Editar

Soluções multicloud com o Serverless Framework

Azure Functions

Este artigo descreve como a equipa de Engenharia de Software Comercial (CSE) da Microsoft estabeleceu uma parceria com um revendedor global para implementar uma solução sem servidor altamente disponível em plataformas cloud do Azure e amazon Web Services (AWS), utilizando o Serverless Framework.

Arquitetura

Diagrama a mostrar a arquitetura sem servidor multicloud.

Transfira um ficheiro do Visio desta arquitetura.

Fluxo de dados

  • A aplicação de utilizador pode ser proveniente de qualquer origem capaz de iniciar sessão na cloud. Nesta implementação, o utilizador inicia sessão numa aplicação de gateway que faz o balanceamento de carga de pedidos 50-50 entre as clouds do Azure e do AWS.
  • Qualquer resposta também encaminha através do gateway do Gestor de API, que depois o envia para a aplicação requestor.

Componentes

A Arquitetura Sem Servidor

Esta solução utiliza o Serverless Framework, disponível a partir de Serverless, Inc. A versão gratuita do Serverless Framework inclui uma CLI, mais plug-ins e serviços de monitorização limitados. A edição Pro apresenta capacidades operacionais em clouds, como monitorização melhorada e alertas. A arquitetura suporta linguagens Node.js e Python e anfitriões de cloud do AWS e do Azure.

Para utilizar o Azure com o Serverless Framework, tem de:

  • Node.js, para empacotar microsserviços
  • Funções do Azure, para fornecer funcionalidades comparáveis a outras plataformas na cloud
  • O Serverless Framework, para suportar a implementação e monitorização de várias clouds
  • A Biblioteca Multicloud Sem Servidor, para fornecer APIs de runtime normalizadas para programadores
  • O Funções do Azure Plug-in Sem Servidor, para suportar a implementação multicloud. Este plug-in não estava inicialmente à altura da paridade com o plug-in do AWS Lambda comparável e foi expandido para este projeto.

A figura seguinte mostra o pipeline de processamento. As camadas de middleware representam qualquer funcionalidade intermédia necessária antes de chegar ao processador.

Diagrama que demonstra um pipeline de processamento multicloud.

APIs agnósticas na cloud

A implementação sem servidor em cada plataforma suporta funções individuais como microsserviços, um para cada nó de VM funcional e executa o processamento conforme necessário. Cada função lambda do AWS tem uma função de Funções do Azure correspondente. A Biblioteca Multicloud Sem Servidor cria microsserviços análogos de qualquer uma das cloud para uma API REST normalizada agnóstica na cloud que as aplicações cliente podem utilizar para interagir com qualquer uma das plataformas. Uma vez que a camada de API abstrata fornece código para abordar os microsserviços correspondentes para cada plataforma, as transações não precisam de tradução. A interface agnóstica da cloud permite que as aplicações dos utilizadores interajam com a cloud sem saberem ou cuidarem da plataforma na cloud a que estão a aceder.

O diagrama seguinte ilustra este conceito:

Diagrama que demonstra uma API agnóstica na cloud.

CI/CD com GitOps

Uma tarefa principal do Serverless Framework é abstrair todas as preocupações de infraestrutura de implementação de uma aplicação na cloud. Ao utilizar uma abordagem baseada em manifestos, o Serverless Framework pode lidar com todos os problemas de implementação, permitindo que a implementação seja automatizada conforme necessário para suportar o GitOps.

Embora este projeto inicial tenha utilizado implementações manuais, é realista implementar compilações, testes e implementações sem servidor orientados por manifestos dentro ou em clouds. Este processo pode utilizar um fluxo de trabalho de programador do GitOps: criar a partir do Git, utilizar portas de qualidade para teste e avaliação e emitir soluções sem servidor para ambos os fornecedores de cloud. Executar todas as implementações com a Arquitetura Sem Servidor desde o início do projeto é a forma mais eficiente de proceder.

Gestor de API

O Gestor de API pode ser uma aplicação existente ou personalizada. O Gestor de API de APIgee™ nesta implementação agiu apenas como um router para fornecer um saldo de carga de transação de 50 a 50 para as duas plataformas na cloud e foi subutilizado para as suas capacidades.

