Escolha uma opção de computação do Azure para microsserviços
O termo computação refere-se ao modelo de alojamento dos recursos de computação em que a aplicação é executada. Para uma arquitetura de microsserviços, duas abordagens são especialmente populares:
- Um orquestrador de serviços que gerencia serviços executados em nós dedicados (VMs).
- Uma arquitetura sem servidor usando funções como serviço (FaaS).
Embora essas não sejam as únicas opções, ambas são abordagens comprovadas para a criação de microsserviços. Uma aplicação pode incluir ambas as abordagens.
Orquestradores de serviço
Um orquestrador lida com tarefas relacionadas à implantação e ao gerenciamento de um conjunto de serviços. Essas tarefas incluem colocar serviços em nós, monitorar a integridade dos serviços, reiniciar serviços não íntegros, balancear a carga do tráfego de rede entre instâncias de serviço, descoberta de serviços, dimensionar o número de instâncias de um serviço e aplicar atualizações de configuração. Orquestradores populares incluem Kubernetes, Service Fabric, DC/OS e Docker Swarm.
Na plataforma Azure, considere as seguintes opções:
O Azure Kubernetes Service (AKS) é um serviço Kubernetes gerido. O AKS provisiona o Kubernetes e expõe os pontos de extremidade da API do Kubernetes, mas hospeda e gerencia o plano de controle do Kubernetes, executando atualizações automatizadas, patches automatizados, dimensionamento automático e outras tarefas de gerenciamento. Você pode pensar no AKS como sendo "APIs do Kubernetes como um serviço".
Os Aplicativos de Contêiner do Azure são um serviço gerenciado criado no Kubernetes que abstrai as complexidades da orquestração de contêineres e outras tarefas de gerenciamento. O Container Apps simplifica a implantação e o gerenciamento de aplicativos e microsserviços em contêineres em um ambiente sem servidor, ao mesmo tempo em que fornece os recursos do Kubernetes.
O Service Fabric é uma plataforma de sistemas distribuídos para empacotamento, implantação e gerenciamento de microsserviços. Os microsserviços podem ser implantados no Service Fabric como contêineres, executáveis binários ou como Serviços Confiáveis. Usando o modelo de programação de Serviços Confiáveis, os serviços podem usar diretamente as APIs de programação do Service Fabric para consultar o sistema, relatar a integridade, receber notificações sobre alterações de configuração e código e descobrir outros serviços. Uma diferenciação importante com o Service Fabric é seu forte foco na criação de serviços com estado usando coleções confiáveis.
Outras opções, como o Docker Enterprise Edition, podem ser executadas em um ambiente IaaS no Azure. Você pode encontrar modelos de implantação no Azure Marketplace.
Contentores
Às vezes, as pessoas falam de contêineres e microsserviços como se fossem a mesma coisa. Embora isso não seja verdade — você não precisa de contêineres para criar microsserviços — os contêineres têm alguns benefícios que são particularmente relevantes para os microsserviços, como:
Portabilidade. Uma imagem de contêiner é um pacote autônomo que é executado sem a necessidade de instalar bibliotecas ou outras dependências. Isso os torna fáceis de implantar. Os contêineres podem ser iniciados e interrompidos rapidamente, para que você possa criar novas instâncias para lidar com mais carga ou para se recuperar de falhas de nó.
Densidade. Os contêineres são leves em comparação com a execução de uma máquina virtual, porque compartilham recursos do sistema operacional. Isso torna possível empacotar vários contêineres em um único nó, o que é especialmente útil quando o aplicativo consiste em muitos serviços pequenos.
Isolamento de recursos. Você pode limitar a quantidade de memória e CPU disponível para um contêiner, o que pode ajudar a garantir que um processo descontrolado não esgote os recursos do host. Consulte o padrão Antepara para obter mais informações.
Sem servidor (Funções como um serviço)
Com uma arquitetura sem servidor, você não gerencia as VMs ou a infraestrutura de rede virtual. Em vez disso, você implanta o código e o serviço de hospedagem lida com a colocação desse código em uma VM e a sua execução. Essa abordagem tende a favorecer pequenas funções granulares que são coordenadas usando gatilhos baseados em eventos. Por exemplo, uma mensagem sendo colocada em uma fila pode acionar uma função que lê da fila e processa a mensagem.
O Azure Functions é um serviço de computação sem servidor que dá suporte a vários gatilhos de função, incluindo solicitações HTTP, filas do Barramento de Serviço e eventos de Hubs de Eventos. Para obter uma lista completa, consulte Conceitos de acionadores e associações do Azure Functions. Considere também a Grade de Eventos do Azure, que é um serviço de roteamento de eventos gerenciado no Azure.
Orquestrador ou sem servidor?
Aqui estão alguns fatores a serem considerados ao escolher entre uma abordagem orquestradora e uma abordagem sem servidor.
Capacidade de gerenciamento Um aplicativo sem servidor é fácil de gerenciar, porque a plataforma gerencia todos os recursos de computação para você. Embora um orquestrador abstraia alguns aspetos do gerenciamento e configuração de um cluster, ele não oculta completamente as VMs subjacentes. Com um orquestrador, você precisará pensar em questões como balanceamento de carga, uso de CPU e memória e rede.
Flexibilidade e controlo. Um orquestrador lhe dá um grande controle sobre a configuração e o gerenciamento de seus serviços e do cluster. A contrapartida é a complexidade adicional. Com uma arquitetura sem servidor, você abre mão de algum grau de controle porque esses detalhes são abstratos.
Portabilidade. Todos os orquestradores listados aqui (Kubernetes, DC/OS, Docker Swarm e Service Fabric) podem ser executados no local ou em várias nuvens públicas.
Integração de aplicações. Pode ser um desafio criar um aplicativo complexo usando uma arquitetura sem servidor, devido à necessidade de coordenar, implantar e gerenciar muitas pequenas funções independentes. Uma opção no Azure é usar os Aplicativos Lógicos do Azure para coordenar um conjunto de Funções do Azure. Para obter um exemplo dessa abordagem, consulte Criar uma função que se integra aos Aplicativos Lógicos do Azure.
Custo. Com um orquestrador, você paga pelas VMs que estão sendo executadas no cluster. Com um aplicativo sem servidor, você paga apenas pelos recursos de computação reais consumidos. Em ambos os casos, você precisa considerar o custo de quaisquer serviços adicionais, como armazenamento, bancos de dados e serviços de mensagens.
Escalabilidade. O Azure Functions é dimensionado automaticamente para atender à demanda, com base no número de eventos de entrada. Com um orquestrador, você pode expandir aumentando o número de instâncias de serviço em execução no cluster. Você também pode dimensionar adicionando VMs adicionais ao cluster.
Nossa implementação de referência usa principalmente o Kubernetes, mas usamos o Azure Functions para um serviço, ou seja, o serviço Histórico de Entrega. O Azure Functions foi uma boa opção para este serviço específico, porque é uma carga de trabalho orientada por eventos. Usando um gatilho de Hubs de Eventos para invocar a função, o serviço precisava de uma quantidade mínima de código. Além disso, o serviço Histórico de Entrega não faz parte do fluxo de trabalho principal, portanto, executá-lo fora do cluster do Kubernetes não afeta a latência de ponta a ponta das operações iniciadas pelo usuário.