Opções de computação em nuvem

Uma máquina virtual (VM) é um computador definido por software. Ela tem processadores virtuais, memória, discos, uma conexão de rede e seu próprio sistema operacional. Um hipervisor divide um servidor físico entre VMs e as mantém isoladas. Uma VM na nuvem em execução também é chamada de instância.

Escolha os recursos

Os serviços principais são Amazon EC2, Azure Virtual Machines e Google Compute Engine. Cada um aluga infraestrutura para você; você gerencia o sistema operacional e a aplicação. Isso é infraestrutura como serviço (IaaS).

Iniciar uma VM envolve várias escolhas relacionadas:

• Local: uma região e, onde disponível, uma zona de disponibilidade.
• Imagem: um modelo que contém o sistema operacional e software pré-instalado. A AWS a chama de Amazon Machine Image (AMI); Azure e Google oferecem imagens públicas e personalizadas.
• Tamanho: as vCPUs, a memória e a capacidade relacionada. Uma vCPU é a unidade de processamento atribuída à VM.
• Disco: armazenamento persistente a partir do qual o sistema operacional é inicializado.
• Rede: uma interface em uma sub-rede, além de regras de tráfego. Um endereço IP público é opcional.

A AWS usa volumes EBS, sub-redes VPC e grupos de segurança. O Azure usa discos gerenciados, sub-redes VNet e grupos de segurança de rede. O Google usa discos persistentes, sub-redes VPC e regras de firewall. Os nomes são diferentes, mas os recursos têm funções comparáveis.

Acompanhe uma decisão de inicialização

Uma equipe precisa de um servidor web Linux em Frankfurt. Ela seleciona a região Europa (Frankfurt), uma AMI do Ubuntu e m7g.large, com 2 vCPUs e 8 GiB de memória. Ela adiciona um volume de inicialização EBS de 30 GiB e conecta a VM a uma sub-rede VPC. Seu grupo de segurança permite HTTPS na porta 443 a partir da internet e SSH na porta 22 somente a partir da rede do escritório. A imagem fornece o ponto de partida do software; o tamanho fornece capacidade de computação; as regras de tráfego determinam quem pode se conectar.

Acompanhe o ciclo de vida e a cobrança

Uma VM é criada, executada, pode ser parada e iniciada e, por fim, é excluída. Cobranças de computação são geradas enquanto ela está alocada para execução, mesmo que o uso de CPU esteja perto de zero. Parar a VM normalmente encerra as cobranças de computação, mas discos retidos e endereços IP públicos reservados ainda podem gerar custos. No Azure, verifique se aparece “Stopped (deallocated)”: desligar dentro do sistema operacional convidado pode deixar a VM em “Stopped”, com a computação ainda sendo cobrada.

Discos locais temporários são diferentes de discos de inicialização persistentes. O instance store da AWS, os discos temporários do Azure e o Local SSD do Google mantêm dados no host físico; parar, mover ou desalocar uma VM pode causar a perda desses dados. Coloque os arquivos que precisam ser preservados em armazenamento persistente. Depois de excluir uma VM, revise os recursos cobrados que foram mantidos. Um grupo de segurança por si só não tem cobrança separada, enquanto um disco não excluído pode continuar gerando cobrança.

Saiba quem faz a manutenção

O provedor mantém o centro de dados, o hardware físico e o hipervisor. Você aplica atualizações ao sistema operacional convidado, atualiza o software instalado, protege os dados e gerencia o acesso e as configurações de firewall. Alugar uma VM não transfere ao provedor a aplicação de atualizações ao sistema convidado.

Um host dedicado reserva um servidor físico para seu uso, o que é útil para licenças vinculadas a núcleos físicos. Uma instância em hardware físico direto expõe o hardware sem uma camada de hipervisor. Já o Azure Virtual Desktop e o Amazon WorkSpaces transmitem desktops hospedados na nuvem para os dispositivos dos usuários.

Uma família de instâncias define o equilíbrio entre processamento, memória, armazenamento e aceleradores. Seu tamanho determina quanto desses recursos você recebe. Escolha a família conforme a principal necessidade da carga de trabalho e depois escolha um tamanho que atenda a todos os seus requisitos.

Reconheça as principais famílias

Armazenamento local rápido não torna os dados persistentes. Uma carga de trabalho que usa instâncias otimizadas para armazenamento ainda precisa de um plano para dados que devem sobreviver à perda do host.

Leia o nome

Em m7g.large, m significa uso geral, 7 é a geração, g indica AWS Graviton e large é o tamanho. A mesma família cresce de 2 vCPUs e 8 GiB em large para 4 vCPUs e 16 GiB em xlarge, e depois para 8 vCPUs e 32 GiB em 2xlarge.

Em Standard_D4s_v5 do Azure, D é a família, 4 é a quantidade de vCPUs, s indica suporte a SSD premium e v5 é a versão. O e2-standard-4 do Google identifica a série E2, a proporção padrão de memória e 4 vCPUs. Uma vCPU muitas vezes é uma thread de hardware; no Graviton, é um núcleo inteiro. Não trate a vCPU de todos os provedores como um núcleo físico idêntico.

