Anatomia de um provedor

TL;DR

Galho 2 da trilha Cloud, Bloco 1: como um provedor é montado por dentro — mecânica concreta, não mais só modelo mental. Conta como unidade fundamental, geografia (regions/AZs/edge), plano de controle vs plano de dados, as quatro portas de acesso (console/CLI/SDK/API), responsabilidade compartilhada, e os limites/cotas/SLA que todo contrato de provedor impõe. 6 notas, 3 fases.

Sobre este galho

O Galho 1 deu o modelo mental; este galho abre a caixa e mostra as peças que qualquer provedor — AWS, DigitalOcean, ou outro — compartilha por baixo dos nomes diferentes. A conta como unidade de isolamento e blast radius, a geografia que decide latência/preço/disponibilidade legal do dado, a distinção entre o sistema que orquestra (plano de controle, frágil e otimizado para consistência) e o sistema que serve tráfego (plano de dados, otimizado para ficar de pé), os quatro clientes que falam com a mesma API HTTP, a linha que separa o que o provedor garante do que você garante, e os tetos — cota, rate limit, SLA — que toda arquitetura precisa respeitar.

Audiência primária: quem já entende o modelo mental do Galho 1 e precisa da mecânica concreta antes de tocar em qualquer serviço específico (compute, rede, storage vêm nos galhos seguintes). Audiência secundária: quem já opera nuvem no dia a dia mas nunca formalizou por que o console às vezes cai e a aplicação continua no ar, ou por que um script de automação pode derrubar o plano de controle sem afetar tráfego de produção.

Os primitivos que rodam dentro dessa anatomia (compute, rede, storage) começam no Bloco 2; a bússola de critério arquitetural é o Galho 3; e a identidade — que atravessa toda essa anatomia como perímetro — é o Galho 4.

Iniciado

1. 01 — A conta e a organização — a conta como unidade de isolamento e cobrança, root user, blast radius, Organizations/Teams.
2. 02 — Geografia da nuvem (regions, zonas e edge) — region, availability zone e edge location como três níveis de granularidade.
3. 04 — As quatro portas (console, CLI, SDK e API) — quatro clientes da mesma API HTTP assinada.

Adepto

3. 03 — Plano de controle e plano de dados — dois sistemas com propriedades opostas rodando lado a lado.
4. 05 — O modelo de responsabilidade compartilhada — segurança “da” nuvem vs segurança “na” nuvem.

Magus

6. 06 — Limites, cotas e o contrato do provedor — cotas ajustáveis, rate limit, SLA que garante crédito e não continuidade. Capstone do galho.

Rotas alternativas

Completa

01 → 02 → 03 → 04 → 05 → 06. Percurso linear recomendado para quem está construindo a mecânica do zero.

Já opero nuvem, quero fechar lacunas

03 (plano de controle vs dados raramente é articulado) → 05 (responsabilidade compartilhada é o divisor entre “o provedor falhou” e “eu configurei errado”) → 06 (cotas e SLA batem direto na operação real).

Todas as notas

TABLE fase, status FROM "03-Dominios/Tecnologia/Cloud/02 - Anatomia de um provedor" WHERE type = "concept" SORT file.name ASC

Veja também

• Cloud (MOC do domínio)
• O que é a nuvem, de verdade — Galho 1
• Well-Architected Framework — Galho 3
• Identidade e acesso (IAM) — Galho 4