Um mergulho profundo na arquitetura Microsoft Radius

Em meu artigo anterior, analisei o fluxo de trabalho de alto nível envolvido no uso do recém-lançado Radius da Microsoft para implantar aplicativos modernos. Vamos dar uma olhada na arquitetura e ampliar os detalhes de como a Microsoft construiu o plano de controle do Radius.

Que problema o raio resolve?

O Radius tenta resolver três problemas principais pertinentes à implantação de aplicativos modernos.

• Complexidade do Kubernetes: Kubernetes, a plataforma de orquestração de contêineres mais popular, introduz complexidade por meio de sua arquitetura altamente flexível, porém complexa. Os desenvolvedores navegam em um labirinto de objetos como pods, serviços e implantações, garantindo interação, dimensionamento e gerenciamento contínuos de contêineres. Essa complexidade aumenta à medida que os clusters crescem, exigindo experiência em armazenamento persistente, configuração de rede e protocolos de segurança.
• Não há separação clara de preocupações entre desenvolvimento e operações: O Kubernetes, apesar das suas capacidades avançadas de orquestração, muitas vezes confunde as linhas de separação de interesses, um princípio vital para a modularidade do sistema e a eficiência organizacional. Ele interliga o gerenciamento de infraestrutura, a implantação de aplicativos e as tarefas operacionais, às vezes causando ambiguidade de funções entre as equipes de desenvolvimento e operações.
• Falta de tempos de execução unificados entre Kubernetes e plataformas em nuvem: Os aplicativos nativos da nuvem enfrentam um desafio significativo com a falta de tempos de execução unificados em diferentes plataformas de nuvem, complicando as estratégias multicloud e as transições nativas da nuvem. Mesmo quando os aplicativos são implantados em clusters Kubernetes gerenciados baseados em nuvem, o consumo de outros serviços gerenciados, como bancos de dados, armazenamento de objetos, serviços de cache e filas de mensagens, exige bastante trabalho. Os desenvolvedores precisam de um ambiente de tempo de execução unificado que abstraia Kubernetes e ambientes de nuvem.

O Radius permite que os desenvolvedores tratem Kubernetes, nuvem pública e ambientes de borda como tempos de execução unificados e abstratos para implantar e dimensionar aplicativos modernos.

A influência do Azure no Radius UCP

Antes de nos aprofundarmos nos detalhes do Radius, vamos recapitular rapidamente como o Azure gerencia os serviços em nuvem.

Um dos principais blocos de construção do Azure é um recurso, que representa uma unidade implantável, como uma máquina virtual, um banco de dados SQL, um cluster Hadoop ou um cluster Kubernetes. Os recursos que pertencem logicamente a uma carga de trabalho ou a um aplicativo são colocados em um grupo de recursos. Os grupos de recursos fazem parte de uma assinatura do Azure, que fornece o mais alto nível de isolamento de recursos.

Cada recurso do Azure é identificado pela assinatura, pelo grupo de recursos e, finalmente, pelo identificador associado ao próprio recurso. Este esquema de endereço ajuda o plano de controlo do Azure a identificar exclusivamente os recursos e a gerir o seu ciclo de vida.

Os serviços do Azure, como máquinas virtuais e instâncias de base de dados, são geridos por gestores de recursos individuais. Eles são diretamente responsáveis ​​pelo gerenciamento do ciclo de vida dos recursos. Quando a Microsoft adiciona um novo serviço de nuvem, tudo começa com um gestor de recursos que sabe como lidar com a criação, atualização e encerramento de recursos individuais. Os modelos do Azure Resource Manager (ARM) fornecem um mecanismo declarativo para definir e provisionar serviços em nuvem.

Para obter mais contexto e informações adicionais sobre ARM, leia meu artigo de 2016.

Os gestores de recursos associados a cada serviço gerido são registados no controlador de tecido Azure, que atua como plano de controlo que expõe a API. O Portal do Azure, CLI, SDKs e ferramentas de terceiros, como Terraform e Pulumi, conversam com esta API.