Analise uma escolha de dimensionamento

Uma aplicação interna de relatórios precisa de 2 vCPUs e 6 GiB no pico. Compare estes tamanhos da AWS:

• c7g.large: 2 vCPUs e 4 GiB; a memória é insuficiente.
• m7g.large: 2 vCPUs e 8 GiB; atende aos dois requisitos, com 2 GiB de sobra.
• r7g.large: 2 vCPUs e 16 GiB; fornece muito mais memória do que essa aplicação precisa.

O tamanho de uso geral é um ponto de partida sensato. Sua memória por vCPU é $8÷2=4$ GiB. As opções otimizadas para computação e para memória fornecem 2 e 8 GiB por vCPU, respectivamente. Os tipos E2 highcpu, standard e highmem de 4 vCPUs do Google também variam em memória: 4 GB, 16 GB e 32 GB.

Dimensionamento adequado significa medir o uso real e ajustar a escolha. Examine o uso de memória, disco e rede junto com o de CPU antes de reduzir o tamanho. O AWS Compute Optimizer, o Azure Advisor e as recomendações de tipos de máquina do Google podem ajudar. Alterar o tamanho de uma VM existente exige uma parada ou reinicialização, então planeje uma interrupção para uma aplicação em um único servidor.

Diferencie picos de interrupção

Os tipos de desempenho expansível AWS T, Azure B e Google E2 de núcleo compartilhado são adequados para cargas tranquilas com picos curtos. AWS T e Azure B acumulam créditos de CPU abaixo de um nível básico e os usam acima dele. Quando os créditos acabam, o Azure B e o AWS T no modo padrão retornam ao nível básico; os tipos AWS T atuais usam o modo ilimitado por padrão e podem cobrar pelo excedente de CPU.

VMs spot usam capacidade excedente que o provedor pode retomar com pouco aviso. Elas são adequadas para trabalho em lote que pode ser reiniciado e tem o progresso salvo. Um único banco de dados de produção é uma escolha inadequada. As VMs preemptíveis mais antigas do Google também têm duração máxima de 24 horas; esse limite não é a regra que define as VMs spot atuais.

Um serviço enfrenta dois problemas diferentes: a chegada de mais trabalho e a falha de equipamentos. O escalonamento altera a capacidade. A alta disponibilidade mantém o serviço utilizável quando componentes falham. Um projeto pode resolver um problema e deixar o outro sem solução.

Altere o tamanho ou a quantidade

O escalonamento vertical altera o tamanho de uma máquina: por exemplo, 2 vCPUs e 8 GiB passam a 8 vCPUs e 32 GiB. O aumento vertical adiciona recursos; a redução vertical os remove. É uma forma direta de dar mais capacidade a uma aplicação existente, mas a máquina geralmente precisa reiniciar, o maior tamanho é limitado e a máquina continua sendo um ponto de falha.

O escalonamento horizontal altera o número de cópias. Três servidores web podem se tornar nove e depois voltar a três. O aumento horizontal adiciona instâncias; a redução horizontal as remove. Um balanceador de carga distribui requisições web, enquanto processos em segundo plano podem receber tarefas de uma fila compartilhada. A aplicação deve permitir que várias cópias trabalhem juntas de forma útil. Um banco de dados compartilhado ainda pode limitar a vazão ou falhar mesmo quando muitos servidores web continuam íntegros.

Escalabilidade é a capacidade de lidar com mais trabalho por meio da adição de recursos. Elasticidade é o aumento e a redução automáticos e oportunos conforme a demanda muda. Uma loja que passa automaticamente de 4 servidores à noite para 20 durante uma promoção é elástica. Um conjunto fixo com capacidade excedente pode ter alta disponibilidade sem ser elástico.

Torne as cópias substituíveis

Uma instância de aplicação sem estado não mantém dados exclusivos necessários para uma requisição posterior. Armazene carrinhos, sessões e arquivos enviados em um banco de dados, cache ou serviço de armazenamento compartilhado. Assim, uma requisição pode chegar a qualquer instância, e a redução horizontal pode remover uma delas sem perder os carrinhos dos usuários.

Por exemplo, um carrinho mantido apenas na memória de um servidor web desaparece quando esse servidor é encerrado. Manter o usuário nesse servidor com afinidade de sessão não protege o carrinho contra a falha do servidor. Mover o carrinho para armazenamento compartilhado muda o que pode ser removido com segurança.

Mantenha capacidade suficiente após a falha de uma zona

Zonas de disponibilidade são locais separados dentro de uma região com energia, refrigeração e rede independentes. Distribuir instâncias entre zonas protege contra a falha de uma zona inteira. Várias instâncias em uma única zona ainda compartilham o risco dessa zona.

Suponha que uma aplicação deva manter a capacidade de 4 instâncias após perder qualquer uma de 3 zonas. Cada uma das duas zonas restantes deve fornecer 2 instâncias:

