Partilhar via

Escolher um serviço de contêiner do Azure

  • Artigo

O Azure oferece uma variedade de serviços de hospedagem de contêiner 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 aos 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 introdutório e outro artigo sobre as considerações que são comuns a todos os tipos de carga de trabalho.

Observação

Se ainda não estiver comprometido com a conteinerização, consulte para escolher o serviço de computação do Azure e obter informações sobre outras opções de computação que pode usar para hospedar o seu workload.

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 abordagens gerenciadas pela Microsoft. Depois de identificar os serviços candidatos com base nas preferências do modelo de serviço, a próxima etapa é avaliar as opções em relação aos requisitos de carga de trabalho, examinando o artigo sobre considerações compartilhadas para rede, segurança, operações e confiabilidade.

Este guia leva em consideração as compensações que você pode precisar fazer, com base nos requisitos técnicos, tamanho e complexidade da sua carga de trabalho e na experiência da equipe da 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 contentores são comparados:

logótipo das Aplicações de Contentor do Azure

Aplicações de Contentores do Azure é uma plataforma totalmente gerida que permite executar aplicações em contentores sem se preocupar com orquestração ou infraestrutura. Para obter mais informações, consulte documentação dos Aplicativos de Contêiner do Azure.

logótipo AKS

O Azure Kubernetes Service (AKS) é um serviço Kubernetes gerido para executar aplicações em contentores. Com o AKS, você pode aproveitar os complementos e extensões de gerenciados para recursos adicionais, preservando o mais amplo nível de configurabilidade. Para obter mais informações, consulte documentação do AKS.

logotipo do Serviço de Aplicativo

Web App for Containers é 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, patches de segurança, dimensionamento e ferramentas de diagnóstico. Para obter mais informações, consulte a documentação do Serviço de Aplicações.

Para obter uma lista completa de todos os serviços de contêiner do Azure, consulte 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 oferece, em troca de sua simplicidade geral e facilidade de uso.

Para obter uma introdução geral à terminologia e aos 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 proteções e processos apropriados, como patching, 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 de 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 aprendizagem significativa para as equipas 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

Os Aplicativos de Contêiner do Azure são uma camada de abstração sobre o Kubernetes que permite que seus aplicativos sejam executados e dimensionados sem que você precise gerenciar diretamente a infraestrutura subjacente. O Container Apps oferece opções de computação dedicadas e sem servidor, oferecendo controle total sobre o tipo e a quantidade de recursos de computação disponíveis para seus aplicativos. Enquanto abstrai as APIs de orquestração de contêineres, os Aplicativos de Contêiner ainda oferecem acesso imediato a recursos importantes, como entrada na Camada 7, divisão de tráfego, testes A/B e gerenciamento do ciclo de vida do aplicativo.

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 Container Apps. 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:

  • AKS é comumente usado para hospedar várias cargas de trabalho ou componentes de carga de trabalho díspares. 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 Kubernetes. As equipes com menos experiência em Kubernetes ainda podem operar com êxito seus próprios clusters aproveitando os complementos e recursos de gerenciados do Azure, como de atualização automática de cluster, para reduzir a sobrecarga operacional.

  • Aplicações de Contentores devem ser usadas para hospedar uma única carga de trabalho com um limite de segurança compartilhado. As Aplicações de Contêiner têm um único limite lógico de nível superior chamado ambiente de Aplicações de Contêiner, que também serve como um limite de segurança reforçado. 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.

  • Aplicativo Web para Contêineres é um recurso do Serviço de Aplicativo. O App Service agrupa as aplicações num limite de cobrança chamado App Service plan. 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 dentro de 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 PaaS com níveis semelhantes de recursos gerenciados pela Microsoft, o Aplicativo Web para Contêineres enfatiza a simplicidade para atender ao seu público-alvo: os clientes existentes de PaaS do Azure, que acham a interface familiar.

Regra geral

Geralmente, serviços que oferecem mais simplicidade tendem a atender clientes que preferem se concentrar mais no desenvolvimento de recursos e menos na infraestrutura. Serviços que oferecem mais controle tendem a atender clientes que precisam de mais configurabilidade e têm as habilidades, recursos e justificativa de negócios necessários para gerenciar sua própria infraestrutura.

Considerações partilhadas sobre 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 despesas gerais operacionais, mas as equipes de segurança podem considerar esse tipo de sobrecarga necessário para atender aos requisitos de conformidade. As equipes precisam colaborar para fazer as compensações apropriadas.

Esteja ciente de que as considerações compartilhadas são amplas. Apenas um subconjunto pode ser relevante para você, dependendo não apenas do tipo de carga de trabalho, mas também da 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, proporcionando amplo controle sobre o fluxo da rede, mas requer mais esforço operacional. O Container Apps oferece 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 a longo prazo devido aos desafios de alterá-las sem reimplantar cargas de trabalho. Vários fatores, como planejamento de endereços IP, responsabilidades de balanceamento de carga, métodos de descoberta de serviços e recursos de rede privada, diferem entre esses serviços. Você deve analisar cuidadosamente como os serviços atendem aos requisitos específicos de rede.
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 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 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. A escalabilidade e a 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 é da exclusiva responsabilidade 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 investigação de integridade do Aplicativo Web para Contêineres e Aplicativos de Contêiner são mais simplificadas do que as do AKS, já que usam a conhecida API do Azure Resource Manager. 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 despesas gerais adicionais para o AKS.

Além disso, os SLAs para Aplicações de Contêiner e Aplicações Web para Contêineres são mais simples do que os do AKS, para os quais o plano de controlo e os grupos de nós têm os seus próprios SLAs e precisam ser compostos em conformidade. Todos os serviços oferecem redundância de zona nos datacenters que a oferecem.

Depois de analisar as considerações anteriores, você ainda pode não ter encontrado o ajuste perfeito. Isso é perfeitamente normal.

Avaliação de 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 que envolvem pessoas, orçamentos e tempo, todas as soluções têm 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 PaaS como Container Apps, mas escolher AKS porque sua equipe de segurança requer controles de rede negados por padrão entre componentes de carga de trabalho colocalizados, que é um recurso somente AKS que usa políticas 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 cada requisito 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 determinar o nível desejado de controle. O controlo é feito à custa da simplicidade. Em outras palavras, é um processo de encontrar o equilíbrio certo entre uma infraestrutura autogerenciada e uma que é 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 abordam 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.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

Outros contribuidores:

Próximo passo

Saiba mais sobre considerações de arquitetura compartilhada para os serviços mencionados neste artigo.

Considerações arquitetônicas compartilhadas