O Gestor de API tem de conseguir:

  • Ser implementado dentro ou fora de uma plataforma na cloud, conforme necessário
  • Encaminhar mensagens de e para ambas as plataformas da cloud
  • Registar pedidos de tráfego para coordenar o tráfego de mensagens assíncronas
  • Reencaminhar pedidos e respostas com a API REST comum de e para a aplicação de utilizador
  • Monitorizar o estado de funcionamento de ambas as implementações de arquitetura sem servidor na cloud para validar a capacidade de receber pedidos
  • Efetuar verificações de estado de funcionamento e disponibilidade automatizadas em cada plataforma cloud, para suportar o encaminhamento e a elevada disponibilidade

Alternativas

  • Outros idiomas, como o Python, podem implementar a solução, desde que sejam suportados pelas implementações sem servidor das plataformas na cloud, do AWS Lambda e do Funções do Azure neste caso. Este projeto utilizou Node.js para empacotar os microsserviços, porque o cliente estava confortável com Node.js e as plataformas do AWS e do Azure suportam-no.

  • A solução pode utilizar qualquer plataforma na cloud que suporte o Serverless Framework e não apenas o Azure e o AWS. Atualmente, o Serverless Framework comunica compatibilidade com oito fornecedores de cloud diferentes. A única ressalva é garantir que os elementos que suportam a arquitetura multicloud ou o seu equivalente estão disponíveis nas plataformas de cloud de destino.

  • O Gestor de API nesta implementação inicial agiu apenas como um router para fornecer um saldo de carga de transação de 50 a 50 para as duas plataformas na cloud. O Gestor de API pode incorporar outra lógica de negócio para cenários específicos.

Detalhes do cenário

Na computação sem servidor, o fornecedor de cloud atribui dinamicamente recursos de microsserviços para executar código e apenas os custos dos recursos utilizados. A computação sem servidor abstrai o código da aplicação da implementação da infraestrutura, da implementação de código e dos aspetos operacionais, como o planeamento e a manutenção.

Tal como acontece com outros serviços, cada fornecedor de cloud tem a sua própria implementação sem servidor e é difícil para os clientes utilizar um fornecedor diferente sem um impacto operacional e custos consideráveis. Os potenciais clientes podem ver esta situação como enfraquecendo a sua posição negocial e agilidade. O bloqueio do fornecedor é um dos maiores obstáculos à adoção da cloud empresarial.

O Open source Serverless Framework é uma interface de cloud universal para desenvolver e implementar soluções de computação sem servidor em fornecedores de cloud. O open-sourcing e as APIs comuns para funções sem servidor ajudam os fornecedores, clientes e parceiros a criar soluções em nuvem cruzada para serviços de melhor raça. O Serverless Framework reduz as barreiras à adoção da cloud ao resolver os problemas de redundância entre fornecedores e fornecedores em várias cloud. Os clientes podem otimizar as suas soluções com base nos custos, agilidade e outras considerações.

O CSE e a equipa de produtos do Azure reescreveram coletivamente a CLI Sem Servidor para suportar novas funcionalidades de Funções do Azure, como Funções Premium, Gestão de API e KeyVault. A CLI Sem Servidor fornece agora uma interface padrão para a implementação do GitOps para o Azure e o AWS. A equipa também desenvolveu a Biblioteca Multicloud Sem Servidor, que fornece uma API de runtime normalizada para implementar aplicações sem servidor no AWS e no Azure.

Esta estrutura fornece elevada disponibilidade com ativação pós-falha ativa-ativa entre várias plataformas na cloud, em oposição à ativação pós-falha ativa-passiva . Se o serviço de um fornecedor de cloud ficar em mau estado de funcionamento ou indisponível, esta solução pode redirecionar os pedidos para outra plataforma na cloud.