Execute 2 instâncias em cada zona, totalizando 6. A perda de qualquer zona deixa 4. Essa é uma capacidade excedente para falhas, não um aumento da necessidade normal da carga de trabalho. Um balanceador de carga direciona as requisições às instâncias restantes; qualquer serviço de dados compartilhado também precisa de disponibilidade adequada.

Reconheça os conjuntos de disponibilidade do Azure

Um conjunto de disponibilidade distribui VMs dentro de um centro de dados entre domínios de falha de hardware e domínios de atualização de manutenção. Um domínio de falha compartilha hardware como energia e comutadores de rede. Os conjuntos aceitam até 3 domínios de falha; os domínios de atualização são 5 por padrão e podem chegar a 20. Eles reduzem os riscos de falha de rack e reinicialização planejada. As zonas tratam do risco maior de um centro de dados inteiro ficar indisponível.

O escalonamento automático adiciona e remove instâncias conforme a demanda muda. O Amazon EC2 Auto Scaling usa grupos Auto Scaling, o Azure usa Virtual Machine Scale Sets com regras de escalonamento automático, e o Google usa grupos de instâncias gerenciadas com um escalonador automático.

Comece com um modelo reproduzível

Uma nova instância precisa da mesma imagem, tamanho, configurações de rede e instruções de inicialização que as demais. A AWS usa um modelo de execução, o Azure usa um modelo de VM do conjunto de dimensionamento e o Google usa um modelo de instância. Uma alteração feita manualmente dentro de uma VM em execução desaparecerá quando ela for substituída, a menos que esteja incluída na configuração reproduzível.

O grupo tem três configurações de capacidade:

• Mínima: o piso que o grupo mantém.
• Desejada: a quantidade que ele busca executar no momento.
• Máxima: o teto que ele não deve ultrapassar.

Com mínimo 2, desejado 4 e máximo 10, o grupo busca manter 4 instâncias. As políticas podem alterar a capacidade desejada entre 2 e 10. O máximo permite crescer; defini-lo como 10 não executa nem cobra 10 VMs por si só. Ele limita a quantidade de instâncias, não todas as cobranças da aplicação.

Escolha o que provoca uma mudança

O acompanhamento de meta tenta manter uma métrica próxima de uma meta, como uso médio de CPU de 50%. O escalonamento por etapas ou por regras altera a capacidade quando um limite é ultrapassado, como adicionar 2 instâncias depois que a CPU permanece acima de 70% por 5 minutos. O escalonamento programado define a capacidade em horários conhecidos. O escalonamento preditivo prevê a demanda com base em padrões anteriores e prepara a capacidade com antecedência.

Um pico diário às 08:00 favorece a preparação de instâncias antes das 08:00. Esperar por um alerta de CPU alta significa que o pico já chegou enquanto as VMs adicionais ainda estão iniciando.

Calcule a capacidade para acompanhamento de meta

Quatro instâncias idênticas têm média de 80% de CPU, e a meta é 50%. Para uma estimativa simplificada com carga constante, primeiro some o trabalho em unidades de pontos percentuais de CPU por instância:

Divida pela meta por instância:

Arredonde para cima para 7 instâncias, pois 6 deixariam a média acima da meta. Com 7, a estimativa é $320÷7\approx \mathrm{45,7}\mathrm{\%}$. Se o máximo do grupo for 6, ele para nesse número e a média fica em cerca de 53,3%.

Diferencie prontidão de recuperação de falhas

Uma VM precisa de tempo para inicializar, executar suas tarefas de inicialização e passar nas verificações de integridade. O aquecimento impede que medições incompletas de uma nova instância distorçam uma decisão de escalonamento. Um período de estabilização limita mudanças rápidas de um lado para outro.

Grupos de escalonamento também podem substituir VMs com falha para restaurar a capacidade desejada. Verificações no nível da aplicação e ações de reparo precisam ser configuradas: uma VM pode estar em execução enquanto sua aplicação web está com defeito. No Azure, uma ação de reparo pode reiniciar, reinstalar a imagem ou substituir; o Google chama a recuperação de reparo automático. Um balanceador de carga pode detectar uma aplicação com defeito, mas o grupo de escalonamento precisa ser configurado para usar essa informação no reparo.

A redução horizontal remove instâncias. Mantenha registros em um local central e dados duradouros fora dos arquivos locais das instâncias para que a remoção de uma cópia íntegra não elimine informações exclusivas.

Um balanceador de carga fornece aos clientes um endereço de entrada e encaminha o tráfego recebido para servidores íntegros. A AWS chama o conjunto de servidores de grupo de destino; o Azure usa pool de back-end; o Google usa serviço de back-end. Os clientes não precisam de um novo endereço sempre que o conjunto muda.

Roteie o tráfego e detecte falhas

Uma verificação de integridade testa um destino repetidamente, por exemplo, solicitando /health a cada 10 segundos. Depois de um número suficiente de falhas nas verificações, o destino é marcado como sem integridade e não recebe novo tráfego até passar novamente. A detecção leva tempo porque as verificações ocorrem em intervalos.

