Escolha uma opção de computação do Azure para microsserviços

Este artigo ajuda você a escolher uma plataforma de computação do Azure para uma carga de trabalho criada em uma arquitetura de microsserviços. Uma arquitetura de microsserviços consiste em serviços pequenos e independentemente implantáveis que se comunicam pela rede. Sua plataforma de computação precisa dar suporte a dimensionamento independente, implantação independente e comunicação de intersserviço confiável em muitos serviços.

Para obter fatores de decisão que se aplicam a qualquer carga de trabalho, como habilidades de equipe, rede e portabilidade, consulte Escolher um serviço de computação do Azure. Este artigo se concentra nos fatores que importam especificamente para microsserviços.

Plataformas de computação do Azure para microsserviços

As plataformas do Azure a seguir dão suporte a cargas de trabalho de microsserviços. Eles diferem na quantidade de orquestração, comunicação entre serviços e comportamento de dimensionamento que eles fornecem.

AKS (Serviço de Kubernetes do Azure)

O AKS (Serviço de Kubernetes do Azure) é um serviço gerenciado do Kubernetes que fornece acesso direto às APIs do Kubernetes e ao plano de controle. O AKS oferece gerenciamento dos nós, correção de patches e atualizações automáticas opcionais. Você configura o cluster, a rede e as políticas de dimensionamento.

Para microsserviços, o AKS dá suporte a malhas de serviços como o Istio para gerenciamento de tráfego e mTLS (mutual Transport Layer Security, segurança mútua de camada de transporte), dimensionamento por implantação por meio de Horizontal Pod Autoscaler (HPA) e Kubernetes Event-driven Autoscaling (KEDA), e estratégias de implantação nativas do Kubernetes, como atualizações incrementais e lançamentos canários.

O AKS Automatic é um modo do AKS que preconfigura o gerenciamento, o dimensionamento, a segurança e a observabilidade do nó com base nas recomendações bem arquitetadas do AKS, para que as equipes obtenham um cluster pronto para produção sem necessidade de configuração por capacidade.

Aplicativos de Contêiner do Azure

Os Aplicativos de Contêiner do Azure são um serviço gerenciado criado no Kubernetes que abstrai o gerenciamento de cluster.

Container Apps fornece recursos internos para microsserviços, incluindo descoberta de serviço, integração com Dapr para invocação de serviço a serviço com mTLS, mensagens de publicador-assinante e gerenciamento de estado. O dimensionamento automático baseado em KEDA permite o dimensionamento controlado por eventos, incluindo escala a zero. Os Aplicativos de Contêiner também oferecem suporte à divisão de tráfego nas revisões para implantações canárias e tarefas sob demanda, agendadas ou controladas por eventos.

Os Aplicativos de Contêiner não expõem APIs do Kubernetes. Se as ferramentas de implantação ou a configuração da malha de serviço dependerem dos primitivos do Kubernetes, use o AKS.

Azure Functions

O Azure Functions é um serviço de computação controlado por eventos sem servidor adequado para microsserviços que respondem a gatilhos como solicitações HTTP, mensagens de fila ou temporizadores. O Functions dimensiona cada aplicativo de funções de forma independente e pode ser dimensionado para zero. Para microsserviços, implante cada serviço como seu próprio aplicativo de funções.

As funções não fornecem descoberta de serviço em nível de plataforma ou comunicação entre serviços. Implemente esses recursos no código do aplicativo ou por meio de serviços externos, como o Gerenciamento de API do Azure.

O Functions dá suporte a várias linguagens de programação. Você também pode executar o modelo de programação do Functions em Aplicativos de Contêiner, que combina gatilhos e associações do Functions com recursos de rede e dimensionamento de Aplicativos de Contêiner.

Serviço de Aplicativo do Azure

O Serviço de Aplicativo do Azure atende a microsserviços baseados em HTTP, como APIs Web. O Serviço de Aplicativo dá suporte à implantação como código ou como um único contêiner. Ele fornece dimensionamento automático interno, slots de implantação para implantações azul-verde e roteamento de tráfego baseado em porcentagem e integração com pipelines de CI/CD (integração contínua e entrega contínua). O App Service não fornece descoberta de serviço e, portanto, é adequado para microsserviços que se comunicam por meio de mensagens externas ou um gateway de API, ao invés de depender da comunicação entre serviços no nível da plataforma.

Red Hat OpenShift no Azure

O Red Hat OpenShift do Azure fornece clusters openshift totalmente gerenciados e estende o Kubernetes com uma experiência de desenvolvedor opinativa. A Red Hat e a Microsoft desenvolvem, operam e dão suporte ao serviço em conjunto. Utilize o Red Hat OpenShift do Azure quando sua organização padroniza o uso do OpenShift.

