Cloud

Escopo: transversal. Aplica-se a qualquer linguagem ou stack do projeto.

Cloud computing redistribui responsabilidades: o provedor cuida da infraestrutura física, o time cuida da configuração, segurança e arquitetura dos serviços.

A escolha entre gerenciado (PaaS (Platform as a Service, Plataforma como Serviço) / SaaS (Software as a Service, Software como Serviço)) e self-hosted afeta diretamente o custo operacional e a complexidade do time.

Serviços gerenciados entregam alta disponibilidade, backups, atualizações e escalabilidade automática. O custo é financeiro: gerenciado custa mais por hora. O benefício é operacional: o time não opera banco, não configura replicação, não gerencia discos.

Usar gerenciado como padrão. Self-hosted quando há restrição de custo ou requisito que o gerenciado não atende.

Cada serviço opera com exatamente as permissões que precisa. IAM (Identity and Access Management, Gerenciamento de Identidade e Acesso) mal configurado é uma das maiores superfícies de ataque em cloud.

Um Secret (segredo) fica em serviços gerenciados (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) e é injetado em runtime. Variáveis de ambiente plaintext, código commitado e .env no repositório são vetores de vazamento. Ver Segurança para detalhes.

Containers garantem paridade entre ambientes: o que roda em dev é o que vai para prod. Essa paridade elimina a classe de bugs "funciona na minha máquina".

Multi-stage builds separam a etapa de build da imagem final. A imagem de runtime não carrega compilador, dependências de desenvolvimento nem arquivos intermediários. Resultado: imagem menor, superfície de ataque menor.

Imagem base mínima (Alpine, Distroless): quanto menor a imagem, menos pacotes, menos vulnerabilidades potenciais.

Processo sem root: o container opera com um usuário sem privilégios. Se comprometido, o acesso é limitado ao escopo do usuário, não do sistema.

Health check: o container declara como verificar sua própria saúde. O orquestrador usa essa informação para roteamento e restart automático. Container sem health check é container que o orquestrador monitora às cegas.

Todo container em produção declara limites de CPU (Central Processing Unit, Unidade Central de Processamento) e memória. Sem limites, um serviço com leak de memória consome os recursos do host inteiro.

OOMKilled (Out Of Memory Killed, Processo encerrado por falta de memória) é um sinal a investigar. Restart automático silencioso mascara o problema e adia o diagnóstico.

Logs em disco local não funcionam em cloud: containers são efêmeros, instâncias sobem e descem, o disco desaparece com o container.

Toda saída de log vai para um sink centralizado (CloudWatch, Datadog, GCP Logging, Azure Monitor). O padrão é stdout/stderr: o orquestrador captura e encaminha. Nenhum serviço escreve log em arquivo local em produção.

Ver Observabilidade para estrutura de logs, níveis e correlation ID.

O mesmo artefato é promovido de ambiente em ambiente, sem rebuild. Cada ambiente serve um propósito:

artefato → dev → qa → staging → prod

Staging deve espelhar prod em OS, runtime e formato de configuração. Divergência entre staging e prod cria uma classe de bugs que só aparecem em produção.

Desenvolvido por @thiagocajadev · Fork baseado no repositório pmndrs/docs · Poimandres.