Este artigo descreve como a equipe de Engenharia de Software Comercial (CSE) da Microsoft fez parceria com um varejista global para implantar uma solução sem servidor altamente disponível nas plataformas de nuvem Azure e Amazon Web Services (AWS), usando o Serverless Framework.
Arquitetura
Transfira um ficheiro do Visio desta arquitetura.
Fluxo de dados
- O aplicativo do usuário pode vir de qualquer fonte capaz de fazer login na nuvem. Nessa implementação, o usuário efetua login em um aplicativo de gateway que balanceia a carga de solicitações de 50 a 50 entre as nuvens do Azure e da AWS.
- Qualquer resposta também é roteizada por meio do gateway do Gerenciador de API, que a envia para o aplicativo solicitante.
Componentes
A estrutura sem servidor
Esta solução usa o Serverless Framework, disponível em Serverless, Inc. A versão gratuita do Serverless Framework inclui uma CLI, mais plugins e serviços de monitoramento limitados. A edição Pro apresenta recursos operacionais em nuvens, como monitoramento e alertas aprimorados. A estrutura oferece suporte às linguagens Node.js e Python e aos hosts de nuvem da AWS e do Azure.
Para usar o Azure com o Serverless Framework, você precisa:
- Node.js, para empacotar microsserviços
- Azure Functions, para fornecer funcionalidade comparável a outras plataformas de nuvem
- O Serverless Framework, para suportar a implementação e monitorização multicloud
- A Biblioteca Multicloud sem Servidor, para fornecer APIs de tempo de execução normalizadas para desenvolvedores
- O plug-in sem servidor do Azure Functions, para dar suporte à implantação multicloud. Inicialmente, esse plug-in não estava em paridade com o plug-in comparável do AWS Lambda 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 chegar ao manipulador.
APIs agnósticas da nuvem
A implementação sem servidor em cada plataforma suporta funções individuais como microsserviços, uma para cada nó de VM funcional, e executa o processamento conforme necessário. Cada função do AWS Lambda tem uma função correspondente do Azure Functions. A Serverless Multicloud Library cria microsserviços análogos de qualquer nuvem em uma API REST normalizada independente da nuvem que os aplicativos cliente podem usar para interagir com qualquer plataforma. Como a camada de API abstrata fornece código para endereçar os microsserviços correspondentes para cada plataforma, as transações não precisam de tradução. A interface independente da nuvem permite que os aplicativos do usuário interajam com a nuvem sem saber ou se importar com qual plataforma de nuvem eles estão 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 ao GitOps.
Embora esse projeto inicial usasse implantações manuais, é realista implementar compilações, testes e implantações sem servidor orientados por manifesto dentro ou entre nuvens. Esse processo pode usar um fluxo de trabalho de desenvolvedor GitOps: construindo a partir do Git, usando portas de qualidade para teste e avaliação e enviando soluções sem servidor para ambos os provedores de nuvem. Executar todas as implantações usando o Serverless Framework desde o início do projeto é a maneira mais eficiente de prosseguir.
Gestor de API
O Gerenciador de API pode ser um aplicativo existente ou personalizado. O Apigee™ API Manager nesta implementação agiu apenas como um roteador para fornecer um equilíbrio de carga de transação de 50-50 para as duas plataformas de nuvem, e foi subutilizado para suas capacidades.
O Gerenciador de API deve ser capaz de:
- Ser implantado dentro ou fora de uma plataforma de nuvem, conforme necessário
- Encaminhar mensagens de e para ambas as plataformas de nuvem
- Registrar solicitações de tráfego para coordenar o tráfego assíncrono de mensagens
- Retransmitir solicitações e respostas usando a API REST comum de e para o aplicativo do usuário
- Monitore a integridade de ambas as implantações de estrutura sem servidor na nuvem para validar sua capacidade de receber solicitações
- Execute verificações automatizadas de integridade e disponibilidade em cada plataforma de nuvem para oferecer suporte ao roteamento e à alta disponibilidade
Alternativas
Outras linguagens, como o Python, poderiam implementar a solução, desde que sejam suportadas pelas implementações sem servidor das plataformas de nuvem, AWS Lambda e Azure Functions, neste caso. Este projeto usou Node.js para empacotar os microsserviços, porque o cliente estava confortável com Node.js, e as plataformas AWS e Azure oferecem suporte a isso.
A solução pode usar qualquer plataforma de nuvem que ofereça suporte ao Serverless Framework, não apenas o Azure e a AWS. Atualmente, o Serverless Framework relata compatibilidade com oito provedores de nuvem diferentes. A única ressalva é garantir que os elementos que suportam a arquitetura multicloud ou seu equivalente estejam disponíveis nas plataformas de nuvem de destino.
O API Manager nesta implementação inicial agiu 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 recursos de microsserviços para executar 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 do código e de aspetos operacionais, como planejamento e manutenção.
Tal como acontece com outros serviços, cada fornecedor de serviços em nuvem tem a sua própria implementação sem servidor e é difícil para os clientes utilizarem um fornecedor diferente sem um impacto operacional e custos consideráveis. Os potenciais clientes podem ver esta situação como um enfraquecimento da sua posição negocial e da sua agilidade. A dependência do fornecedor é um dos maiores obstáculos à adoção da nuvem corporativa.
O Serverless Framework de código aberto é uma interface de nuvem universal para desenvolver e implantar soluções de computação sem servidor em provedores de nuvem. O open sourcing e as APIs comuns para funções sem servidor ajudam os provedores, clientes e parceiros a criar soluções entre nuvens para os melhores serviços. O Serverless Framework reduz as barreiras à adoção da nuvem, abordando os problemas de dependência do fornecedor e redundância entre provedores de nuvem. Os clientes podem otimizar suas soluções com base em custo, agilidade e outras considerações.
O CSE e a equipe de produto do Azure reescreveram coletivamente a CLI sem servidor para dar suporte aos novos recursos do Azure Functions, como Funções Premium, Gerenciamento de API e KeyVault. A CLI sem servidor agora fornece uma interface padrão para implantação do GitOps no Azure e na AWS. A equipe também desenvolveu a Serverless Multicloud Library, que fornece uma API de tempo de execução normalizada para implantar aplicativos sem servidor na 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 não estiver íntegro ou indisponível, essa solução poderá redirecionar solicitações para outra plataforma de nuvem.
Este projeto cumpriu os seguintes objetivos técnicos:
- Crie uma solução intersetorial.
- Use a Multicloud Serverless Library para oferecer suporte a uma API independente da nuvem que faz interface com microsserviços onde quer que eles sejam implantados.
- Ofereça 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 suportadas.
- Use o acesso baseado em API por meio de um gateway de nuvem autenticado e balanceie de carga entre plataformas de nuvem usando o gateway como um roteador.
Outros benefícios potenciais do uso do Serverless Framework incluem:
- Prevenção ou redução da dependência do fornecedor
- Redução de código de 40-60+% durante o desenvolvimento usando a Multicloud Serverless Library
- Desenvolvimento das melhores soluções que combinam os serviços de diferentes fornecedores de serviços em nuvem
- Eliminação da maior parte da complexidade da plataforma e da infraestrutura e dos requisitos de manutenção
- Compartilhamento de dados mais fácil, comparações de desempenho e custos e capacidade de aproveitar ofertas especiais
- Alta disponibilidade ativo-ativo
Potenciais casos de utilização
- Escreva aplicativos do lado do cliente para várias plataformas usando uma API independente da nuvem da Serverless Multicloud Library.
- Implante uma coleção de microsserviços funcionais em uma estrutura sem servidor em várias plataformas de nuvem.
- Use um aplicativo independente da nuvem em plataformas de nuvem sem saber ou se importar com qual plataforma está hospedando-o.
Considerações
Este artigo não descreve soluções de segurança, embora a implantação inicial as tenha incluído. Existem muitas soluções de segurança possíveis, algumas dependentes da plataforma, e esta estrutura deve acomodar qualquer solução razoável. A autenticação do usuário é a segurança mínima assumida.
Como é difícil articular as diferenças entre as ofertas funcionais sem servidor da AWS e do Azure, o esforço inicial 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 a partir dessas informações.
Usar uma solução de código aberto pode introduzir riscos, devido a desafios de manutenção e suporte a longo prazo com qualquer software de código aberto.
No Serverless Framework gratuito, o monitoramento é limitado principalmente ao painel administrativo. O monitoramento está disponível na oferta empresarial paga. Atualmente, o plug-in sem servidor do Azure Functions não inclui provisões para observabilidade ou monitoramento e precisaria 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 perfeitamente o uso entre plataformas de nuvem.
Implementar este cenário
Uma implantação Blue-Green tradicional desenvolve e implanta um aplicativo em dois ambientes separados, mas idênticos, azul e verde, aumentando a disponibilidade e reduzindo o risco. O ambiente azul geralmente é o ambiente de produção que normalmente lida com tráfego ao vivo, 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. Esta configuração é considerada uma configuração ativa-passiva .
Na solução multicloud, a implantação azul-verde é implementada em ambas as plataformas de nuvem. No caso sem servidor, dois conjuntos duplicados de microsserviços são implantados para cada plataforma de nuvem, um como ambiente de produção e outro como ambiente de failover. Essa configuração ativo-passivo dentro de cada plataforma de nuvem reduz o risco de que essa plataforma fique inativa, aumentando sua disponibilidade e permitindo alta disponibilidade ativa-ativa multicloud.
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 microsserviços, antes de liberá-las para a implantação de produção.