Comparar plataformas para microsserviços

A tabela a seguir compara como cada plataforma dá suporte aos recursos que importam para uma arquitetura de microsserviços. Para obter uma comparação mais detalhada das plataformas de hospedagem de contêineres do Azure e suas funcionalidades, consulte Escolher um serviço de contêiner do Azure.

Capability AKS Aplicativos de Contêiner Functions Serviço de Aplicativo
Descoberta de serviço DNS (Sistema de Nomes de Domínio do Kubernetes), malha de serviço Integrado, Dapr Nenhum (nível do aplicativo) Nenhum (nível do aplicativo)
Comunicação entre serviços Malha de serviço (Istio) Dapr, nível do ambiente Nenhum (nível do aplicativo) Nenhum (nível do aplicativo)
Mensagens do publicador-assinante Nível do aplicativo (como o Barramento de Serviço do Azure, Hubs de Eventos do Azure) Dapr pub/sub Vinculações Nível da aplicação
Dimensionamento independente Por implantação (HPA, KEDA) Por aplicativo (KEDA) Aplicativo por função (por função no Flex) Plano de serviço Per-App
Escala para zero Parcial (somente pools de nós do usuário) Yes Sim (planos de consumo ou consumo flex) No
Mitigação de inicialização a frio Contagem mínima de nós, mínimas réplicas de pods Contagem mínima de réplicas Instâncias pré-aquecidas ou sempre prontas (Consumo Premium ou Flex) Não aplicável (Always On)
Divisão de tráfego e implantações canárias Malha de serviço nativa do Kubernetes Baseado em revisão Slots para implantação (Premium/Dedicado) Slots de implantação que incluem roteamento de tráfego
Rastreamento distribuído OpenTelemetry, ferramentas de software livre Rastreamento integrado do Dapr Application Insights Application Insights
Serviços com estado Volumes persistentes, StatefulSets Montagens de volume, estado Dapr Funções duráveis Montagem de Arquivos do Azure
Identidade por serviço Identidade da carga de trabalho Identidade gerenciada Identidade gerenciada Identidade gerenciada
Acesso à API do Kubernetes Yes No No No
Implantabilidade independente Sim (por pod ou por implantação) Sim (aplicativo por contêiner) Sim (aplicativo por função) Sim (slot por aplicativo ou por slot de implantação)
Executa contêineres Yes Yes Yes Yes
Executa o código sem contêineres No No Yes Yes

O nível do aplicativo nesta tabela significa que a plataforma não fornece a funcionalidade como um recurso interno. Implemente-o no código do aplicativo por meio de um SDK ou um serviço externo, que introduz uma dependência desse serviço.

Note

Esta tabela não inclui o Red Hat OpenShift do Azure. Ele fornece a API completa do Kubernetes, portanto, seus principais recursos de microsserviços, como dimensionamento por implantação, descoberta de serviço e atualizações sem interrupção, são comparáveis ao AKS.

As plataformas diferem em suas ferramentas operacionais, não em seus principais recursos de microsserviços. Por exemplo, o AKS fornece Dapr e KEDA como complementos gerenciados, mas no OpenShift, você mesmo instala e os mantém. Para obter mais informações, consulte a documentação do Red Hat OpenShift no Azure.

Escolher a sua plataforma

  • Comece com Os Aplicativos de Contêiner quando quiser primitivos de microsserviços internos, como descoberta de serviço, Dapr e dimensionamento por aplicativo que inclua escala a zero, sem gerenciamento de cluster.

  • Escolha o AKS quando precisar de acesso direto à API do Kubernetes, configuração de malha de serviço personalizada ou controle refinado sobre a infraestrutura de cluster, como pools de nós, políticas de rede ou restrições de agendamento.

  • Use funções para microsserviços controlados por eventos que têm padrões de tráfego esporádicos ou de pico repentino que se beneficiam da cobrança com escala até zero e da execução acionada por gatilho.

  • Use o Serviço de Aplicativo para serviços diretos baseados em HTTP que não precisam de recursos de descoberta de serviço ou comunicação entre serviços no nível da plataforma.

Sua carga de trabalho de microsserviços não precisa ser executada em uma única plataforma. Por exemplo, você pode executar serviços principais no AKS ou aplicativos de contêiner enquanto o Functions lida com cargas de trabalho controladas por eventos. Avalie cada serviço em sua composição em relação a seu próprio padrão de tráfego, requisitos de dimensionamento e necessidades de comunicação. Escolha a plataforma que se ajusta a esse serviço em vez de forçar o serviço a se ajustar à plataforma.

Principais fatores de decisão

A tabela de comparação mostra o que cada plataforma dá suporte. As seções a seguir ajudam você a avaliar esses recursos com base nos quais os microsserviços são mais importantes para sua carga de trabalho.

