Quando você pesquisa "serverless" no GCP, três serviços aparecem ao mesmo tempo: App Engine, Cloud Run e Cloud Functions. Os três compartilham a característica de que você nunca gerencia a infraestrutura subjacente diretamente, mas seus modelos de execução e os tipos de carga de trabalho para os quais são otimizados são claramente distintos. Este guia sintetiza os padrões extraídos de 53 questões reais do exame GCP-ACE e mapeia cada serviço para os cenários onde ele é a melhor escolha.
---
Três serviços por trás da palavra "serverless"
| Serviço | Nível de abstração | Alvo principal | Base de cobrança | |---------|-------------------|----------------|------------------| | App Engine | Plataforma (PaaS) | Aplicações web completas | Horas de instância | | Cloud Run | Serverless de contêiner | Microsserviços HTTP | CPU, memória, número de requisições | | Cloud Functions | Serverless de função | Funções efêmeras orientadas a eventos | Número de invocações + tempo de execução |
Com App Engine você simplesmente faz upload do seu código e de uma configuração de runtime, e o Google cuida do balanceador de carga, da terminação HTTPS e do autoescalonamento. Cloud Run aceita qualquer contêiner Docker como está, eliminando restrições de linguagem ou framework. Cloud Functions conecta uma única função a uma fonte de eventos e representa a menor pegada serverless. A distinção mais importante entre os três é a unidade que é implantada: uma aplicação, uma imagem de contêiner ou uma função.
Para engenheiros de plataforma que trabalham habitualmente com contêineres, Cloud Run será o mais natural. Para engenheiros de backend que preferem evitar até mesmo a ideia de construir uma imagem, Cloud Functions elimina essa camada. App Engine fica no meio: o artefato de implantação é o seu código-fonte mais um arquivo , não uma imagem de contêiner, mas a abstração é mais alta do que a de uma VM tradicional.
---
App Engine Standard vs Flexible
App Engine oferece dois ambientes de execução distintos. Compreender exatamente onde eles diferem é o que separa uma resposta correta de uma incorreta na maioria das questões do exame sobre App Engine.
| Atributo | Ambiente Standard | Ambiente Flexible | |----------|------------------|-------------------| | Runtimes | Python, Java, Go, Node.js, Ruby, PHP (versões fixas) | Qualquer linguagem (Dockerfile personalizado) | | Inicialização da instância | Segundos (às vezes milissegundos) | Vários minutos | | Escala para zero | Sim — instâncias caem para 0 quando ociosas | Não — mínimo de 1 instância sempre ativa | | Acesso direto à VPC | Não — requer Serverless VPC Access Connector | Sim | | Modelo de custos | Cobrança por segundo, custo zero quando ocioso | Mínimo de 1 instância cobrada continuamente | | Sistema de arquivos | Somente leitura (o diretório /tmp local é gravável) | Leitura e escrita completas |
As vantagens do ambiente Standard são os cold starts rápidos e a capacidade de escalar para zero. É econômico para aplicações com tráfego variável ou imprevisível, mas as versões fixas de runtime podem ser uma restrição se você depende de uma biblioteca que requer um interpretador mais recente.
O ambiente Flexible permite trazer uma imagem Docker personalizada e conectar-se diretamente a uma VPC, mas a instância mínima sempre ativa significa que você paga mesmo quando não há tráfego. A heurística para o exame é simples: se a questão menciona conectividade direta com VPC, a resposta é Flexible; se menciona custo zero com tráfego zero, a resposta é Standard.
Uma restrição crítica que aparece no exame: cada projeto do GCP pode ter exatamente uma aplicação App Engine, e a região escolhida na primeira implantação é permanente. Mudar a região requer criar um projeto completamente novo. É um limite operacional definitivo, não uma diretriz flexível.
---
Cloud Run: O serverless de contêineres por padrão
Cloud Run é a opção serverless mais versátil do GCP. Aceita qualquer contêiner Docker que escute em uma porta HTTP, o que significa que você tem liberdade para usar qualquer linguagem, qualquer framework e qualquer conjunto de dependências.
O mecanismo central do Cloud Run é o escalonamento baseado em requisições. Quando não chegam requisições, o serviço escala para zero instâncias. Quando o tráfego aumenta de forma repentina, Cloud Run se expande automaticamente até o máximo configurado — 1.000 por padrão.
| Configuração do Cloud Run | Padrão | Descrição | |--------------------------|--------|----------| | Concorrência | 80 | Máximo de requisições simultâneas por instância | | Instâncias mínimas | 0 | Instâncias sempre ativas | | Instâncias máximas | 1.000 | Limite de escalonamento horizontal | | Timeout de requisição | Até 3.600 segundos | Duração máxima de uma única requisição | | Alocação de CPU | Somente durante o processamento | Usar --cpu-always-on para manter CPU alocada |
Cloud Run opera em dois modos. Um Cloud Run Service recebe tráfego HTTP de forma contínua e é a escolha certa para APIs e aplicações web. Um Cloud Run Job não tem um endpoint HTTP; ele é executado até completar o trabalho e encerra, tornando-o ideal para cargas de trabalho de processamento em lote.
Para processamento assíncrono, as assinaturas Push do Pub/Sub que invocam Cloud Run são uma arquitetura padrão no GCP. A abordagem de autenticação recomendada pelo Google nesse padrão é o uso de tokens OIDC. A autenticação por chave de API não é a resposta correta no exame nem a abordagem recomendada em produção.
Para serviços intensivos em CPU, configure a concorrência mais baixa (próxima de 1). Para serviços intensivos em I/O — aqueles que aguardam consultas ao banco de dados ou chamadas a APIs externas — uma concorrência maior significa que menos instâncias são necessárias para manter o mesmo throughput, o que reduz diretamente o custo.
---
Cloud Functions e o modelo de gatilhos de eventos
Cloud Functions implanta código na granularidade de uma única função e a conecta diretamente a uma fonte de eventos. Se a unidade do Cloud Run é um contêiner, a unidade do Cloud Functions é uma função. Você não gerencia roteamento, não define portas e não pensa no ciclo de vida das requisições além do limite da função.
| Tipo de gatilho | Evento de exemplo | Suporte Gen 1 | Suporte Gen 2 | |----------------|-------------------|---------------|---------------| | HTTP | Requisição HTTP de entrada | Sim | Sim | | Cloud Storage | Upload de objeto (finalizar), exclusão, alteração de metadados | Sim | Sim | | Cloud Pub/Sub | Mensagem publicada em um tópico | Sim | Sim | | Firestore | Documento criado, atualizado ou excluído | Sim | Sim | | Eventarc (outros) | BigQuery, Cloud Audit Logs, mais de 90 fontes | Não | Sim |
As diferenças mais importantes entre Gen 1 e Gen 2 são o limite de tempo de execução e o modelo de concorrência. Gen 2 roda internamente sobre Cloud Run, por isso herda a configuração de concorrência do Cloud Run e pode executar funções acionadas por HTTP por até 60 minutos.
| Atributo | Cloud Functions Gen 1 | Cloud Functions Gen 2 | |----------|-----------------------|-----------------------| | Tempo máximo de execução | 9 minutos | 60 min (HTTP), 9 min (eventos) | | Infraestrutura subjacente | Própria | Cloud Run | | Concorrência | 1 requisição por instância (fixo) | Configurável (igual ao Cloud Run) | | Integração com Eventarc | Não | Sim | | Divisão de tráfego | Não | Sim |
O caso de uso canônico do Cloud Functions é responder a eventos do Cloud Storage. Quando uma imagem é enviada para um bucket, o evento é disparado e a função conectada é executada automaticamente para redimensionar a imagem ou extrair metadados. Quando não chegam eventos, o custo é zero. A cobrança é baseada no número de invocações mais o tempo de execução arredondado para o múltiplo de 100 milissegundos mais próximo. O nível gratuito inclui 2 milhões de invocações e 360.000 GB-segundos por mês.
---
Divisão de tráfego e padrões de implantação sem tempo de inatividade
O recurso Traffic Splitting do App Engine distribui as requisições de entrada entre várias versões implantadas do mesmo serviço com percentuais configuráveis. Isso permite deploys canary, testes A/B e alternâncias blue-green de forma nativa, sem a necessidade de configurar um balanceador de carga externo.
| Método de divisão | Característica | Melhor cenário | |------------------|---------------|----------------| | Baseado em IP | O mesmo cliente sempre é roteado para a mesma versão | Quando a consistência de sessão é importante | | Baseado em cookie | Um cookie HTTP fixa o usuário a uma versão (mais estável que IP) | Sessões de usuário autenticado | | Aleatório | Cada requisição seleciona uma versão de forma independente | Testes de percentual puro |
Tanto a configuração da divisão de tráfego quanto a realização de rollbacks são feitos com um único comando gcloud:
Deploy canary (10% para a nova versão): Rollback imediato:
Quando você quer implantar uma nova versão sem desviar tráfego para ela, use a flag . A versão é implantada e iniciada, mas não recebe tráfego até que você ajuste explicitamente a divisão. Este é o padrão de implantação mais seguro para serviços em produção com requisitos rigorosos de disponibilidade.
Cloud Run gerencia versões no nível de revisão e também suporta divisão de tráfego entre revisões através das mesmas ferramentas gcloud.
| Serviço | Unidade de versão | Divisão de tráfego | Rollback imediato | |---------|------------------|--------------------|-----------------| | App Engine | Versão | Sim (IP/cookie/aleatório) | Sim | | Cloud Run | Revisão | Sim | Sim | | Cloud Functions Gen 1 | Não suportado | Não suportado | Requer reimplantação | | Cloud Functions Gen 2 | Suportado | Suportado | Sim |
Se o cenário do exame mencionar "rollback imediato sem reimplantação", a resposta é a divisão de tráfego do App Engine. As versões implantadas persistem até serem explicitamente excluídas, portanto, redirecio