Roteamento e reparo são tarefas diferentes. O balanceador de carga deixa de enviar novas requisições a um destino com falha. Um grupo de escalonamento ou operador repara ou substitui esse servidor. Adicionar um balanceador de carga, por si só, não acrescenta capacidade de processamento à aplicação.

A distribuição circular seleciona os destinos íntegros em sequência. O método de menor número de conexões ou de menor número de requisições pendentes favorece o destino com menos trabalho em andamento. O roteamento baseado em hash associa detalhes da conexão, incluindo endereços e portas, a um destino. Uma conexão permanece no mesmo destino, mas uma nova conexão do mesmo usuário pode ir para outro.

A afinidade de sessão mantém as requisições de um usuário em um servidor. Ela pode ajudar uma aplicação com sessões locais, mas torna o tráfego menos uniforme e deixa as sessões expostas à falha desse servidor. O armazenamento compartilhado de sessões permite que outros servidores íntegros continuem o trabalho do usuário.

Calcule o efeito da perda de um servidor

Três servidores íntegros dividem igualmente 900 requisições por minuto. Cada um atende:

Um servidor falha nas verificações de integridade. O mesmo trabalho agora vai para dois:

Se cada um puder atender a apenas 400 requisições por minuto, o roteamento para servidores íntegros ainda deixa uma sobrecarga. O conjunto precisa de capacidade excedente ou mais instâncias. O escalonamento automático altera a capacidade; o balanceamento de carga a distribui.

Escolha a camada adequada ao roteamento

Um serviço de camada 7 também pode fazer a terminação TLS, descriptografando HTTPS no ponto de entrada, e funcionar com um firewall de aplicações web. Um serviço de camada 4 não examina um caminho HTTP para escolher seu back-end. Verifique quais protocolos de transporte cada produto oferece.

O AWS Elastic Load Balancing oferece Application Load Balancers na camada 7, Network Load Balancers na camada 4 e Gateway Load Balancers para dispositivos de rede, dentro de uma região. O Azure Load Balancer é de camada 4; o Application Gateway é regional de camada 7; o Front Door fornece um ponto de entrada global de camada 7. O Google Cloud Load Balancing oferece Application e Network Load Balancers em versões regionais e globais.

Una roteamento e escalonamento

Com a integração configurada, novas instâncias do grupo são registradas como destinos e recebem tráfego assim que estão íntegras. Durante a remoção, a drenagem de conexões permite que requisições ativas terminem antes de um destino desaparecer. Uma implantação em várias zonas roteia para zonas íntegras durante uma interrupção, desde que as zonas restantes tenham capacidade suficiente. Até dois servidores se beneficiam desse ponto de entrada compartilhado e do roteamento baseado em integridade.

Um contêiner executa uma aplicação e suas dependências como um processo isolado em um host. Empacotar suas bibliotecas e seu ambiente de execução permite reproduzir em produção o software testado.

Imagem, registro e cópia em execução

Uma imagem é o modelo somente de leitura; um registro de imagens armazena e distribui imagens; um contêiner é uma cópia em execução. Amazon ECR, Azure Container Registry e Google Artifact Registry fornecem registros de imagens. A Open Container Initiative define formatos padrão de imagem; o Docker ajudou a popularizar seu uso.

Por exemplo, uma equipe empacota sua API de pedidos em Python como orders-api:1.4, testa-a, envia-a a um registro de imagens e inicia 3 contêineres de produção a partir dessa imagem. As configurações do ambiente e o acesso a serviços externos ainda precisam ser configurados.

Compartilhe um kernel em vez de inicializar um sistema operacional convidado

Cada VM contém um sistema operacional convidado completo atrás de um hipervisor. Contêineres compartilham o kernel do host, o núcleo do sistema operacional que gerencia recursos e processos. Eles têm menos software para transportar e iniciar: imagens geralmente têm dezenas ou centenas de megabytes, e a inicialização leva segundos ou menos. Imagens de VM normalmente têm gigabytes e inicializam em minutos. Assim, um host pode executar mais contêineres do que VMs completas.

O compartilhamento também afeta o isolamento. Uma falha no kernel do host pode afetar vários contêineres, enquanto kernels convidados separados dão às VMs uma barreira mais forte. Contêineres Linux precisam de um kernel Linux; contêineres Windows precisam do Windows. A imagem também deve ser compatível com a arquitetura do processador, como x86 ou Arm. Contêineres muitas vezes são executados em VMs na nuvem.

Substitua o software e preserve os dados

Atualize um contêiner criando uma imagem corrigida e substituindo as cópias antigas. Uma correção manual desaparece na substituição e deixa as outras réplicas inalteradas.

O mesmo vale para arquivos criados durante a execução na camada gravável. Uma fatura gerada ali deve ser salva em um volume persistente ou serviço de armazenamento antes da substituição. O registro de imagens preserva pacotes de aplicações, não documentos criados por contêineres em execução.

Separe serviços quando isso ajudar

