Desenvolver, administrar e implementar aplicações no Kubernetes utilizando métodos de infraestrutura como código, com divisão de responsabilidades e visualização de dependências.
A complexidade dos aplicativos nativos de nuvem é profunda e abrangente, indo além do uso do Kubernetes e envolvendo um crescente conjunto de serviços oferecidos pelas plataformas de nuvem pública. Desenvolver e gerenciar esses aplicativos requer mais do que simples codificação, demandando uma colaboração estreita entre equipes para garantir a estabilidade, por meio da entrega de um conjunto consistente de código e configurações que possam ser implantados de forma eficiente.
Isso envolve a necessidade de integrar os diferentes elementos de uma aplicação nativa da nuvem de forma harmoniosa, aproveitando as ferramentas já utilizadas, sem precisar criar algo do zero, uma vez que essas ferramentas já são eficazes, embora não estejam integradas.
Nós tomamos vários passos durante o percurso. As ferramentas de infraestrutura como código (IaC), tais como Terraform e Azure Resource Manager, permitem a automação da gestão de serviços e plataformas de infraestrutura ao definir e construir redes, servidores e serviços necessários para o seu código. Essas ferramentas estão se tornando cada vez mais avançadas e capazes de interagir diretamente com APIs de gerenciamento de serviços em nuvem, fornecendo uma sintaxe familiar com abordagens declarativas e programáticas para a definição de infraestrutura.
Na área da programação, existem estruturas que facilitam a criação de aplicativos, o controle de APIs e auxiliam na definição dos microsserviços que formam um aplicativo nativo comum na nuvem. Com a utilização de um framework de aplicação atual, podemos passar de algumas instruções de linha de comando para um modelo básico de aplicação, permitindo-nos atender às necessidades dos nossos usuários.
Como podemos combinar essas duas abordagens de colaboração de forma eficaz para desenvolver e administrar nossos aplicativos nativos na nuvem? A Microsoft lançou recentemente uma nova ferramenta de engenharia de plataforma com esse propósito específico.
Introduzindo Radius
Criada pela equipe de incubação do Azure, a Radius combina estruturas de aplicativos distribuídos já existentes e ferramentas de infraestrutura conhecidas, além de conexões automatizadas para serviços em nuvem. Seu objetivo é centralizar o gerenciamento de diversos modelos, possibilitando que equipes continuem utilizando suas ferramentas atuais. Em vez de descartar habilidades existentes, a Radius captura automaticamente as informações essenciais para gerenciar recursos de aplicação.
Mantive uma troca de e-mails com o CTO do Azure, Mark Russinovich, sobre o Radius, discutindo suas visões para o progresso do projeto e o papel que desempenharia no desenvolvimento em nuvem nativa. Ele compartilhou comigo,
Desejamos que os desenvolvedores possam acompanhar os custos, as operações e as boas práticas de segurança. No entanto, descobrimos, por meio de feedback dos clientes, que tentar ensinar aos desenvolvedores os detalhes de funcionamento do Kubernetes ou as possíveis configurações para o Redis não estava sendo eficaz. Era necessário encontrar uma abordagem mais eficiente para evitar que os desenvolvedores se perdessem em detalhes ao buscar o sucesso.
Russinovich notou outro condutor, ou seja, a expansão de novas áreas de estudo.
Texto parafraseado: “Testemunhamos o surgimento da engenharia de plataforma como uma área de estudo. Acreditamos que o Radius pode ser útil ao oferecer uma plataforma de autoatendimento, permitindo que os desenvolvedores sigam as práticas recomendadas pelas empresas por meio de receitas personalizadas, as quais envolvem os módulos Terraform já existentes nas organizações. Se conseguirmos alcançar esse objetivo, isso poderá auxiliar as equipes de TI e desenvolvimento na implementação das melhores práticas de engenharia de plataforma, permitindo que os desenvolvedores se concentrem na programação, que é o que eles mais gostam de fazer.”
A Radius pode ser considerada como uma das primeiras ferramentas de operações de plataforma de uma nova geração. Enquanto existem outras ferramentas como Dapr para gerenciar aplicativos e Bicep para gerenciar a infraestrutura, a Radius se destaca por integrar aplicativos e infraestruturas, focando no desenvolvimento de aplicativos nativos em nuvem. Seu objetivo é centralizar a gestão de informações essenciais da plataforma, como strings de conexão, funções e permissões, necessárias para conectar o código à infraestrutura subjacente, como Kubernetes e serviços de nuvem.
Iniciar com o Raio.
Você vai precisar de um cluster de Kubernetes para rodar o Radius, que funciona como uma aplicação Kubernetes. A maioria das operações do Radius são realizadas por meio de uma linha de comando que pode ser instalada na maioria dos shells, incluindo suporte para o Windows Subsystem para Linux e PowerShell, além do macOS. Após a instalação, é possível verificar se tudo está correto executando o comando “rad version”. Com isso feito, você está preparado para iniciar a construção da sua primeira aplicação gerenciada pelo Radius.
Utilize o comando Identificação para iniciar o Radius no contexto atual do cluster de desenvolvimento, especificando seu namespace e configurando um ambiente para começar a trabalhar. Ao mesmo tempo, o rad init cria um aplicativo Radius padrão, gerando um aplicativo Bicep que carregará um contêiner de demonstração do repositório do Azure Radius. Para executar o contêiner de demonstração, utilize o comando rad run para lançar o aplicativo de infraestrutura Bicep. Isso configurará o servidor Kubernetes e iniciará o contêiner de demonstração, que inclui um servidor web básico executando uma aplicação web simples.
Você não está limitado a utilizar a linha de comando, pois o Radius também é compatível com um conjunto de extensões do Visual Studio Code. O primeiro passo evidente é instalar a extensão Radius Bicep, que oferece suporte para recursos Azure e AWS. É importante ressaltar que esta extensão não é a mesma que a extensão Bicep completa e não é compatível com ela. A Microsoft planeja integrar o suporte do Radius na extensão oficial do Bicep, porém isso demandará algum tempo. Você tem a opção de utilizar a extensão oficial HashiCorp Terraform para criar e editar scripts.
Sob o capô, há um gráfico Helm que supervisiona a implantação nos servidores Kubernetes, construídos a partir da definição de aplicativo pelo Radius. Essa abordagem permite implantar aplicativos no Kubernetes utilizando os processos Helm já existentes, mesmo quando se usa o Radius para gerenciar o desenvolvimento de aplicativos. É possível criar aplicativos e infraestruturas com o Radius, armazenar a saída em um registro compatível com OCI e utilizar ferramentas de implantação já existentes para disponibilizar o código em toda a infraestrutura global. O Radius criará o arquivo YAML Helm para você com base nas definições de Bicep.
Isso é bastante comum para um aplicativo básico nativo na nuvem, onde você pode utilizar suas ferramentas preferidas para criar recipientes e seus conteúdos. A verdadeira inovação com Radius ocorre quando você começa a incorporar “receitas” ao código Bicep, estabelecendo conexões entre seus recipientes e serviços de plataforma ou recursos externos, como bancos de dados.
Administrar plataformas de serviços por meio de estratégias da Radius.
Uma das vantagens das receitas é que elas são feitas para incluir automaticamente as variáveis de ambiente necessárias em um contêiner, como as strings de conexão do banco de dados, para que seu código possa utilizar recursos sem precisar de mais configurações além das presentes no seu Bicep. Isso possibilita que as equipes de plataforma garantam que as medidas de segurança estejam em vigor, como garantir a segurança das conexões.
Você tem a opção de aprovar uma receita usando Bicep ou Terraform, sendo que Terraform é a escolha mais indicada para desenvolvimento em múltiplas nuvens. Se você já utiliza técnicas de infraestrutura como código, essa abordagem será familiar para você, pois trata a receita como um modelo de infraestrutura com os mesmos parâmetros em Bicep ou variáveis no Terraform que são utilizadas em outros contextos.
As receitas estabelecem os parâmetros utilizados para lidar com o recurso de destino, controlando as conexões com os serviços necessários para o funcionamento do seu código. Essas conexões são então especificadas na definição do seu aplicativo. Dessa maneira, as receitas Radius promovem a divisão de responsabilidades entre a engenharia de plataforma e o desenvolvimento de aplicações. Caso eu deseje incluir um cache Redis na minha aplicação, basta adicionar a receita apropriada ao meu aplicativo Radius. Essa receita é desenvolvida e administrada pela equipe de plataforma, que determina como essa funcionalidade será implementada e quais informações serão necessárias para utilizá-la na minha aplicação.
Fora da caixa Radius oferece uma seleção de receitas simples e locais para serviços usuais. Essas receitas podem servir como exemplos para criar suas próprias receitas, seja para integrar um aplicativo com o Azure OpenAI, estabelecer uma loja online, ou conectar-se a um serviço de pagamento.
Uma possibilidade atrativa consiste em empregar o Radius para montar a estrutura necessária para uma aplicação Dapr. Neste caso, você configura seu aplicativo como um componente Dapr, utilizando uma receita do Radius para adicionar uma camada de armazenamento de estado com o banco de dados de sua escolha. No repositório do Radius, há diversos exemplos de contêineres Dapr disponíveis para auxiliá-lo no início do projeto.
Simplesmente adicione suas conexões à configuração da loja estadual e inclua uma extensão para o sidecar Dapr. Isso significa que você criará seus próprios contêineres usando Dapr, utilizando suas ferramentas de desenvolvimento de microsserviços usuais, e então os incluirá em um repositório local para gerenciar a aplicação final no Radius.
Domando o Oeste Selvagem da Nuvem Nativa.
Uma das questões principais que o Radius busca abordar é a dificuldade de compreender os recursos e conexões complexas envolvidas nas aplicações nativas em nuvem. O Radius oferece uma estrutura que nos permite visualizar nossas aplicações de forma clara, facilitando a implementação de governança arquitetônica para garantir a estabilidade e segurança das aplicações empresariais.
Uma das principais vantagens da ferramenta Radius é sua capacidade de representar de maneira rápida as estruturas de aplicativos, mostrando as relações entre contêineres e serviços em um formato gráfico. Atualmente, o gráfico gerado pela Radius é apenas em texto, porém há planos de incluir visualizações mais acessíveis e avançadas que poderiam auxiliar significativamente na compreensão e resolução de problemas em aplicações de grande porte, conforme observado por Russinovich.
Nós simplificamos o acesso ao Radius e obtivemos o gráfico completo da aplicação. Outra pessoa poderia unir nosso gráfico de aplicativos a outra fonte de dados, como telemetria ou dados de rede. Observar esses gráficos em conjunto pode ser bastante impactante.
Além de fornecer uma visão do que compõe a nossa aplicação, o gráfico de aplicação terá um papel importante em auxiliar as equipes a avançarem do desenvolvimento para a produção, conforme afirmou Russinovich.
Por exemplo, é possível observar a diferença entre a definição de um aplicativo feita por um desenvolvedor e sua implementação em ambiente de produção. Ter um diagrama de aplicativos possibilita que essas equipes colaborem na definição e na implantação do aplicativo. Além do custo e da infraestrutura, outros aspectos a considerar incluem desempenho, monitoramento e análise de traços.
A evolução do desenvolvimento na nuvem nativa requer uma transição do ambiente de programação manual para um cenário onde podemos implementar práticas de engenharia confiáveis e consistentes como parte de nossas atividades rotineiras. Por essa razão, a introdução de plataformas como o Radius é significativa. Esta plataforma não apenas é proveniente da Microsoft, mas também está sendo desenvolvida e utilizada por empresas como Comcast, BlackRock e o banco português Millennium BCP, sendo disponibilizada como um projeto de código aberto no GitHub.
Ao encerrar nossa troca de mensagens por e-mail, Mark Russinovich destacou o potencial de progresso da plataforma Radius, enfatizando a importância da participação da comunidade por meio da Cloud Native Computing Foundation (CNCF).
Radius possui diversos pontos de expansão. Gostaríamos de ver parceiros como Confluent ou MongoDB colaborando para gerar receitas ao integrar seus serviços com o Radius. Além disso, acreditamos que os provedores de nuvem, como AWS ou GCP, poderiam aprimorar o suporte multi-nuvem do Radius. Por fim, temos planos de desenvolver extensões para suportar computação sem servidor, como AWS Fargate e Azure Container Instances.