Este artigo descreve a parceria estabelecida entre a equipe de Engenharia de Software Comercial (CSE) da Microsoft com um varejista global para implantar uma solução sem servidor altamente disponível nas plataformas de nuvem Azure e AWS (Amazon Web Services) usando o Serverless Framework.
Arquitetura
Baixe um Arquivo Visio dessa arquitetura.
Fluxo de dados
- O aplicativo do usuário pode vir de qualquer fonte capaz de fazer logon na nuvem. Nessa implementação, o usuário faz logon em um aplicativo de gateway que balanceia a carga das solicitações de 50 a 50 entre as nuvens Azure e AWS.
- Qualquer resposta também roteia o gateway do Gerenciador de API, que o envia para o aplicativo solicitante.
Componentes
O Serverless Framework
A solução usa o Serverless Framework, da Serverless, Inc. A versão gratuita do Serverless Framework inclui uma CLI, mais plugins e serviços de monitoramento limitados. A edição do Pro apresenta recursos operacionais entre nuvens, como monitoramento e alertas aprimorados. O Framework dá suporte a linguagens Node.js e Python e hosts de nuvem do Azure e AWS.
Para usar o Azure com o Serverless Framework, você precisa de:
- Node.js, para empacotar os microserviços
- O Azure Functions, para fornecer funcionalidade comparável a outras plataformas de nuvem
- O Serverless Framework, para dar suporte à implantação e ao monitoramento de nuvem
- A biblioteca multinuvem sem servidor, para fornecer APIs de tempo de execução normalizadas para desenvolvedores
- O plug-in do Azure Functions sem servidor, para dar suporte à implantação em nuvem. Esse plug-in não estava inicialmente em paridade com o plug-in de Lambda AWS comparável e foi estendido para este projeto.
A figura a seguir mostra o pipeline de processamento. As camadas de middleware representam qualquer funcionalidade intermediária necessária antes de alcançar o manipulador.
APIs independentes de nuvem
A implementação sem servidor em cada plataforma dá suporte a funções individuais como microservices, uma para cada nó de VM funcional e executa o processamento conforme necessário. Cada função Lambda AWS tem uma função de Azure Functions correspondente. A biblioteca multinuvem sem servidor cria microserviços análogos de uma nuvem em uma API REST normalizada independente de nuvem que os aplicativos cliente podem usar para fazer interface com qualquer plataforma. Como a camada de API abstrata fornece código para lidar com os microserviços correspondentes para cada plataforma, as transações não precisam de tradução. A interface independente de nuvem permite que os aplicativos de usuário interajam com a nuvem sem saber ou preocupar qual plataforma de nuvem está acessando.
O diagrama a seguir ilustra esse conceito:
CI/CD com GitOps
Um trabalho principal do Serverless Framework é abstrair todas as preocupações de infraestrutura da implantação de um aplicativo na nuvem. Usando uma abordagem baseada em manifesto, o Serverless Framework pode lidar com todos os problemas de implantação, permitindo que a implantação seja automatizada conforme necessário para dar suporte a GitOps.
Embora esse projeto inicial tenha usado implantações manuais, é realista implementar compilações, testes e implantações sem servidor controladas por manifesto dentro ou entre nuvens. Esse processo pode usar um fluxo de trabalho do desenvolvedor do GitOps: compilação do Git, uso de Gates de qualidade para teste e avaliação e envio de soluções sem servidor em ambos os provedores de nuvem. Executar todas as implantações usando o Serverless Framework do início do projeto é a maneira mais eficiente de continuar.
Gerenciador de API
O Gerenciador de API pode ser um aplicativo existente ou personalizado. O Gerenciador de API Apigee™ nessa implementação funcionava apenas como um roteador para fornecer um balanceamento de carga de transação de 50 a 50 para as duas plataformas de nuvem e foi subutilizado para seus recursos.
O Gerenciador de API deve ser capaz de:
- Ser implantado dentro ou fora de uma plataforma de nuvem, conforme necessário
- Rotear mensagens de e para ambas as plataformas de nuvem
- Solicitações de tráfego de log para coordenar o tráfego de mensagens assíncronas
- Retransmitir solicitações e respostas usando a API REST comum de e para o aplicativo de usuário
- Monitore a integridade de implantações de estrutura sem servidor na nuvem para validar sua capacidade de receber solicitações
- Executar verificações automatizadas de integridade e disponibilidade em cada plataforma de nuvem, para dar suporte ao roteamento e alta disponibilidade
Alternativas
Outras linguagens, como o Python, poderiam implementar a solução, desde que elas tenham suporte das implementações sem servidor das plataformas de nuvem, AWS Lambda e Azure Functions nesse caso. Este projeto usou Node.js para empacotar os microserviços, porque o cliente estava confortável com Node.js, e as plataformas do AWS e do Azure dão suporte a ele.
A solução pode usar qualquer plataforma de nuvem que dê suporte ao Serverless Framework, não apenas ao Azure e AWS. Atualmente, a Serverless Framework relata a compatibilidade com oito provedores de nuvem diferentes. A única limitação é garantir que os elementos que dão suporte à arquitetura de várias nuvens ou seu equivalente estejam disponíveis nas plataformas de nuvem de destino.
O Gerenciador de API nessa implementação inicial funcionava apenas como um roteador para fornecer um balanceamento de carga de transação de 50 a 50 para as duas plataformas de nuvem. O Gerenciador de API pode incorporar outra lógica de negócios para cenários específicos.
Detalhes do cenário
Na computação sem servidor, o provedor de nuvem aloca dinamicamente os recursos de microserviço para executar o código e cobra apenas pelos recursos usados. A computação sem servidor abstrai o código do aplicativo da implementação da infraestrutura, da implantação de código e dos aspectos operacionais, como planejamento e manutenção.
Assim como acontece com outros serviços, cada provedor de nuvem tem sua própria implementação sem servidor, e é difícil para os clientes usarem um provedor diferente com um impacto operacional considerável e custos. Clientes potenciais podem exibir essa situação como enfraquecendo sua posição e agilidade de acordo. O bloqueio do fornecedor é um dos maiores obstáculos à adoção da nuvem empresarial.
O Serverless Framework de código aberto é uma interface de nuvem universal para desenvolver e implantar soluções de computação sem servidor entre provedores de nuvem. As APIs de código aberto e comuns para funções sem servidor ajudam provedores, clientes e parceiros a criar soluções entre nuvem para os melhores serviços. O Serverless Framework reduz as barreiras para a adoção da nuvem abordando os problemas de bloqueio de fornecedor e redundância de provedor entre nuvem. Os clientes podem otimizar suas soluções com base em custos, agilidade e outras considerações.
A CSE e a equipe de produto do Azure reescreveram coletivamente a CLI sem servidor para dar suporte a novos recursos de Azure Functions, como funções de Premium, Gerenciamento de API e KeyVault. A CLI sem servidor agora fornece uma interface padrão para a implantação do GitOps no Azure e no AWS. A equipe também desenvolveu a biblioteca multinuvem sem servidor, que fornece uma API de tempo de execução normalizada para implantar aplicativos sem servidor no AWS e no Azure.
Esse design fornece alta disponibilidade com failover ativo-ativo entre várias plataformas de nuvem, em oposição ao failover ativo-passivo. Se o serviço de um provedor de nuvem se tornar não íntegro ou indisponível, essa solução poderá redirecionar solicitações para outra plataforma de nuvem.
Este projeto atende aos seguintes objetivos técnicos:
- Crie uma solução entre setores.
- Use a biblioteca sem servidor de nuvem para dar suporte a uma API independente de nuvem que interage com microservices onde quer que elas sejam implantadas.
- Suporte a um fluxo de trabalho de processo de CI/CD do GitOps para desenvolvimento, teste e implantação em todas as plataformas de nuvem com suporte.
- Use o acesso baseado em API por meio de um gateway de nuvem autenticado e balanceamento de carga entre plataformas de nuvem usando o gateway como um roteador.
Outros benefícios potenciais de usar o Serverless Framework incluem:
- Prevenção ou redução do bloqueio do fornecedor
- Redução de 40 a 60% de código durante o desenvolvimento usando a biblioteca sem servidor de nuvem
- Desenvolvimento de soluções de ponta que combinam serviços de provedores de nuvem diferentes
- Eliminação da maior complexidade da plataforma e da infraestrutura e requisitos de manutenção
- Compartilhamento de dados, comparações de desempenho e custo mais fáceis e capacidade de aproveitar ofertas especiais
- Alta disponibilidade ativo-ativo
Possíveis casos de uso
- Grave aplicativos do lado do cliente para várias plataformas usando uma API independente de nuvem da biblioteca multinuvem sem servidor.
- Implante uma coleção de microserviços funcionais em uma estrutura sem servidor para várias plataformas de nuvem.
- Use um aplicativo independente de nuvem em plataformas de nuvem sem saber ou preocupar qual plataforma está hospedando-o.
Considerações
Este artigo não descreve as soluções de segurança, embora a implantação inicial as tenha incluído. Há muitas soluções de segurança possíveis, algumas plataformas dependentes, e essa estrutura deve acomodar qualquer solução razoável. A autenticação de usuário é a segurança mínima assumida.
Como é difícil articular as diferenças entre AWS e ofertas funcionais sem servidor do Azure, o esforço antecipado deve se concentrar no mapeamento das funções disponíveis em cada plataforma de nuvem e na identificação dos requisitos de transformação necessários. Você pode desenvolver uma API independente de plataforma com base nessas informações.
O uso de uma solução de software livre pode introduzir riscos, devido à manutenção de longo prazo e aos desafios de suporte com qualquer software livre.
No Serverless Framework gratuito, o monitoramento é limitado principalmente ao painel administrativo. O monitoramento está disponível na oferta paga para empresas. Atualmente, o plug-in do Azure Functions sem servidor não inclui provisões de observação ou monitoramento e precisa de modificação para implementar esses recursos.
Essa solução pode usar métricas para comparar o desempenho e os custos entre plataformas de nuvem, permitindo que os clientes otimizem o uso diretamente entre plataformas de nuvem.
Implantar este cenário
Uma implantação azul-verde tradicional desenvolve e implanta um aplicativo em dois ambientes separados, mas idênticos, em azul e verde, aumentando a disponibilidade e reduzindo os riscos. O ambiente azul geralmente é o ambiente de produção que normalmente lida com o tráfego ativo, e o ambiente verde é uma implantação de failover, conforme necessário. Normalmente, o pipeline de CI/CD implanta automaticamente ambientes azuis e verdes dentro da mesma plataforma de nuvem. Essa configuração é considerada uma configuração ativa-passiva.
Na solução de multinuvem, a implantação azul-verde é implementada em ambas as plataformas de nuvem. No caso sem servidor, dois conjuntos duplicados de microserviços são implantados para cada plataforma de nuvem, um como o ambiente de produção e o outro como o ambiente de failover. Essa configuração ativa-passiva em cada plataforma de nuvem reduz o risco de que essa plataforma fique inativa, aumentando sua disponibilidade e habilitando a alta disponibilidade ativo-ativo de várias nuvens.
Um benefício secundário da implantação azul-verde é a capacidade de usar a implantação de failover em cada plataforma de nuvem como um ambiente de teste para atualizações de microserviços, antes de liberá-las para a implantação de produção.