GCP (Serviços equivalentes)

O Google Cloud Platform é a terceira grande nuvem pública e concentra seu diferencial em dados, analytics e infraestrutura de rede global herdada da própria Google. Para o estudo de arquitetura de produção, o GCP é relevante por três motivos: o GKE é referência de maturidade em Kubernetes gerenciado, o Cloud Run definiu o modelo moderno de contêiner serverless e o BigQuery redefiniu o analytics em nuvem. Times que começam pelo GCP costumam vir de contextos de dados, machine learning e serviços web de alto tráfego, embora o catálogo cubra o mesmo espectro dos concorrentes. A hierarquia de organização também é distinta, baseada em projetos, e a rede virtual é global por padrão, o que muda decisões de desenho em comparação com AWS e Azure. Este arquivo mapeia as equivalências por categoria e destaca onde o modelo do GCP diverge de forma relevante.

Hierarquia: projetos, pastas e organização

O GCP organiza tudo em projetos, que são unidades de isolamento de recursos, quotas e cobrança, com um identificador único global. Pastas agrupam projetos, e a organização é o nó raiz que amarra a empresa, com políticas IAM herdadas de cima para baixo. O modelo é mais simples que a hierarquia Azure e mais granular que a árvore de contas da AWS.

Cada projeto recebe um conjunto próprio de quotas e APIs ativadas, o que torna o projeto a fronteira prática de blast radius: um erro de configuração em um projeto não contamina outros. Em produção, a convenção comum é um projeto por ambiente por serviço ou domínio, com pastas por time e billing exportado por projeto para alocação de custo precisa.

O IAM do GCP herdou uma crítica histórica: papéis primitivos como editor de projeto são excessivamente amplos e ainda aparecem em desenhos apressados. O caminho correto é usar papéis predefinidos por serviço ou papéis customizados, concedidos por projeto ou por recurso, com contas de serviço dedicadas por carga de trabalho e revisão periódica pelo IAM Recommender.

Compute: Compute Engine, GKE, Cloud Functions e Cloud Run

A oferta de computação cobre o espectro completo, com dois diferenciais notáveis: o GKE é historicamente o Kubernetes gerenciado mais maduro do mercado, já que a Google criou a tecnologia, e o Cloud Run oferece contêineres serverless com escala a zero e cobrança por segundo.

O Cloud Run merece destaque como modelo arquitetural: você empacota um contêiner HTTP padrão, envia para o Artifact Registry e o serviço instancia concorrências sob demanda, escalando até zero e cobrando apenas pelo tempo de processamento de requisições. Não há nodes para administrar, pool de instâncias para dimensionar nem integração de load balancer para montar; a mesma imagem roda localmente e em produção. Para a maioria das APIs e workers em fila, o Cloud Run entrega o custo operacional mais baixo do GCP, e o GKE Autopilot estende essa filosofia cobrando por pod no Kubernetes sem administrar nodes.

# Deploy de API em contêiner no Cloud Run com concorrência e escala controladas
gcloud run deploy pedidos-api \
  --image sa-east-1-docker.pkg.dev/projeto/pedidos/api:1.4.0 \
  --region southamerica-east1 \
  --min-instances 1 \            # mantém uma instância quente contra cold start
  --max-instances 50 \           # teto de escala para conter custo
  --concurrency 80 \             # requisições simultâneas por instância
  --cpu 1 --memory 512Mi \
  --service-account pedidos-run@projeto.iam.gserviceaccount.com

Storage: Cloud Storage e discos

O Cloud Storage é o armazenamento de objetos unificado, com classes por frequência de acesso: Standard, Nearline, Coldline e Archive, e lifecycle rules que transicionam objetos automaticamente entre classes. É o repositório padrão para data lake, artefatos, backups e mídia, com integração profunda ao BigQuery para consulta direta a dados externos.

# Lifecycle: relatórios vão para Nearline em 30 dias e expiram em 180
rule:
  - action:
      type: SetStorageClass
      storageClass: NEARLINE
    condition:
      age: 30
      matchesPrefix: ["relatorios/"]
  - action:
      type: Delete
    condition:
      age: 180
      matchesPrefix: ["relatorios/"]

Para blocos, o Persistent Disk e o Hyperdisk anexam volumes a instâncias do Compute Engine, com snapshots incrementais e a peculiaridade de discos persistentes regionais replicados entre zonas. Volumes locais SSD entregam latência mínima para bancos de dados sensíveis a IOPS. Para sistemas de arquivos compartilhados, o Filestore cumpre o papel do EFS com compartilhamentos NFS gerenciados de desempenho previsível.

Database: Cloud SQL, Spanner e BigQuery

A categoria de banco de dados é onde o GCP mais se diferencia dos concorrentes, com três peças em posições distintas.

O Spanner é único no mercado: um banco relacional com consistência forte, transações distribuídas e replicação multi-região automática, viável quando o relacionamento relacional precisa escalar horizontalmente sem abrir mão de consistência. O BigQuery é a joia da coroa do GCP em analytics: sem cluster para administrar, cobrança por TB escaneado ou capacidade reservada, e integração nativa com pipelines de streaming, o que explica por que times de dados frequentemente escolhem o GCP como nuvem principal mesmo mantendo sistemas em outro provedor.

