Panorama multi-cloud e portabilidade

TL;DR

Galho 23 da trilha Cloud, no Bloco 5 (Provedores e maestria). Existem quatro grandes nuvens, e o sênior sabe traduzir entre elas sem decorar quatro catálogos: cada provedor tem uma filosofia (AWS amplitude, Azure enterprise/Microsoft, GCP dados/rede/K8s, DO simplicidade) e um dialeto de nomes que mapeiam para os mesmos conceitos. Multi-cloud é uma decisão cara que raramente compensa; a portabilidade real vem de desenhar sobre camadas abertas (Kubernetes, Terraform, padrões), não de usar N provedores. 6 notas, 3 fases, fecha com um framework de decisão de provedor.

Sobre este galho

Depois de estudar AWS a fundo (galho 21) e DigitalOcean a fundo (galho 22), este galho preenche o resto do mapa: os outros dois grandes hyperscalers em nível de filosofia e tradução de nomes (não hands-on), a tabela de tradução consolidada dos quatro provedores, e o tema que atravessa toda a conversa de “mais de uma nuvem” — lock-in e portabilidade real.

O fio condutor vai do mito à decisão. Primeiro desmonta o motivo mais repetido em reunião de arquitetura (“vamos ser multi-cloud pra não ficar reféns de um fornecedor”) separando as razões legítimas (regulação, best-of-breed pontual, M&A, DR cross-provider) das ruins (diversificação genérica, poder de barganha fantasioso, portabilidade “por via das dúvidas”). Depois mapeia Azure — a nuvem da identidade corporativa e do mundo Microsoft — e GCP — a nuvem de dados, rede global e Kubernetes de berço —, cada uma com sua própria filosofia de nascimento. Uma tabela de tradução consolida os quatro provedores lado a lado por categoria de serviço. E o galho fecha encarando o tabu do lock-in de frente: ele não é vício, é o preço da alavanca; Kubernetes é a maior ilha de portabilidade real da cloud, mas só porta o compute — load balancer, storage e banco continuam do provedor. O capstone amarra tudo num framework de decisão de provedor.

Audiência primária: quem já domina AWS e/ou DigitalOcean a fundo e precisa reconhecer o terreno quando encontra Azure ou GCP numa vaga, num job ou numa arquitetura herdada, sem refazer o aprendizado do zero. Audiência secundária: quem está numa reunião de arquitetura onde “multi-cloud” ou “vamos evitar lock-in” foi dito como princípio genérico, e precisa de um argumento estruturado (com custo real) para trazer a conversa de volta ao trade-off concreto.

Fronteira

Este galho não ensina Azure ou GCP hands-on — não há tutorial de portal, CLI ou deploy real; isso ficaria para galhos próprios que este panorama deliberadamente não cobre. AWS a fundo é o Galho 21, DigitalOcean a fundo é o Galho 22 — a filosofia de amplitude e de simplicidade, respectivamente, já foram tratadas lá e são o contraponto constante das notas 02 e 03 aqui. Kubernetes gerenciado (o produto em si, EKS/AKS/GKE/DOKS) é o Galho 12 (Containers gerenciados); aqui ele entra só como camada de portabilidade, não como tutorial de operação. Terraform e IaC a fundo é o Galho 16; aqui entra só como camada neutra de processo. FinOps (otimização de custo a fundo, incluindo committed use discounts) é o Galho 19. Este galho trata do mapa entre provedores e da decisão estratégica de usar um, dois ou nenhum lock-in — e linka essas fronteiras em vez de reexplicá-las.

Iniciado

(Este galho não tem nota de fase Iniciado — o público-alvo já chega com AWS e/ou DigitalOcean a fundo; a primeira nota já assume esse chão e parte direto para uma decisão de arquitetura.)

Adepto

2. 02 — Azure em uma nota — a nuvem da Microsoft e do enterprise — a filosofia da Azure (identidade corporativa via Microsoft Entra ID, híbrido via Azure Arc/Stack, integração .NET e Office 365) e o mapa dos seus serviços-núcleo traduzidos pra AWS e DO.
3. 03 — GCP em uma nota — a nuvem de dados, rede e Kubernetes — a filosofia do GCP (data-first via BigQuery, network-first com VPC global, Kubernetes de berço via GKE, opinião forte/catálogo menor) e o mapa dos seus serviços-núcleo traduzidos pra AWS.
4. 04 — A tabela de tradução dos quatro provedores — a tabela mestra de equivalência AWS↔Azure↔GCP↔DO por categoria (compute, storage, dados, rede, mensageria, IaC, identidade, observabilidade), e como usá-la pra reconhecer um provedor novo rápido.

Magus

1. 01 — Por que (e por que não) multi-cloud — as razões reais (regulação, best-of-breed pontual, M&A, DR cross-provider) e as imaginárias (“não colocar os ovos numa cesta só”, poder de barganha, portabilidade “por via das dúvidas”) para usar mais de uma nuvem, e por que multi-cloud custa caro e raramente compensa.
2. 05 — Lock-in e portabilidade — Kubernetes como camada neutra — o trade-off real entre aproveitar serviços gerenciados proprietários (lock-in, mas produtividade) e portabilidade via camadas abertas (Kubernetes, Terraform, OCI, OpenTelemetry) — e por que Kubernetes só porta o compute.
3. 06 — Capstone — a decisão de provedor — síntese do galho: um framework de decisão (fluxograma) que integra filosofia do provedor, legado, compliance, perfil de carga e budget, mais quatro cenários trabalhados e a regra de ouro do lock-in seletivo. Capstone do galho.

Rotas alternativas

Completa

01 → 02 → 03 → 04 → 05 → 06. Percurso do mito (por que não multi-cloud) ao mapa (Azure, GCP, tabela consolidada) à decisão estratégica (lock-in, framework de provedor).

Já domino AWS/DO, só preciso do mapa rápido de Azure e GCP

02 → 03 → 04 — pula direto pras notas de tradução, sem a discussão de multi-cloud ou lock-in.

Preciso argumentar contra um “vamos ser multi-cloud” numa reunião amanhã

01 (o mito, as razões legítimas vs ruins, o custo decomposto) → 05 (lock-in como alavanca, não pecado) → 06 (o framework e a regra de ouro).

Todas as notas

TABLE fase, status FROM "03-Dominios/Tecnologia/Cloud/23 - Panorama multi-cloud e portabilidade" WHERE type = "concept" SORT file.name ASC

Veja também

• Cloud (MOC do domínio)
• AWS a fundo — Galho 21, a filosofia de amplitude que este galho contrasta a cada nota
• DigitalOcean a fundo — Galho 22, a filosofia de simplicidade que este galho contrasta a cada nota