O Radius empresta fortemente esses conceitos do controlador de malha do Azure para seu plano de controle. Se o controlador de malha do Azure trata máquinas virtuais de serviços e clusters Kubernetes como provedores de recursos, o Radius trata a API Kubernetes, a API do Azure Resource Manager e a API AWS Cloud Control como provedores de recursos.

Quando uma definição de aplicação aponta para recursos em execução num cluster Kubernetes com serviços em execução no Azure ou no AWS, o plano de controlo federa a chamada e delega a gestão de recursos a cada um dos fornecedores de recursos.

Cada provedor de recursos registrado no UCP é responsável por realizar operações CRUDL (Criar, Ler, Atualizar, Excluir, Listar) em seus recursos. O plano de controle simplesmente abstrai os tempos de execução subjacentes e expõe uma API unificada para a CLI e ferramentas como o Bicep para se comunicarem com ela.

A Microsoft chamou o plano de controle do Radius de Plano de Controle Universal (UCP). Isso é adequado, visto que o plano de controle é capaz de incluir qualquer provedor de recursos. Por exemplo, quando o Google Cloud é adicionado como um ambiente de execução compatível, o provedor de recursos do GCP é registrado no UCP e o ciclo de vida dos serviços em nuvem baseados no GCP será gerenciado pelo provedor de recursos dedicado. Se um provedor de recursos ficar disponível para KVM, o Radius poderá até mesmo provisionar VMs.

Em 2020, escrevi sobre como o Kubernetes está evoluindo como um plano de controle universal. Radius é um exemplo clássico que implementa essa ideia.

Voltando ao Radius UCP, ele é totalmente de código aberto e escrito em Go como um plano de controle extensível.

Os recursos provisionados e gerenciados pelo UCP possuem um mecanismo de endereçamento universal baseado no ambiente de destino. Por exemplo, ao lidar com o Azure, o identificador incluirá a subscrição, o grupo de recursos e o recurso. Da mesma forma, os recursos da AWS são identificados por meio de nomes de recursos da Amazon (ARNs). O provedor local é mapeado para o ambiente e o nome do aplicativo conforme definido no arquivo Bicep ou Terraform. Esta abordagem não apenas elimina a carga do UCP de gerenciar os identificadores de recursos, mas também depende do provedor de recursos para nomear e endereçar recursos individuais.

Ao instalar o Radius em um cluster Kubernetes e verificar os provedores de recursos disponíveis, você verá os provedores de desenvolvimento local, AWS e Azure registrados no UCP.

Abaixo estão exemplos de identificadores de recursos provisionados em um cluster Kubernetes local, Azure e AWS por meio do Radius UCP.

/planes/radius/local/resourceGroups/my-group/Applications.Core/applications/my-app

/planes/azure/azurecloud/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/my-group/Microsoft.Storage/storageAccounts/myaccount

/planes/aws/aws/accounts/01234556789/regions/us-west-2/AWS.Kinesis/Stream/my-stream

É importante observar que o UCP federa a chamada CRUDL ao respectivo provedor de recursos, o que também expõe uma API REST escalável. Os provedores de recursos são projetados para aceitar tráfego somente do UCP. Isso garante que a autenticação e a autorização estejam em vigor.

Por fim, o Radius tem forte integração com o Dapr, o que facilita o desenvolvimento de aplicativos multicloud sem a necessidade de acoplá-los fortemente aos serviços em nuvem. Para começar com o Dapr, consulte meu tutorial. Dapr é um dos provedores de recursos do Radius, o que torna mais fácil para os operadores trocarem os blocos de construção no momento da implantação.

Resumo

À medida que o Kubernetes se torna mais complexo e a lacuna entre os aplicativos nativos da nuvem e os serviços em nuvem continua a aumentar, o DevOps precisa de plataformas como o Radius.

O Radius simplifica o fluxo de trabalho e o gerenciamento do ciclo de vida de cargas de trabalho e suas dependências para que os desenvolvedores possam se concentrar em seus aplicativos. Ele aproxima os aplicativos executados em um cluster Kubernetes dos serviços gerenciados disponíveis na nuvem pública. Isso significa que os desenvolvedores podem atingir um tempo de execução unificado sem se preocupar com os detalhes de implementação de cargas de trabalho em contêineres e serviços em nuvem.