Um monólito é implantado como uma unidade. Microsserviços dividem uma aplicação em serviços conectados pela rede que são implantados e escalonados separadamente. Uma loja pode adicionar contêineres do serviço de pagamentos sem adicionar cópias do serviço de catálogo.

Um orquestrador distribui contêineres entre hosts, reinicia cópias com falha, ajusta sua quantidade, implanta versões e conecta serviços. O Kubernetes faz isso, assim como serviços gerenciados de contêineres mais simples. Contêineres não exigem Kubernetes.

O Kubernetes implanta e gerencia contêineres em um grupo de máquinas chamado cluster. É de código aberto, surgiu no Google e é mantido pela Cloud Native Computing Foundation. A mesma plataforma pode funcionar em nuvens e centros de dados privados.

Entenda as partes do cluster

O plano de controle armazena a configuração, programa o trabalho e coordena o cluster. Os nós de trabalho, geralmente VMs, fornecem o processamento e a memória que os contêineres consomem.

Um pod é a menor unidade programada pelo Kubernetes. Ele contém um ou mais contêineres que compartilham um endereço de rede e permanecem juntos em um nó. Um pod não é uma VM separada. Vários pods podem compartilhar o mesmo nó de trabalho se suas necessidades de recursos couberem nele.

Você declara um estado desejado: por exemplo, 3 réplicas de orders-api:1.4. O Kubernetes trabalha para manter 3 pods em execução. Quando um pod falha, ele cria um substituto; após a falha de um nó, pods substitutos podem ser executados em nós restantes com capacidade disponível. Um Service do Kubernetes fornece um nome e um endereço estáveis para acessar os pods mesmo quando seus endereços individuais mudam.

Escalone pods e máquinas separadamente

Um escalonador horizontal automático de pods (HPA) altera a quantidade de pods usando métricas como demanda de CPU. Um escalonador automático de cluster altera a capacidade dos nós quando os pods não cabem ou os nós se tornam desnecessários. Adicionar pods sem espaço para executá-los cria trabalho pendente, não mais capacidade de processamento.

Suponha que cada pod solicite 0,5 vCPU e que cada nó tenha 2 vCPUs disponíveis para pods. Ignore outros limites de recursos neste exemplo. Um nó pode comportar:

Se o HPA aumentar a quantidade desejada para 10 pods, dois nós comportam apenas 8. O necessário é:

Arredonde para cima para 3 nós. O terceiro nó fornece espaço para os últimos 2 pods. Use a capacidade disponível para pods, pois o sistema operacional do nó e os componentes do Kubernetes também precisam de recursos. Na programação real, memória e regras de alocação também importam, além da CPU.

Divida as responsabilidades de gerenciamento

Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS) e Google Kubernetes Engine (GKE) executam planos de controle gerenciados. O provedor mantém esse plano de controle, incluindo sua disponibilidade e atualizações. Você gerencia imagens, configurações da aplicação, acesso e solicitações de recursos das cargas de trabalho. Em muitos modos, você também gerencia as escolhas e atualizações dos nós de trabalho. As taxas do cluster podem ser separadas das cobranças dos nós.

O GKE Standard deixa as escolhas dos nós com você e cobra pelas VMs dos nós. O GKE Autopilot provisiona e gerencia os nós, geralmente cobrando pelos recursos solicitados pelos pods. O EKS pode executar pods elegíveis no AWS Fargate para que você não gerencie as VMs dos nós. Esses modos reduzem o trabalho operacional, mas limitam algumas escolhas relacionadas ao host.

Decida se a complexidade ajuda

O Kubernetes é adequado para muitos serviços implantados de forma independente e para equipes que precisam de uma plataforma comum entre provedores. Suas ferramentas e definições de cargas de trabalho melhoram a portabilidade, embora bancos de dados em nuvem, sistemas de identidade e redes conectados ainda possam exigir alterações.

Para uma aplicação web simples, uma plataforma de hospedagem ou um serviço de contêineres sem servidor pode exigir menos trabalho. O Kubernetes gerenciado não corrige um erro na sua imagem nem escolhe a solicitação de memória adequada para você. Se uma aplicação ficar sem memória repetidamente, a equipe deverá diagnosticar a aplicação e suas configurações mesmo quando o plano de controle for totalmente gerenciado.

Serviços de contêineres sem servidor executam suas imagens em hosts gerenciados pelo provedor. Você ainda seleciona recursos, mantém a imagem e configura a aplicação. O escalonamento e a cobrança dependem do serviço.

Separe a orquestração da computação

O Amazon ECS orquestra contêineres como tarefas. Um serviço ECS mantém uma quantidade desejada de tarefas, opcionalmente atrás de um balanceador de carga. As tarefas são executadas em hosts EC2 gerenciados por você ou na computação do Fargate.

O Fargate também aceita pods elegíveis do EKS. Você escolhe as vCPUs e a memória da tarefa ou do pod e paga enquanto esses recursos estão em execução; você não seleciona, atualiza nem escalona os hosts EC2 subjacentes. O escalonamento automático de serviços ECS usa políticas configuradas por você. O Fargate fornece computação, não a quantidade desejada de tarefas da aplicação. O ECS no EC2 mantém mais controle sobre o host e a família de instâncias, com mais trabalho de gerenciamento.

