Nuvem, computação e containers: modelo mental e decisões

O problema e por que importa

Nuvem oferece capacidades sob demanda e uma divisão de responsabilidades, não terceiriza automaticamente arquitetura, segurança ou operação. VM, container, PaaS e serverless mudam quem gerencia cada camada e quais limites ficam visíveis.

Para hospedar a API de manutenção, a pergunta é: qual parte a equipe precisa controlar e qual parte consegue delegar sem perder portabilidade, observabilidade ou requisitos de segurança? A opção mais flexível também pode exigir mais operação.

Vocabulário antes das siglas

• IaaS: Infrastructure as a Service; computação, rede e armazenamento básicos gerenciados por API, com sistema e aplicação sob responsabilidade do cliente.
• PaaS: Platform as a Service; plataforma gerenciada para executar aplicações com menos responsabilidade sobre a infraestrutura subjacente.
• SaaS: Software as a Service; aplicação pronta consumida como serviço.
• região: área geográfica de um provedor que contém uma ou mais zonas e serviços.
• zona: domínio de falha fisicamente separado dentro de uma região, conforme definição do provedor.
• VM: máquina virtual que emula um computador e executa seu próprio sistema operacional convidado.
• container: processo isolado que compartilha o kernel do host e usa uma imagem para filesystem e metadados.
• imagem: artefato imutável em camadas usado para criar containers.
• orquestrador: sistema que agenda, atualiza, recupera e conecta cargas distribuídas.
• serverless: modelo gerenciado no qual a plataforma provisiona e escala a execução, ainda sujeito a limites e configuração.
• responsabilidade compartilhada: divisão explícita do que o provedor protege e do que permanece sob responsabilidade do cliente.

Container não é uma VM pequena e serverless não significa ausência de servidores. O modelo correto é perguntar quais controles o provedor opera e quais ainda pertencem à equipe.

Modelo mental

nuvem é aluguel programável de capacidades; abstrações removem trabalho, não responsabilidade. A analogia ajuda a localizar responsabilidades; ela deixa de valer quando esconde concorrência, falhas parciais ou atores maliciosos. Software distribuído não tem uma única percepção de tempo nem sucesso: uma resposta pode se perder depois de um efeito ter ocorrido.

Fronteira e responsabilidade

A aplicação declara artefato, recursos, identidade, rede, configuração e sinais operacionais. A plataforma agenda e reinicia conforme o modelo contratado. Dados, permissões, dependências, custos e comportamento da aplicação continuam sob responsabilidade da equipe.

Escolher orquestrador antes de medir necessidades pode criar uma plataforma mais complexa que o produto. Comece com o serviço gerenciado mais simples que satisfaz isolamento, portabilidade e operação; evolua quando restrições comprovadas exigirem controle adicional.

Decisão orientada por risco

Pergunta de projeto	Decisão inicial	Evidência exigida
Quanto controlar?	Delegar o que não diferencia o produto	Responsabilidades e limites estão documentados
Como isolar falhas?	Zonas e dependências conforme o impacto	Teste remove um domínio de falha
Como empacotar?	Imagem mínima, reproduzível e não privilegiada	Scanner e assinatura validam o artefato
Quando orquestrar?	Após necessidades de escala e operação reais	Complexidade tem owner e SLO

A alternativa mais complexa só é promovida quando essa evidência mostra que a solução atual não atende ao risco. A decisão registra também custo operacional, forma de reversão e responsável.

Caso real: manutenção conectada ao ERP

O eletricista conclui a OS 742. O sistema valida identidade, unidade, estado atual e evidências; persiste a mudança; registra auditoria; publica a integração; informa “sincronização pendente” se o ERP não responder. A decisão deste livro aparece ao executar cargas com isolamento, elasticidade e responsabilidades operacionais explícitas. O sucesso não é apenas HTTP 200: banco, usuário, fila, ERP e telemetria precisam convergir para um estado conhecido.

Falha orientadora

container sem limites esgota nó; serviço regional é tratado como altamente disponível. Trate a falha como cenário de projeto, não exceção improvável. O controle principal é limites, probes, IAM, políticas, IaC, múltiplas zonas quando necessário e plano de saída. Seu teste deve falhar antes do controle e passar depois dele.

Segurança, privacidade e custo

• Use identidade de workload e menor privilégio em vez de chaves estáticas na imagem.
• Execute containers sem root, com filesystem e capacidades mínimas quando possível.
• Mantenha inventário, patching e política de imagens permitidas.
• Defina orçamento e limites de recurso; elasticidade sem controle também é risco financeiro.