Comunicação entre serviços

Os microsserviços dependem de uma comunicação de serviço a serviço confiável, com recursos como descoberta de serviço, tentativas de reconexão e mTLS.

Se sua arquitetura depender de chamadas síncronas de serviço a serviço em muitos serviços, priorize uma plataforma que tenha primitivos de comunicação internos. Container Apps fornece esses primitivos por meio do Dapr sem infraestrutura extra. O AKS fornece essas funcionalidades por meio de malhas de serviço, como o Istio, que dão controle sobre políticas de tráfego, repetições e quebras de circuito no nível da malha. Você gerencia o ciclo de vida da malha, a configuração e as atualizações.

Se seus serviços se comunicarem principalmente por meio de mensagens assíncronas, como filas ou fluxos de eventos, os recursos de comunicação internos da plataforma importam menos porque você precisa interagir com esses serviços por meio de um SDK ou uma abstração. Utilize o padrão de Solicitação-Resposta assíncrono para operações de execução longa porque os tempos limite da plataforma podem se tornar um problema. Por exemplo, Funções e Serviço de Aplicativo impõem um tempo limite de resposta HTTP de 230 segundos devido aos limites do Azure Load Balancer.

Dimensionamento independente

Cada microsserviço em uma composição tem características de carga diferentes.

Se seus serviços tiverem tráfego altamente variável ou de pico repentino, os Aplicativos de Contêiner e as Funções serão dimensionados por serviço e poderão dimensionar os serviços ociosos para zero. Essa abordagem evita encargos de capacidade não utilizados. Para o Functions, cada aplicativo de funções é a unidade de dimensionamento, portanto, implante cada microsserviço como seu próprio aplicativo de funções. O AKS fornece dimensionamento por implantação. Você gerencia pools de nós compartilhados que permanecem provisionados, e os pools de nós de usuário podem ser redimensionados para zero.

As plataformas de escala para zero introduzem latência de início frio quando um serviço ocioso recebe sua primeira solicitação. Em uma arquitetura de microsserviços, uma única solicitação de usuário pode percorrer vários serviços. Se vários serviços na cadeia de chamadas estiverem frios, a latência se acumula. Para chamadas de interserviço síncronas que exigem baixa latência, use os recursos de mitigação de início a frio da plataforma ou pague o custo para manter as instâncias mínimas ativas para evitar inícios a frio.

Se seus serviços tiverem uma carga estável e previsível, o AKS ou o Serviço de Aplicativo poderão reduzir os custos porque você paga pela capacidade reservada em vez de cobrança baseada em consumo.

Implantabilidade independente

Você precisa implantar, atualizar e reverter microsserviços individuais sem afetar o restante do sistema. Todas as quatro plataformas dão suporte à implantabilidade independente, mas elas diferem na forma como você valida as alterações. Os Aplicativos de Contêiner e o AKS fornecem divisão de tráfego nativamente para distribuições graduais. O Serviço de Aplicativo dá suporte ao roteamento de tráfego baseado em porcentagem entre slots de implantação. O Functions dá suporte a slots de implantação em planos Premium e Dedicados.

Observabilidade distribuída

Uma única solicitação de usuário pode percorrer muitos serviços. Se você precisar de rastreamentos correlacionados em toda a cadeia de chamadas completa, verifique se as ferramentas de observabilidade da plataforma se integram à sua estratégia de rastreamento. Container Apps fornece observabilidade integrada com o rastreamento de Dapr. O AKS integra-se ao OpenTelemetry e a ferramentas de rastreamento de código aberto, permitindo que você escolha o back-end de rastreamento (como Jaeger, Zipkin ou Azure Monitor), mas exige que você implante e configure o pipeline de coleta. As funções e o Serviço de Aplicativo integram-se ao Application Insights para rastreamento de transações de ponta a ponta com configuração mínima.

Verifique se cada serviço na composição expõe métricas por serviço, como taxa de solicitação, taxa de erro e latência. Essas métricas ajudam a identificar quais serviços são degradados sem correlacionar logs na cadeia de chamadas completa.

Gerenciamento de estado

Em uma arquitetura de microsserviços, cada serviço normalmente possui seus dados e externaliza o estado para um banco de dados ou cache dedicado. Esse padrão mantém os serviços implantáveis de forma independente e todas as quatro plataformas dão suporte a ele igualmente porque o armazenamento de dados é um recurso separado do Azure.