Compare os serviços do Azure e do Google

O Azure Container Instances (ACI) inicia um contêiner ou um pequeno grupo sem um cluster e cobra por segundo. É adequado para testes e tarefas simples com duração limitada, mas não tem escalonamento automático integrado.

O Azure Container Apps oculta sua plataforma Kubernetes subjacente. Regras configuradas escalonam aplicações em contêineres conforme o tráfego HTTP ou eventos, inclusive reduzindo a zero para cargas de trabalho adequadas.

O Google Cloud Run oferece serviços para requisições recebidas e tarefas executadas até a conclusão. Os serviços podem crescer a partir de zero e diminuir novamente. A cobrança de computação baseada em requisições cobre o processamento de requisições e a inicialização e o desligamento. Sem instâncias mínimas e sem instâncias em execução, a computação ociosa não custa nada; bancos de dados e imagens armazenadas ainda podem gerar cobranças. O Cloud Run também hospeda Cloud Run functions, que partem do código da função em vez de uma imagem de aplicação fornecida pelo cliente.

Equilibre economia em períodos ociosos e atraso de inicialização

Uma API interna de reservas é muito usada das 08:00 às 18:00 em dias úteis: 10 horas em 5 dias, ou 50 das 168 horas da semana. Também chegam requisições ocasionais à noite. O Cloud Run ou o Container Apps podem executar várias cópias no pico e chegar a zero entre requisições durante períodos tranquilos.

Uma requisição após um período ocioso pode esperar por uma inicialização a frio. Manter uma instância mínima pronta reduz o atraso dentro da capacidade dela e acrescenta custo contínuo. Um pico acima dessa capacidade ainda pode iniciar instâncias adicionais a frio.

Escolha o controle de host necessário

Esses serviços restringem o acesso ao host e impõem limites de recursos e duração. Você não pode instalar agentes no host nem alterar seu kernel. VMs ou nós adequados do Kubernetes atendem a essas necessidades. Para APIs padrão em contêineres, serviços mais simples podem evitar o trabalho de operar o Kubernetes; o ACI é uma opção direta para um grupo simples de contêineres.

Uma função sem servidor é um código executado quando um evento correspondente chega. O provedor gerencia os servidores e o ambiente de execução gerenciado. AWS Lambda, Azure Functions e Google Cloud Run functions oferecem esse modelo de função como serviço (FaaS).

Relacione um gatilho a uma invocação

Um gatilho inicia uma execução, chamada invocação. Gatilhos incluem requisições HTTP, arquivos enviados, mensagens de fila, alterações em bancos de dados e temporizadores. O envio de uma foto pode acionar uma função que cria uma miniatura de 200 pixels e a salva no armazenamento. Sem envios, uma implantação sob demanda pode não ter computação de função em execução.

O provedor escalona a execução conforme os eventos chegam, dentro dos limites de concorrência e do serviço. Muitas funções simultâneas podem abrir muitas conexões de banco de dados. A camada de funções pode ter espaço para escalonar mesmo quando o banco de dados não tem. Limite a concorrência ao que os sistemas conectados podem suportar.

Funções são sem estado entre invocações. Uma invocação posterior pode usar um novo ambiente, portanto não pode depender da memória ou dos arquivos temporários de uma chamada anterior. Armazene contadores, sessões e resultados duradouros em um banco de dados, cache ou armazenamento de objetos. Um ambiente já pronto pode ser reutilizado, mas essa reutilização não é uma garantia de persistência.

Calcule o uso para cobrança por consumo

A cobrança padrão sob demanda do Lambda combina a quantidade de invocações e GB-segundos (GB-s): memória alocada em GB multiplicada pelos segundos de execução. Para um cálculo ilustrativo, suponha que cada uma de 3.000.000 de invocações seja executada por 0,2 segundo com 0,5 GB de memória. Ignore franquias gratuitas e todos os outros serviços.

A preços hipotéticos de R$ 0,0000167 por GB-s e R$ 0,20 por milhão de requisições, a computação custa R$ 5,01 e as requisições custam R$ 0,60, totalizando R$ 5,61. Esses preços são hipotéticos para aprender o modelo. O Cloud Run functions também mede a CPU; planos do Azure podem cobrar por instâncias prontas ou alocadas.

Com 100.000.000 de invocações iguais nos demais aspectos, o uso é de 10.000.000 GB-s: R$ 167 pela computação mais R$ 20 pelas requisições, nessas tarifas hipotéticas. Uma VM com preço hipotético de R$ 0,04 por hora custa R$ 29,20 por 730 horas, mas uma comparação justa também verifica se ela pode processar o mesmo trabalho e inclui seu esforço operacional. Demanda com picos favorece evitar capacidade ociosa; carga constante pode favorecer computação sempre ativa.

Verifique limites de execução e atraso de inicialização

