Escolher um serviço de contêiner do Azure
O Azure oferece uma variedade de serviços de hospedagem de contêineres projetados para acomodar várias cargas de trabalho, arquiteturas e requisitos de negócios. Este guia de seleção de serviço de contêiner pode ajudá-lo a entender qual serviço de contêiner do Azure é mais adequado para seus cenários e requisitos de carga de trabalho.
Observação
Neste guia, o termo carga de trabalho refere-se a uma coleção de recursos de aplicativo que dão suporte a uma meta de negócios ou à execução de um processo de negócios. Uma carga de trabalho usa vários serviços, como APIs e armazenamentos de dados, que trabalham juntos para fornecer funcionalidade específica de ponta a ponta.
Como usar este guia
Este guia inclui dois artigos: este artigo de introdução e outro artigo sobre considerações que são compartilhadas em todos os tipos de carga de trabalho.
Observação
Se você ainda não estiver comprometido com a conteinerização, consulte Escolher um serviço de computação do Azure para obter informações sobre outras opções de computação que você pode usar para hospedar sua carga de trabalho.
Este artigo de introdução descreve os serviços de contêiner do Azure que estão no escopo deste guia e como os modelos de serviço se comparam em termos de compensações entre configurabilidade e soluções opinativas, como abordagens gerenciadas pelo cliente versus gerenciadas pela Microsoft. Depois de identificar os serviços candidatos com base em suas preferências de modelo de serviço, a próxima etapa é avaliar as opções em relação aos requisitos de carga de trabalho, revisando o artigo sobre considerações compartilhadas sobre rede, segurança, operações e confiabilidade.
Este guia leva em consideração as compensações que talvez você precise fazer, com base nos requisitos técnicos, tamanho e complexidade de sua carga de trabalho e na experiência da equipe de sua carga de trabalho.
Serviços de contêiner do Azure no escopo deste guia
Este guia se concentra em um subconjunto dos serviços de contêiner que o Azure oferece atualmente. Esse subconjunto fornece um conjunto de recursos maduro para aplicativos Web e APIs, rede, observabilidade, ferramentas de desenvolvedor e operações. Estes serviços de contêiner são comparados:
Os Aplicativos de Contêiner do Azure são uma plataforma de aplicativo baseada em Kubernetes totalmente gerenciada que ajuda você a implantar aplicativos HTTP e não HTTP de código ou contêineres sem orquestrar a infraestrutura. Para obter mais informações, confira Documentação dos Aplicativos de Contêiner do Azure.
O Serviço de Kubernetes do Azure (AKS) é um serviço Kubernetes gerenciado para executar aplicativos em contêineres. Com o AKS, você pode aproveitar os complementos e extensões gerenciados para recursos adicionais, preservando o nível mais amplo de configurabilidade. Para obter mais informações, consulte a documentação do AKS.
O Aplicativo Web para Contêineres é um recurso do Serviço de Aplicativo do Azure, um serviço totalmente gerenciado para hospedar aplicativos Web baseados em HTTP com manutenção de infraestrutura interna, correção de segurança, dimensionamento e ferramentas de diagnóstico. Para saber mais, confira a Documentação do Serviço de Aplicativo.
Para obter uma lista completa de todos os serviços de contêiner do Azure, consulte a página de categoria de produto de serviços de contêiner.
Considerações sobre o modelo de serviço
O modelo de serviço fornece a visão mais ampla sobre o nível de flexibilidade e controle que qualquer serviço de contêiner do Azure fornece, em troca de sua simplicidade geral e facilidade de uso.
Para obter uma introdução geral sobre a terminologia e os conceitos em torno dos modelos de serviço, incluindo infraestrutura como serviço (IaaS) e plataforma como serviço (PaaS), consulte Responsabilidade compartilhada na nuvem.
Comparando os modelos de serviço das soluções de contêiner do Azure
AKS
Como um híbrido de IaaS e PaaS, o AKS prioriza o controle sobre a simplicidade. Embora o AKS simplifique o gerenciamento da infraestrutura principal subjacente, essa plataforma baseada em VM ainda está exposta aos seus aplicativos e requer guardrails e processos apropriados, como aplicação de patches, para garantir a segurança e a continuidade dos negócios. A infraestrutura de computação é suportada por recursos adicionais do Azure que são hospedados diretamente em sua assinatura, como balanceadores de carga do Azure.
O AKS também fornece acesso ao servidor API do Kubernetes, que permite personalizar a orquestração de contêineres e, assim, implantar projetos da Cloud Native Computing Foundation (CNCF). Consequentemente, há uma curva de aprendizado significativa para equipes de carga de trabalho que são novas no Kubernetes. Se você é novo em soluções conteinerizadas, essa curva de aprendizado pode ser um impedimento. As seguintes soluções de PaaS oferecem uma barreira menor à entrada. Você pode migrar para o Kubernetes quando seus requisitos ditarem essa mudança.
Aplicativos de Contêiner do Azure
Container Apps, uma oferta de PaaS, equilibra o controle com simplicidade. Ele oferece opções de computação sem servidor e dedicadas, que abstraem a necessidade de corrigir o sistema operacional ou construir guardrails em torno de aplicativos, em relação ao sistema operacional. Os Aplicativos de Contêiner também abstraem completamente a API de orquestração de contêiner e fornecem um subconjunto de sua funcionalidade principal por meio das APIs do Azure com as quais sua equipe já pode estar familiarizada. Além disso, a entrada na Camada 7, a divisão de tráfego, os testes A/B e o gerenciamento do ciclo de vida do aplicativo estão totalmente disponíveis prontamente.
Aplicativo Web para Contêineres
O Web App for Containers também é uma oferta de PaaS, mas fornece mais simplicidade e menos controle do que os Aplicativos de Contêiner. Ele abstrai a orquestração de contêineres, mas ainda fornece dimensionamento apropriado, gerenciamento do ciclo de vida do aplicativo, divisão de tráfego, integração de rede e observabilidade.
Considerações sobre o modelo de hospedagem
Você pode usar recursos do Azure, como clusters AKS, para hospedar várias cargas de trabalho. Isso pode ajudá-lo a simplificar as operações e, assim, reduzir o custo geral. Se você escolher esse caminho, aqui estão algumas considerações importantes:
O AKS é comumente usado para hospedar várias cargas de trabalho ou componentes de carga de trabalho diferentes. Você pode isolar essas cargas de trabalho e componentes usando a funcionalidade nativa do Kubernetes, como namespaces, controles de acesso e controles de rede, para atender aos requisitos de segurança.
Você também pode usar o AKS em cenários de carga de trabalho única se precisar da funcionalidade adicional que a API do Kubernetes fornece e sua equipe de carga de trabalho tiver experiência suficiente para operar um cluster do Kubernetes. As equipes com menos experiência no Kubernetes ainda podem operar com êxito seus próprios clusters aproveitando os complementos e recursos gerenciados do Azure, como a atualização automática de cluster, para reduzir a sobrecarga operacional.
Os aplicativos de contêiner devem ser usados para hospedar uma única carga de trabalho com um limite de segurança compartilhado. Os Aplicativos de Contêiner têm um único limite lógico de nível superior chamado de ambiente de Aplicativos de Contêiner, que também serve como um limite de segurança aprimorada. Não há mecanismos para controle de acesso granular adicional. Por exemplo, a comunicação intraambiente é irrestrita e todos os aplicativos compartilham um único espaço de trabalho do Log Analytics.
Se a carga de trabalho tiver vários componentes e vários limites de segurança, implante vários ambientes de Aplicativos de Contêiner ou considere o AKS.
O Aplicativo Web para Contêineres é um recurso do Serviço de Aplicativo . O Serviço de Aplicativo agrupa aplicativos em um limite de cobrança chamado plano do Serviço de Aplicativo. Como você pode definir o escopo do RBAC (controle de acesso baseado em função) no nível do aplicativo, pode ser tentador hospedar várias cargas de trabalho em um único plano. No entanto, recomendamos que você hospede uma única carga de trabalho por plano para evitar o problema do vizinho barulhento. Todos os aplicativos em um único plano do Serviço de Aplicativo compartilham a mesma computação, memória e armazenamento alocados.
Ao considerar o isolamento de hardware, você precisa estar ciente de que os planos do Serviço de Aplicativo geralmente são executados em infraestrutura compartilhada com outros clientes do Azure. Você pode escolher Camadas dedicadas para VMs dedicadas ou Camadas isoladas para VMs dedicadas em uma rede virtual dedicada.
Em geral, todos os serviços de contêiner do Azure podem hospedar vários aplicativos que têm vários componentes. No entanto, os Aplicativos de Contêiner e o Aplicativo Web para Contêineres são mais adequados para um componente de carga de trabalho única ou vários componentes de carga de trabalho altamente relacionados que compartilham um ciclo de vida semelhante, em que uma única equipe possui e executa os aplicativos.
Se você precisar hospedar componentes de aplicativos ou cargas de trabalho diferentes e potencialmente não relacionados em um host, considere o AKS.
A compensação entre controle e facilidade de uso
O AKS fornece a maior capacidade de configuração, mas essa configurabilidade tem o custo de uma maior sobrecarga operacional, em comparação com os outros serviços. Embora os Aplicativos de Contêiner e o Aplicativo Web para Contêineres sejam serviços de PaaS que têm níveis semelhantes de recursos gerenciados pela Microsoft, o Aplicativo Web para Contêineres enfatiza a simplicidade para atender ao seu público-alvo: clientes de PaaS do Azure existentes, que acham a interface familiar.
Regra geral
Geralmente, os serviços que oferecem mais simplicidade tendem a atender aos clientes que preferem se concentrar mais no desenvolvimento de recursos e menos na infraestrutura. Os serviços que oferecem mais controle tendem a atender aos clientes que precisam de mais configurabilidade e têm as habilidades, os recursos e a justificativa de negócios necessários para gerenciar sua própria infraestrutura.
Considerações compartilhadas em todas as cargas de trabalho
Embora uma equipe de carga de trabalho possa preferir um modelo de serviço específico, esse modelo pode não atender aos requisitos da organização como um todo. Por exemplo, os desenvolvedores podem preferir menos sobrecarga operacional, mas as equipes de segurança podem considerar esse tipo de sobrecarga necessária para atender aos requisitos de conformidade. As equipes precisam colaborar para fazer as devidas trocas.
Lembre-se de que as considerações compartilhadas são amplas. Somente um subconjunto pode ser relevante para você, dependendo não apenas do tipo de carga de trabalho, mas também de sua função dentro da organização.
A tabela a seguir fornece uma visão geral de alto nível das considerações, incluindo comparações de recursos de serviço. Analise as considerações em cada categoria e compare-as com os requisitos da sua carga de trabalho.
Categoria | Visão geral |
---|---|
Considerações de rede | A rede nos serviços de contêiner do Azure varia dependendo de sua preferência por simplicidade versus configurabilidade. O AKS é altamente configurável, fornecendo amplo controle sobre o fluxo de rede, mas requer mais esforço operacional. Os Aplicativos de Contêiner oferecem recursos de rede gerenciados pelo Azure. É um meio termo entre o AKS e o Web App for Containers, que é adaptado para clientes que estão familiarizados com o Serviço de Aplicativo. Crucialmente, as decisões de design de rede podem ter consequências de longo prazo devido aos desafios de alterá-las sem reimplantar cargas de trabalho. Vários fatores, como planejamento de endereço IP, responsabilidades de balanceamento de carga, métodos de descoberta de serviço e recursos de rede privada, diferem entre esses serviços. Você deve analisar cuidadosamente como os serviços atendem a requisitos de rede específicos. |
Considerações de segurança | Os Aplicativos de Contêiner, o AKS e o Aplicativo Web para Contêineres fornecem integração com as principais ofertas de segurança do Azure, como o Cofre de Chaves do Azure e identidades gerenciadas. O AKS oferece recursos adicionais, como proteção contra ameaças em tempo de execução e políticas de rede. Embora possa parecer que os serviços de PaaS, como Aplicativos de Contêiner, oferecem menos recursos de segurança, isso ocorre em parte porque mais dos componentes de infraestrutura subjacentes são gerenciados pelo Azure e não estão expostos aos clientes, o que reduz o risco. |
Considerações operacionais | Embora o AKS ofereça mais personalização, ele exige maior entrada operacional. Por outro lado, as soluções de PaaS, como Aplicativos de Contêiner e Aplicativo Web para Contêineres, permitem que o Azure lide com tarefas como atualizações do sistema operacional. Escalabilidade e flexibilidade de SKU de hardware são cruciais. O AKS fornece opções de hardware flexíveis, enquanto os aplicativos de contêiner e o aplicativo Web para contêineres fornecem configurações definidas. A escalabilidade da aplicação no AKS é de responsabilidade exclusiva do cliente. Os aplicativos de contêiner e o aplicativo Web para contêineres oferecem abordagens mais simplificadas. |
Considerações sobre confiabilidade | As configurações de teste de integridade do Aplicativo Web para Contêineres e Aplicativos de Contêiner são mais simplificadas do que as do AKS, já que elas usam a conhecida API do Gerenciador de Recursos do Azure. O AKS requer o uso da API do Kubernetes. Ele também exige que você assuma a responsabilidade adicional de gerenciar a escalabilidade e a disponibilidade do pool de nós do Kubernetes para agendar adequadamente as instâncias do aplicativo. Esses requisitos resultam em sobrecarga adicional para o AKS. Além disso, os SLAs para Aplicativos de Contêiner e Aplicativo Web para Contêineres são mais diretos do que os do AKS, para os quais o plano de controle e os pools de nós têm seus próprios SLAs e precisam ser compostos de acordo. Todos os serviços oferecem redundância de zona nos datacenters que a oferecem. |
Depois de revisar as considerações anteriores, você ainda pode não ter encontrado o ajuste perfeito. Isso é perfeitamente normal.
Avaliando compensações
Escolher um serviço de nuvem não é um exercício simples. Dada a complexidade da computação em nuvem, a colaboração entre muitas equipes e as restrições de recursos envolvendo pessoas, orçamentos e tempo, cada solução tem compensações.
Esteja ciente de que, para qualquer carga de trabalho, alguns requisitos podem ser mais críticos do que outros. Por exemplo, uma equipe de aplicativos pode preferir uma solução de PaaS como Aplicativos de Contêiner, mas escolher AKS porque sua equipe de segurança requer controles de rede de negação por padrão entre componentes de carga de trabalho colocalizados, que é um recurso somente AKS que usa diretivas de rede do Kubernetes.
Por fim, observe que as considerações compartilhadas anteriores incluem os requisitos mais comuns, mas não são abrangentes. É responsabilidade da equipe de carga de trabalho investigar todos os requisitos em relação ao conjunto de recursos do serviço preferido antes de confirmar uma decisão.
Conclusão
Este guia descreve as considerações mais comuns que você enfrenta ao escolher um serviço de contêiner do Azure. Ele foi projetado para orientar as equipes de carga de trabalho na tomada de decisões informadas. O processo começa com a escolha de um modelo de serviço em nuvem, que envolve a determinação do nível de controle desejado. O controle vem às custas da simplicidade. Em outras palavras, é um processo de encontrar o equilíbrio certo entre uma infraestrutura autogerenciada e uma gerenciada pela Microsoft.
Muitas equipes de carga de trabalho podem escolher um serviço de contêiner do Azure exclusivamente com base no modelo de serviço preferido: PaaS versus IaaS. Outras equipes precisam investigar mais para determinar como os recursos específicos do serviço lidam com a carga de trabalho ou os requisitos organizacionais.
Todas as equipes de carga de trabalho devem usar este guia, além de incorporar a devida diligência para evitar decisões difíceis de reverter. Esteja ciente, no entanto, de que a decisão não é confirmada até que os desenvolvedores experimentem o serviço e decidam com base na experiência e não na teoria.
Colaboradores
Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.
Principais autores:
- Andre Dewes - Brasil | Engenheiro de Clientes Sênior
- Marcos Martinez - Brasil | Engenheiro de Serviços Sênior
- Julie Ng - Brasil | Engenheiro Sênior
Outros colaboradores:
- Mick Alberts | Escritor Técnico
- Martin Gjoshevski - Brasil | Engenheiro de Clientes Sênior
- Don Alto | Engenheiro de Clientes Principal
- Nelly Kiboi - Brasil | Engenheiro de Serviços
- Xuhong Liu - Brasil | Engenheiro de Serviços Sênior
- Faisal Mustafa - Brasil | Engenheiro de Clientes Sênior
- Walter Myers - Brasil | Gerente Principal de Engenharia do Cliente
- Sonalika Roy - Brasil | Engenheiro de Clientes Sênior
- Paolo Salvatori | Engenheiro de Clientes Principal
- Victor Santana - Brasil | Engenheiro de Clientes Principal
Próxima etapa
Saiba mais sobre considerações de arquitetura compartilhada para os serviços mencionados neste artigo.