O manual de Cybersecurity aprofunda threat modeling, identidade, proteção de dados, supply chain e resposta a incidentes; os controles acima são a aplicação específica nesta disciplina.

Erros frequentes e diagnóstico

1. Tecnologia antes do problema: registre hipótese e atributo de qualidade que justificam a escolha.
2. Caminho feliz apenas: injete timeout, duplicata, concorrência, permissão negada e dado inválido.
3. Métrica de vaidade: acompanhe saturação, throttling, reinícios, utilização, custo por transação e dependência regional e ligue o sinal a uma decisão.
4. Automação sem condição de parada: limite tentativas e torne o estado pendente visível.
5. Documentação sem prova: execute exemplos e conecte diagramas a arquivos, owners e testes.

Critérios de aceite

• Fronteira, dono, entradas, saídas e dependências estão diagramados.
• Caminho feliz e falha parcial possuem testes reproduzíveis.
• O controle “limites, probes, IAM, políticas, IaC, múltiplas zonas quando necessário e plano de saída” tem evidência observável.
• Segurança, privacidade, acessibilidade, custo e operação foram avaliados.
• A métrica “saturação, throttling, reinícios, utilização, custo por transação e dependência regional” possui unidade, janela e responsável.
• Runbook informa diagnóstico, mitigação, recuperação e escalonamento.

Prática e recuperação ativa

1. Desenhe a jornada da OS 742 e marque onde esta camada começa e termina.
2. Explique a diferença entre ocultar uma ação e negar sua autorização no servidor.
3. Injete a falha “container sem limites esgota nó; serviço regional é tratado como altamente disponível” e capture evidência antes/depois do controle.
4. Transfira o raciocínio para um pedido de e-commerce: o que permanece e o que muda?

Entregável verificável: matriz de responsabilidade compartilhada, comparação IaaS/PaaS/serverless, imagem verificada e teste de falha de zona ou instância. A entrega só é aceita quando outra pessoa consegue repetir a verificação.

Fontes primárias e oficiais

Revisão editorial: 2 de agosto de 2026. Confirme versões antes de implementar configuração volátil.

• https://kubernetes.io/docs/concepts/
• https://csrc.nist.gov/publications/detail/sp/800-145/final

Da compreensão à execução

O modelo anterior explica o que precisa permanecer verdadeiro. Agora o caderno transforma essa compreensão em um experimento. Antes de executar, escreva sua previsão; depois compare o observado com o esperado e registre a primeira fronteira onde o estado divergiu.

Objetivo, hipótese e ambiente

Objetivo: demonstrar executar cargas com isolamento, elasticidade e responsabilidades operacionais explícitas em uma fatia da jornada de manutenção. Hipótese: o controle “limites, probes, IAM, políticas, IaC, múltiplas zonas quando necessário e plano de saída” reduz a falha escolhida sem violar o contrato das camadas vizinhas.

Pré-requisitos: Git, terminal, TypeScript ou a tecnologia indicada no exemplo, ambiente local isolado e dados sintéticos. Duração orientativa: 90–180 minutos; depende de prática, não de leitura. Não use credenciais reais nem produção.

sequenceDiagram
  actor E as Eletricista
  participant W as Aplicativo
  participant A as API de manutenção
  participant D as Estado canônico
  participant R as ERP
  E->>W: conclui OS 742
  W->>A: intenção + identidade + idempotency-key
  A->>D: valida e persiste
  A-->>W: estado confirmado ou pendente
  A->>R: integração controlada
  R-->>A: confirmação, rejeição ou timeout

Passo 1 — registre o contrato antes do código

Escreva pré-condição, pós-condição, erros esperados, timeout e política de repetição. Separe “aceito para processamento” de “confirmado pelo ERP”. Defina o que a pessoa verá durante incerteza. O contrato deve caber em uma tabela e ser revisado por negócio, desenvolvimento, segurança e operação.

Situação	Resultado público	Estado interno	Próxima ação
Entrada válida	confirmado ou 202 pendente	registrado	processar/observar
Sem permissão	negação estável	nenhuma mutação	auditar
Duplicata	mesmo resultado lógico	um efeito	responder idempotente
Dependência lenta	timeout controlado	pendente conhecido	retry com limite
Dado incompatível	erro de contrato	quarentena	corrigir/reprocessar

Passo 2 — implemente a menor fatia vertical

O trecho é didático e precisa ser adaptado ao runtime indicado. Ele ilustra a decisão central, não constitui aplicação completa.

resources:
  requests: { cpu: "100m", memory: "128Mi" }
  limits: { cpu: "500m", memory: "512Mi" }
