Por que as opções de computação do GCP parecem tão confusas
Quando um engenheiro chega ao Google Cloud pela primeira vez, a pergunta que o paralisa é quase sempre a mesma: qual serviço de computação devo usar? Compute Engine, GKE, GKE Autopilot, App Engine Standard, App Engine Flexible, Cloud Run, Cloud Functions — sete opções distintas antes de escrever uma única linha de código de infraestrutura. Os nomes se confundem e os limites parecem arbitrários, mas dois eixos esclarecem todo o panorama imediatamente.
O primeiro eixo é o nível de controle: você precisa gerenciar o sistema operacional diretamente, ou prefere enviar código e deixar o Google cuidar do resto? O segundo eixo é a unidade de execução: você está levantando uma máquina virtual completa, executando um contêiner, ou invocando uma única função?
| Nível de controle | VM | Contêiner | Função | |---|---|---|---| | Alto (autogerenciado) | Compute Engine | GKE Standard | — | | Médio (gerenciado) | — | GKE Autopilot / App Engine Flex | — | | Baixo (serverless) | — | Cloud Run / App Engine Standard | Cloud Functions |
Memorize essa tabela e o restante se torna uma questão de preencher os detalhes de cada serviço. Mais de 80% das questões do exame sobre esse tema derivam apenas desses dois eixos.
---
Compute Engine: todo o poder do IaaS
Compute Engine é a oferta IaaS fundamental do GCP. Você tem controle total sobre uma máquina virtual: seleção de sistema operacional, fixação de versão de JVM, ajuste de parâmetros do kernel, instalação de bibliotecas personalizadas, configuração de portas — tudo o que você pode fazer em um servidor físico on-premises está disponível aqui.
Dois sinais em uma questão do exame apontam diretamente para Compute Engine como resposta. O primeiro é um requisito de Lift-and-Shift: migrar sem alterar o código. Se uma aplicação Java legada tem dependências fortes com flags específicos de JVM (-Xms, -Xmx) e versões de bibliotecas proprietárias, App Engine e Cloud Run impõem sandboxes de runtime que tornam a migração impossível. Compute Engine é o único caminho viável. O segundo sinal é isolamento físico — um requisito de Sole-tenant Nodes para manter workloads fora de hardware compartilhado.
Estratégia de seleção de tipo de máquina
| Família de máquina | Séries de exemplo | Casos de uso principais | |---|---|---| | Propósito geral | N2, E2, N1 | Servidores web, ambientes de desenvolvimento, bancos de dados médios | | Otimizada para computação | C2, C2D | Computação de alto desempenho, servidores de jogos, simulações científicas | | Otimizada para memória | M2, M3 | SAP HANA, grandes bancos de dados em memória | | Otimizada para acelerador | A2, G2 | Treinamento de ML, inferência com GPU, renderização | | Otimizada para armazenamento | Z3 | SSD local de alto desempenho, Spanner, etc. |
Custom Machine Type é a escolha certa quando nenhum tipo predefinido atende à sua combinação exata de recursos. E2 escala em incrementos de 1 vCPU; N1 e N2 em incrementos de 2. A memória é ajustada em passos de 256 MB. Se você precisar de mais memória por vCPU do que o limite padrão permite, adicione a opção Extended Memory.
Spot VM: a alavanca de redução de custos
Spot VM oferece até 91% de economia em comparação com preços sob demanda, com uma contrapartida: o Google pode recuperar a instância com 30 segundos de aviso. Isso torna o Spot VM ideal para workloads que suportam reinicializações baseadas em checkpoints — processamento em lote, treinamento de ML, pipelines de renderização. Os Committed Use Discounts (compromissos de 1 ou 3 anos, 20–57% de desconto) funcionam melhor para workloads sempre ativas e são ineficientes para jobs em lote intermitentes.
Managed Instance Groups e autoescalonamento
Um Managed Instance Group (MIG) agrupa múltiplas VMs construídas a partir do mesmo template de instância e escala a contagem automaticamente com base na utilização de CPU ou no backlog de assinatura do Cloud Pub/Sub. Quando os volumes de solicitações disparam para centenas de milhares, o padrão recomendado é o Pub/Sub absorver mensagens de forma durável (retidas por até 7 dias, nunca excluídas antes do ACK) enquanto o MIG escala a contagem de VMs com base na métrica de backlog. Isso desacopla a ingestão do processamento e evita a perda de mensagens durante picos de carga.
---
Google Kubernetes Engine: o padrão para orquestração de contêineres
GKE oferece clusters Kubernetes gerenciados no GCP. É a opção mais poderosa para executar workloads em contêineres em escala e carrega consigo uma complexidade operacional proporcionalmente maior.
Se sua aplicação já está em contêineres ou segue uma arquitetura de microsserviços, o GKE merece estar na conversa. Se você está migrando uma aplicação monolítica sem refatoração, o Compute Engine evita completamente a sobrecarga da containerização.
GKE Standard é a escolha certa quando você precisa de controle direto sobre node pools, DaemonSets, políticas de rede personalizadas ou outras primitivas avançadas do Kubernetes. GKE Autopilot remove o gerenciamento de nós das suas responsabilidades: você declara os requisitos de recursos no nível do Pod e o Google cuida do provisionamento, escalonamento e atualizações. A cobrança passa de horas de VM de nó para solicitações reais de recursos de Pod, então você para de pagar por capacidade de nó ociosa.
Uma limitação importante do GKE: o Horizontal Pod Autoscaler (HPA) mantém um mínimo de um Pod em todos os momentos. Mesmo com tráfego zero, você incorre em custos. Se o scale-to-zero verdadeiro é necessário, Cloud Run é a resposta.
---
App Engine e Cloud Run: dois caminhos para contêineres serverless
Tanto o App Engine quanto o Cloud Run são serviços PaaS serverless. Os desenvolvedores fornecem código (App Engine) ou uma imagem de contêiner (Cloud Run) e pulam completamente o patch de SO, o planejamento de capacidade e o provisionamento de servidores. A diferença na filosofia de design é o que orienta a decisão de seleção.
App Engine Standard vs App Engine Flexible
| Dimensão | App Engine Standard | App Engine Flexible | |---|---|---| | Runtime | Runtimes limitados (Python, Java, Node.js, Go, PHP, Ruby) | Contêiner Docker personalizado | | Scale-to-zero | Suportado (zero instâncias quando inativo) | Não suportado (mínimo 1 instância) | | Cold start | Sim | Não (sempre ativo) | | Cobrança | Horas de instância (gratuito quando inativo) | Horas de VM (mínimo 1 minuto) | | Restrições de rede | Algumas limitações | Sem restrições | | Melhor para | Tráfego intermitente, runtimes padrão | Binários personalizados, serviços sempre ativos |
A vantagem principal do App Engine Standard é o scale-to-zero: quando não há tráfego, o custo cai a zero. A restrição é o sandbox — flags de JVM personalizados e bibliotecas nativas proprietárias geralmente não são suportadas.
Cloud Run: características fundamentais
Cloud Run aparece com mais frequência do que qualquer outro serviço como resposta correta no exame. Suas características definidoras são três: scale-to-zero, cobrança baseada em requisições com granularidade de milissegundos, e portabilidade de contêineres. É a opção ideal para workloads com variabilidade de tráfego extrema — imagine um site de venda de ingressos que passa de inativo para milhões de requisições em minutos após o anúncio de um grande evento. Se cold starts são uma preocupação, configure min-instances para manter um pool aquecido disponível. Ao escolher entre Cloud Run e App Engine Standard, o separador mais claro é o artefato: você está implantando uma imagem de contêiner ou código-fonte diretamente?
---
Cloud Functions: execução orientada a eventos com granularidade de função
Cloud Functions é a oferta FaaS do GCP. Você implanta funções individuais que executam apenas em resposta a eventos. Você paga com base na contagem de invocações e duração de execução, sem cobrança por tempo ocioso.
Palavras-chave que tornam o Cloud Functions a resposta correta: sem gerenciamento de servidores, preço de pagamento por uso com custo zero em ociosidade, tráfego esporádico, tarefas concluídas em segundos, gatilhos de eventos HTTP/Pub/Sub/Cloud Storage.
Um exemplo prático: dados de pedidos de parceiros chegam em rajadas em determinadas horas do dia, e cada registro requer apenas uma transformação rápida antes de ser encaminhado para o próximo passo. Cloud Functions lida com esse padrão de forma limpa. App Engine Standard também suporta scale-to-zero, mas para tratamento de eventos de função única, Cloud Functions oferece cobrança mais granular e menor superfície operacional.
Os limites de tempo de execução importam. Cloud Functions de primeira geração têm um máximo de 9 minutos; a segunda geração suporta até 60 minutos. Para processos de longa execução ou conexões sustentadas a bancos de dados on-premises, Cloud Functions não é a escolha certa. Compartilhe estado entre funções usando armazenamentos externos como Cloud Firestore ou Cloud Memorystore — nunca confie no estado em memória entre invocações.
---
Comparando todas as opções em uma única tabela
A tabela abaixo consolida o modelo de cobrança, suporte a scale-to-zero, carga operacional e adequação de workload para cada serviço.
| Serviço | Base de cobrança | Scale-to-zero | Carga operacional | Workloads ideais | |---|---|---|---|---| | Compute Engine | Horas de instância | Não | Alta | Lift-and-Shift, apps legadas, runtimes personalizados | | GKE Standard | Horas de VM de nó | Não | Alta | Controle avançado de K8s, microsserviços | | GKE Autopilot | Solicitações de recursos de Pod | Não | Baixa | Contêineres sem gerenciamento de nós K8s | | App Engine Standard | Horas de instância | Sim | Baixa | Apps web com runtimes padrão, tráfego intermitente | | App Engine Flexible | Horas de VM | Não | Baixa | Runtimes personalizados, serviços sempre ativos | | Cloud Run | Tempo de processamento de requisições | Sim | Muito baixa | Variabilidade extrema, contêineres serve