As plataformas diferem quando um serviço precisa de abstrações de estado gerenciadas pela plataforma, como padrões baseados em ator, orquestração de fluxo de trabalho ou armazenamento dedicado por instância:

  • O AKS fornece a maior flexibilidade por meio de volumes persistentes e StatefulSets, que dão suporte a armazenamentos de dados no cluster e identidade estável por instância.

  • Os Container Apps oferecem suporte a montagens de volume e gerenciamento de estado Dapr, incluindo atores Dapr.

  • O Functions dá suporte a orquestrações e entidades com estado por meio de Durable Functions.

  • O Serviço de Aplicativo dá suporte ao armazenamento compartilhado por meio de montagens de Arquivos do Azure, mas não fornece abstrações de estado de nível de plataforma ou armazenamento por instância.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que você pode usar para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Well-Architected Framework.

Confiabilidade

A confiabilidade ajuda a garantir que seu aplicativo possa cumprir os compromissos que você faz aos seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design para confiabilidade.

Em uma arquitetura de microsserviços, o principal risco de confiabilidade é a falha em cascata. Um serviço não saudável faz com que os chamadores acumulem timeouts, e o problema se propaga ao longo da cadeia de chamadas. Sua escolha de plataforma afeta a maneira como você reduz esse risco.

  • O AKS e os Aplicativos de Contêiner fornecem probes de integridade no nível da plataforma que detectam instâncias com problemas e automaticamente as removem da rotação.

  • As funções repetem execuções com falha com base no tipo de gatilho.

Independentemente da plataforma, implemente disjuntores, políticas de repetição com retirada e tempos limite em sua comunicação de intersserviço para evitar que uma única falha de serviço se torne uma interrupção em todo o sistema.

Implante cada serviço entre zonas de disponibilidade para proteger contra falhas no nível do datacenter. Em uma composição de plataforma mista, verifique se todas as plataformas em uso suportam a redundância de zona para sua região de implantação.

Para obter diretrizes de confiabilidade específicas da plataforma, consulte as seções de confiabilidade dos guias de serviço do Well-Architected Framework para AKS, Aplicativos de Contêiner e Funções.

Segurança

A segurança fornece garantias contra ataques deliberados e o uso indevido de seus valiosos dados e sistemas. Para obter mais informações, consulte Lista de verificação de revisão de design para segurança.

Os microsserviços aumentam a superfície de ataque porque cada chamada serviço a serviço cruza um limite de rede. Trate todo o tráfego de intersserviço como não confiável e criptografe-o por meio do mTLS. O AKS dá suporte ao mTLS por meio de malhas de serviço como o Istio. Os Aplicativos de Contêiner fornecem mTLS por meio de Dapr ou configuração em nível de ambiente. As funções e o Serviço de Aplicativo não fornecem mTLS no nível da plataforma. Se essas plataformas hospedarem serviços em sua arquitetura, imponha a segurança de transporte por meio de HTTPS na camada de aplicação, políticas de gateway de API ou isolamento de rede virtual.

Em uma composição de muitos serviços, cada serviço deve se autenticar apenas para os recursos necessários. Atribua identidades por serviço em vez de compartilhar uma única identidade na carga de trabalho. Para mecanismos específicos da plataforma, consulte a linha de identidade por serviço na tabela de comparação.

Para obter diretrizes de segurança específicas da plataforma, consulte as seções de segurança dos guias de serviço do Well-Architected Framework para AKS, Aplicativos de Contêiner e Funções.

Otimização de custos

A Otimização de Custos concentra-se em maneiras de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Lista de verificação de revisão de design para otimização de custos.

Uma arquitetura de microsserviços pode incluir dezenas de serviços e cada serviço lida com volumes de tráfego diferentes. Corresponda cada serviço ao modelo de cobrança que se ajusta ao seu padrão de tráfego. Plataformas baseadas em consumo, como Aplicativos de Contêiner e Funções, dimensionam os serviços ociosos para zero, mas a computação dedicada, como o AKS, pode ser mais econômica para serviços que têm carga sustentada. Em uma composição de plataforma mista, a flexibilidade de cobrança por serviço é uma das principais vantagens de custo. No entanto, considere a sobrecarga de manter pipelines de implantação separados, configurações de monitoramento e a experiência da equipe em várias plataformas.

Para obter diretrizes de custo específicas da plataforma, consulte as seções de otimização de custo dos guias de serviço do Well-Architected Framework para AKS, Aplicativos de Contêiner e Funções.

Arquiteturas de referência

Restrinja suas opções a uma ou duas plataformas aplicando os critérios de comparação neste artigo. Execute uma prova de conceito implantando um subconjunto representativo de seus serviços e testando a comunicação entre serviços, o comportamento de dimensionamento e os fluxos de trabalho de implantação em relação às suas necessidades. Confirme se a plataforma atende às expectativas operacionais da sua equipe antes de você se comprometer com a produção. As arquiteturas a seguir fornecem pontos de partida prontos para produção:

Próxima etapa

Criar comunicação entre serviços para microsserviços

  • Last updated on