A escolha entre eles segue o padrão de acesso e o requisito de consistência. Cloud SQL cobre o transacional convencional até os limites de instância vertical e réplicas de leitura; Spanner entra quando a escrita ultrapassa um nó ou quando disponibilidade multi-região com consistência forte é requisito contratual; BigQuery fica fora do caminho transacional e serve a analítica com custo proporcional ao dado escaneado, não ao tempo de uptime.

Networking: VPC global, Cloud Load Balancing e Cloud DNS

A VPC do GCP é global por padrão: uma mesma rede atravessa regiões, e sub-redes são alocadas por região, invertendo a lógica da VPC regional da AWS. Firewall rules aplicam filtragem, VPC peering e VPN interconectam redes, e o Private Google Access permite consumir APIs do GCP por endereço interno, sem saída para a internet.

O Cloud Load Balancing é um balanceador global com um único anycast IP de entrada, roteando para backends na região mais próxima do usuário, na posição de um ALB global sem necessidade de DNS geográfico. Cloud DNS oferece zonas gerenciadas, Cloud CDN integra-se ao balanceador com um campo de configuração, e o Cloud Armor adiciona WAF e proteção contra DDoS na borda. Em arquiteturas multi-região, esse conjunto elimina uma camada inteira de desenho que AWS e Azure exigem por região.

A rede global é também um argumento de custo e latência: tráfego entre regiões do GCP percorre a espinha própria da Google, com latência menor e modelos de preço diferentes dos concorrentes. Sistemas com usuários distribuídos em continentes distintos, bancos multi-região ou desenhos ativo-ativo se beneficiam de forma direta dessa base de rede.

Cloud Run como modelo de contêiner serverless

O Cloud Run mudou o vocabulário de arquitetura serverless ao unir contêiner e função em um único modelo: qualquer binário em contêiner que escute HTTP torna-se um serviço escalável, sem reescrever código para o runtime do provedor. As consequências práticas em produção são diretas: portabilidade total da imagem, debugging local idêntico ao de produção, e migração simples para GKE ou para outra nuvem quando o caso exige.

O serviço também aceita requisições de fila do Pub/Sub, jobs em lote agendados e workers de eventos, cobrindo padrões de arquitetura orientada a eventos com o mesmo modelo de deploy. Limites de CPU por requisição, timeouts e concorrência máxima por instância são os três parâmetros que demandam tuning real, e a combinação de min-instances e CPU boost cuida do cold start nas rotas sensíveis.

O modelo de concorrência é o outro diferencial em relação ao FaaS tradicional: em vez de uma requisição por execução, o Cloud Run multiplexa até dezenas de requisições HTTP na mesma instância, o que reduz custo e cold start para cargas de I/O, e exige apenas que o contêiner seja seguro para concorrência.

Tabela de equivalências entre os três provedores

A leitura correta da tabela é por posição competitiva: AWS lidera em amplitude de catálogo, Azure em integração corporativa e GCP em dados, Kubernetes e rede global, e o desenho de produção deve explorar a força principal do provedor escolhido em vez de replicar hábitos de outra nuvem.

Aplicação prática: topologia de referência

Uma topologia de produção no GCP aproveita a rede global desde o desenho. O Cloud Load Balancing recebe o tráfego em um anycast IP, com Cloud Armor filtrando ataques e Cloud CDN servindo o conteúdo estático; backends Cloud Run em duas regiões atendem a API; Cloud SQL com réplicas regionais guarda o transacional, e BigQuery alimenta o BI a partir do data lake em Cloud Storage. Pub/Sub desacopla eventos entre serviços, e Secret Manager entrega credenciais via service account dedicada.

Essa topologia usa a força de dados do GCP como parte do desenho principal, e não como anexo posterior, e o custo total tende a ser competitivo precisamente porque BigQuery e Cloud Run cobram por uso efetivo, alinhando despesa a valor entregue.

Erros comuns e boas práticas

• Tratar o projeto como repositório de tudo: sem separação por ambiente e domínio, quotas, cobrança e IAM viram um imbróglio; um projeto por ambiente é o piso.
• Ignorar que a VPC é global e desenhar como se fosse regional, criando rotas e peering desnecessários entre regiões.
• Provisionar BigQuery sem controles: consultas ad hoc sem custo máximo configurado podem escanear terabytes; defina custom quotas por usuário e slots reservados para cargas previsíveis.
• Usar Cloud SQL para tudo, incluindo casos que pedem Spanner para consistência global ou BigQuery para analytics, e encontrar o teto de escala tarde demais.
• Não configurar min-instances no Cloud Run em rotas de latência crítica e sofrer cold start em picos de tráfego.
• Deixar contas de serviço com papéis amplos de editor de projeto; prefira papéis específicos por serviço e audite com o IAM Recommender.
• Copiar desenhos de VPC regional da AWS sem revisar rotas, já que sub-redes e peering se comportam de forma diferente na VPC global.
• Ativar APIs e serviços sem dono em projetos compartilhados; cada API ativa amplia a superfície de ataque e o custo de auditoria.

Como prática consolidada, padronize a criação de projetos com Terraform e pastas por time desde o primeiro dia, habilite o export de billing para BigQuery para analítica de custo, e adote Cloud Run como padrão inicial de API, subindo para GKE apenas quando requisitos concretos de platform engineering ou integração fina de rede justificarem a complexidade adicional.