A computação padrão do Lambda permite no máximo 15 minutos por invocação e até 10.240 MB de memória. Uma conversão de 40 minutos não cabe nessa invocação. Uma tarefa em contêiner, uma VM ou etapas mais curtas podem atender à necessidade; as regras de tempo limite diferem para outros planos e modos de computação.

Uma inicialização a frio ocorre quando um novo ambiente de execução precisa ser preparado, após um período ocioso ou durante um aumento horizontal. Ambientes já prontos e reutilizados iniciam mais rapidamente. A concorrência provisionada do Lambda, instâncias sempre prontas no Azure Premium ou Flex Consumption e instâncias mínimas do Cloud Run reduzem atrasos de inicialização por um custo adicional.

O provedor mantém os servidores e o ambiente de execução gerenciado. Você ainda corrige seu código e as bibliotecas incluídas, protege segredos, configura permissões e protege dados. A computação sem servidor elimina a administração de servidores, não a responsabilidade pela aplicação.

Uma plataforma de hospedagem de aplicações recebe seu código ou imagem de contêiner e fornece a infraestrutura para executá-lo. É uma plataforma como serviço (PaaS): implantação, monitoramento de integridade, operação de servidores e escalonamento são fornecidos pela plataforma, enquanto você desenvolve a aplicação.

Compare as principais plataformas

O AWS Elastic Beanstalk cria recursos comuns da AWS para sua aplicação, geralmente instâncias EC2 em um grupo Auto Scaling atrás de um Elastic Load Balancer. Ele cuida das implantações e do monitoramento de integridade. O próprio Beanstalk não tem taxa adicional de serviço; você paga pelos recursos que ele cria. Esses recursos continuam visíveis na sua conta, e você pode personalizar sua configuração.

O Azure App Service hospeda aplicações web, APIs e back-ends móveis a partir de código ou contêineres. Um plano do App Service define a região, o tamanho e a quantidade de instâncias. As aplicações desse plano compartilham essas instâncias. Camadas dedicadas cobram pelo plano mesmo quando as aplicações estão com pouco uso. Recursos como escalonamento automático e slots de implantação dependem da camada escolhida.

O Google App Engine tem ambientes padrão e flexível. O padrão usa ambientes de execução compatíveis em uma área isolada e pode escalonar a zero com escalonamento automático adequado. O flexível executa contêineres em VMs do Compute Engine, permite mais personalização e mantém pelo menos uma instância em execução. O Cloud Run é outra opção para hospedar uma aplicação já empacotada em um contêiner.

Lance uma nova versão com segurança

Uma equipe de loja com duas pessoas usa uma camada do App Service com slots de implantação. Ela executa 2 instâncias e implanta uma nova versão em um slot de homologação, um local separado para testar a versão antes que os clientes a usem. Depois dos testes, ela troca a homologação e a produção. A versão antiga continua disponível no outro slot para uma possível reversão.

Durante uma promoção, a regra de escalonamento automático configurada aumenta o plano para 5 instâncias depois que a média de CPU permanece acima de 70%, e depois retorna a 2 conforme a demanda diminui. A plataforma executa o escalonamento, mas a equipe ainda escolhe o plano, as regras e os limites. Ela nunca instala o sistema operacional do host nem o servidor web.

Mantenha as responsabilidades adequadas

Você mantém código, bibliotecas incluídas, configurações, segredos, dados e acesso em todas as plataformas. O App Service e o App Engine mantêm seu sistema operacional de host e ambiente de execução gerenciado. O Beanstalk permite mais personalização do EC2; a AWS publica atualizações de plataforma, e você as aplica ou ativa as atualizações gerenciadas de plataforma. O software adicional que você instalar também precisa de atenção.

Uma plataforma é diferente de SaaS. Com PaaS, você implanta a aplicação que desenvolve; com SaaS, você usa uma aplicação pronta de outra pessoa, como um pacote de e-mail. Configurações específicas da plataforma e integrações com serviços também podem dificultar uma mudança posterior de provedor.

Atenda a necessidades mais simples de hospedagem

O Amazon Lightsail reúne um servidor virtual privado, armazenamento e transferência de dados em um pacote mensal previsível. Ele é adequado para sites pequenos, mas ainda envolve responsabilidades de VM. Um site estático é composto de arquivos como HTML, CSS, JavaScript e imagens. AWS Amplify Hosting, Azure Static Web Apps e Firebase Hosting podem distribuir esses arquivos globalmente sem que você precise manter um servidor web. Uma aplicação que exige controle total do sistema operacional do host deve ficar em VMs.

Compare modelos de computação para a mesma carga de trabalho. Verifique controle, esforço operacional, inicialização, cobrança, limites e portabilidade.

Quem mantém cada parte?

Dados e acesso continuam sob responsabilidade do cliente em todos os casos. O Elastic Beanstalk também exige a escolha de como as atualizações de plataforma serão aplicadas.

Compare tráfego e capacidade utilizável

Uma VM geralmente precisa de um minuto ou mais para inicializar e passar nas verificações; um contêiner costuma iniciar em segundos; uma função em ambiente pronto pode começar a trabalhar em milissegundos. Um novo ambiente pode acrescentar atraso de inicialização a frio. Capacidade mantida pronta reduz esse atraso por um custo contínuo.