readinessProbe:
  httpGet: { path: /ready, port: 8080 }

Mantenha a mudança pequena: interface, regra, persistência, teste e sinal operacional no mesmo ticket. Evite construir “toda a infraestrutura” antes de uma jornada observável.

Passo 3 — prove o caminho feliz e o negativo

1. Execute uma OS válida e capture resposta, estado persistido e correlation ID.
2. Repita a mesma intenção; o efeito lógico deve continuar único.
3. Remova a permissão; nenhum estado deve mudar.
4. Force timeout do ERP; a UI deve mostrar estado honesto e a fila não pode crescer sem limite.
5. Corrompa um campo do contrato; rejeite-o com erro útil, sem stack trace nem segredo.

O teste negativo é parte do produto. Sem ele, o controle pode existir apenas no diagrama.

Passo 4 — instrumente a decisão

Registre duração, resultado, dependência, versão do contrato e correlação. Não use nome, e-mail, token, payload completo nem user_id como dimensão ilimitada de métrica. Para este livro, acompanhe saturação, throttling, reinícios, utilização, custo por transação e dependência regional. Defina SLI, janela, limiar e ação humana associada.

Exemplo de evento estruturado conceitual:

{
  "event": "work_order.transition",
  "order_id": "742",
  "result": "pending_erp",
  "contract_version": "v1",
  "correlation_id": "demo-01",
  "duration_ms": 184
}

Passo 5 — injete falha e recupere

Falha-alvo: container sem limites esgota nó; serviço regional é tratado como altamente disponível.

• Detectar: qual sinal diferencia falha real de tráfego normal?
• Conter: como impedir propagação, repetição ilimitada ou perda de dados?
• Mitigar: qual recurso pode ser desativado ou degradado com segurança?
• Recuperar: como reprocessar sem duplicar efeito?
• Aprender: qual teste, alerta, ADR ou limite impedirá recorrência?

Use timeout curto no laboratório e retry limitado com atraso e jitter. Um retry não é recuperação quando a operação não é idempotente. Registre itens que exigem intervenção humana em fila consultável; não esconda exceções em log.

Segurança e abuso

Faça uma mini análise: ativo, ator, fronteira, ameaça, impacto, controle e teste. Teste acesso horizontal entre unidades, elevação de perfil, payload grande, repetição rápida, dado fora de ordem e indisponibilidade. O controle esperado é limites, probes, IAM, políticas, IaC, múltiplas zonas quando necessário e plano de saída. Valide no servidor e preserve evidência sem expor segredos.

Troubleshooting

Sintoma	Hipótese	Verificação	Correção segura
Estado diverge do ERP	efeito parcial	correlação + outbox/inbox	reconciliar idempotentemente
Latência cresce	fila ou dependência saturada	p95/p99, lag, pool	backpressure e capacidade
Só um tenant falha	escopo, dado ou quota	dimensão de tenant controlada	corrigir política/dado
Retry aumenta erro	operação não idempotente	contar efeitos por chave	deduplicar e limitar
Dashboard “verde”	SLI não representa jornada	teste sintético E2E	medir resultado do usuário

Critérios de aceite verificáveis

• Caminho feliz, entrada inválida, negação, duplicata e timeout foram executados.
• O segundo envio com a mesma chave não produz segundo efeito.
• Nenhum segredo ou dado pessoal aparece em saída, log ou fixture.
• A falha é detectada por sinal antes da reclamação do usuário.
• Existe estado explícito para pendência e procedimento de reconciliação.
• O resultado inclui teste, captura de telemetria, ADR e atualização do runbook.

Evidência, limpeza e solução comentada

Guarde: comandos, versões, saída dos testes, screenshot do fluxo, consulta de estado e gráfico do sinal. Remova ambiente e dados sintéticos; revogue qualquer credencial de laboratório. A solução adequada não é uma ferramenta específica: é a menor composição que satisfaz o contrato e demonstra recuperação.

Exercícios de transferência

1. Troque ERP por gateway de pagamento. Quais garantias ficam mais rígidas?
2. Troque OS por leitura de sensor offline. Onde ordenar e deduplicar?
3. Reduza o RTO pela metade. Qual custo e complexidade aparecem?
4. Explique em voz alta por que nuvem é aluguel programável de capacidades; abstrações removem trabalho, não responsabilidade é útil e onde a analogia quebra.

Fontes

Consulte as fontes oficiais do capítulo conceitual e registre versão/data no relatório do laboratório. Para observabilidade, use OpenTelemetry; para segurança, use o manual canônico.