Este projeto cumpriu os seguintes objetivos técnicos:

  • Crie uma solução entre indústrias.
  • Utilize a Biblioteca Sem Servidor Multicloud para suportar uma API agnóstica na cloud que interage com microsserviços onde quer que sejam implementados.
  • Suporte para um fluxo de trabalho de processo ci/CD do GitOps para desenvolvimento, teste e implementação em todas as plataformas de cloud suportadas.
  • Utilize o acesso baseado em API através de um gateway de cloud autenticado e o balanceamento de carga entre plataformas na cloud através do gateway como router.

Outras vantagens potenciais da utilização do Serverless Framework incluem:

  • Prevenção ou redução do bloqueio do fornecedor
  • Redução de código de 40 a 60% durante o desenvolvimento com a Biblioteca Sem Servidor Multicloud
  • Desenvolvimento de soluções de melhor raça que combinam diferentes serviços de fornecedores de cloud
  • Eliminação da maioria dos requisitos de manutenção e complexidade da plataforma e infraestrutura
  • Partilha de dados, desempenho e comparações de custos mais fáceis e capacidade de tirar partido de ofertas especiais
  • Elevada disponibilidade ativa

Potenciais casos de utilização

  • Escreva aplicações do lado do cliente para várias plataformas através de uma API agnóstica na cloud a partir da Biblioteca Multicloud Sem Servidor.
  • Implemente uma coleção de microsserviços funcionais numa arquitetura sem servidor em várias plataformas na cloud.
  • Utilize uma aplicação agnóstica na cloud em todas as plataformas da cloud sem saber ou cuidar da plataforma que a está a alojar.

Considerações

  • Este artigo não descreve soluções de segurança, embora a implementação inicial as tenha incluído. Existem muitas soluções de segurança possíveis, algumas dependentes da plataforma, e esta arquitetura deve acomodar qualquer solução razoável. A autenticação do utilizador é a segurança mínima assumida.

  • Uma vez que é difícil articular as diferenças entre as ofertas funcionais do AWS e do Azure sem servidor, o esforço inicial deve focar-se no mapeamento das funções disponíveis em cada plataforma na cloud e na identificação dos requisitos de transformação necessários. Pode desenvolver uma API agnóstica de plataforma a partir destas informações.

  • A utilização de uma solução open source pode introduzir riscos, devido a desafios de manutenção e suporte a longo prazo com qualquer software open source.

  • No Framework Sem Servidor gratuito, a monitorização é limitada principalmente ao dashboard administrativo. A monitorização está disponível na oferta empresarial paga. Atualmente, o Plug-in Funções do Azure Sem Servidor não inclui aprovisionamentos de observabilidade ou monitorização e necessitaria de modificação para implementar estas capacidades.

  • Esta solução pode utilizar métricas para comparar o desempenho e os custos entre plataformas na cloud, permitindo que os clientes otimizem de forma totalmente integrada a utilização nas plataformas da cloud.

Implementar este cenário

Uma Implementação Azul-Verde tradicional desenvolve e implementa uma aplicação em dois ambientes separados, mas idênticos, azul e verde, aumentando a disponibilidade e reduzindo o risco. Normalmente, o ambiente azul é o ambiente de produção que normalmente processa o tráfego em direto e o ambiente verde é uma implementação de ativação pós-falha conforme necessário. Normalmente, o pipeline CI/CD implementa automaticamente ambientes azuis e verdes na mesma plataforma na cloud. Esta configuração é considerada uma configuração ativa-passiva .

Na solução multicloud, a implementação azul-verde é implementada em ambas as plataformas da cloud. No caso sem servidor, são implementados dois conjuntos duplicados de microsserviços para cada plataforma na cloud, um como ambiente de produção e outro como ambiente de ativação pós-falha. Esta configuração ativa-passiva em cada plataforma de cloud reduz o risco de esta plataforma estar em baixo, aumentando a sua disponibilidade e ativando a elevada disponibilidade ativa-ativa de várias clouds.

Diagrama a mostrar uma implementação ativo-ativo-azul-verde.

Um benefício secundário da implementação azul-verde é a capacidade de utilizar a implementação de ativação pós-falha em cada plataforma de cloud como um ambiente de teste para atualizações de microsserviços, antes de as lançar para a implementação de produção.

Passos seguintes