Um diretório com pouco uso durante a noite pode se beneficiar do escalonamento a zero; demanda constante pode favorecer computação alocada. Compare vazão, memória e concorrência equivalentes antes dos totais mensais: uma VM barata pode não atender ao mesmo trabalho que muitas invocações simultâneas de funções. Inclua também o esforço operacional.

VMs e planos dedicados de hospedagem cobram pelo tempo alocado, ocupados ou ociosos. A cobrança padrão sob demanda do Lambda combina requisições e GB-segundos; outros planos de funções usam medições diferentes. Ter zero instâncias elimina cobranças de computação ociosa apenas quando não há um mínimo pago. Armazenamento e bancos de dados ainda podem ser cobrados.

Verifique limites e transferência entre plataformas

Processos de longa duração são adequados para VMs ou contêineres apropriados. Uma invocação de computação padrão do Lambda é limitada a 15 minutos, portanto uma tarefa ininterrupta de duas horas precisa de outra opção de execução compatível. Funções não podem depender da sobrevivência do estado local entre chamadas; contêineres descartáveis e VMs de grupos de escalonamento também precisam de dados duradouros externos.

Controle total do sistema operacional convidado, alterações de kernel e software licenciado especializado favorecem VMs. Muitos serviços implantados de forma independente podem justificar o Kubernetes. Aplicações web padrão muitas vezes são adequadas para plataformas de hospedagem; tarefas curtas por eventos são adequadas para funções.

Imagens de contêiner são transferidas entre hosts compatíveis, e o Kubernetes oferece ferramentas comuns de implantação entre nuvens. Bancos de dados, identidade e rede ainda podem precisar de alterações. A migração de VMs depende dos formatos e ferramentas do provedor; funções e plataformas estão mais vinculadas às configurações e aos gatilhos do provedor. Componentes diferentes podem usar modelos diferentes.

Primeiro, verifique os requisitos que poderiam excluir uma opção. Depois, compare tráfego, custo e habilidades da equipe.

Encontre a restrição decisiva

1. Verifique acesso ao sistema operacional convidado, software especial, hardware e licenciamento.
2. Para trabalho curto acionado por eventos, verifique duração, estado e concorrência da função.
3. Para aplicações em contêineres, compare o controle do Kubernetes com serviços gerenciados mais simples.
4. Para aplicações web padrão implantadas como código, considere uma plataforma de hospedagem.
5. Verifique atraso de inicialização, padrões de tráfego, limites de recursos e custo operacional total.

Associe os casos de negócios

Um fornecedor oferece suporte a uma aplicação de contabilidade apenas no Windows Server, com uma licença baseada em núcleos. VMs preservam esse ambiente; use um host dedicado se o licenciamento por núcleo físico exigir. Cópias em várias zonas precisam de um projeto compatível para a aplicação e os dados. A transferência praticamente sem alterações é a rehospedagem, ou lift and shift, e mantém a manutenção do sistema convidado.

Os envios de fotos aumentam de poucos à noite para milhares por minuto. Tarefas curtas e independentes de miniaturas são adequadas para funções acionadas por envios. Elas escalonam conforme as chegadas; verifique inicializações a frio, limites de duração e capacidade dos serviços posteriores.

Uma empresa de varejo tem 30 microsserviços, 6 equipes e um requisito de plataforma em duas nuvens. O Kubernetes gerenciado fornece ferramentas comuns de orquestração. Uma startup com 3 serviços e sem experiência em Kubernetes pode usar Cloud Run, Container Apps ou ECS com Fargate, mantendo as responsabilidades pela imagem e pela aplicação sem trabalho com hosts.

Uma agência desenvolve o site de venda de ingressos de um museu, mas não tem equipe de operações. Uma plataforma de hospedagem fornece ferramentas de implantação e escalonamento para os dias de abertura. O App Service e o App Engine mantêm os hosts; o Beanstalk exige uma escolha de atualização de plataforma, como atualizações gerenciadas.

Um relatório noturno de duas horas é adequado para uma tarefa em contêiner ou VM com limite de execução apropriado, não para uma única invocação de computação padrão do Lambda. A capacidade spot pode reduzir o custo se a tarefa salvar o progresso e for retomada após uma interrupção.

O treinamento em GPU durante vários dias precisa de VMs aceleradas ou nós adequados do Kubernetes com GPU. Pontos de verificação persistidos tornam a capacidade spot viável ao limitar a perda de progresso.

Explique uma escolha em etapas

Uma empresa pode primeiro rehospedar para deixar seu centro de dados rapidamente e depois modernizar componentes selecionados com contêineres, plataformas de hospedagem ou funções. A rehospedagem, por si só, mantém o modelo operacional antigo.

Por exemplo: “Use o Cloud Run porque a API já está em contêiner, o tráfego para à noite e a equipe não tem administrador de servidores; considere uma inicialização a frio após períodos ociosos.”