Arquitetura cloud
Arquitetura cloud é um desenho operacional, não uma escolha de hospedagem.
Um mapa prático para contexto de workload, compute, dados, rede, identidade, segredos, ambientes, serviços gerenciados, escala, resiliência, observabilidade, segurança, custos e evolução.Definição
Arquitetura cloud é o conjunto de decisões estruturais e operacionais que define como aplicações, dados e infraestrutura são implantados, protegidos, observados, escalados e evoluídos por meio de recursos cloud. Cloud não significa automaticamente microservices, serverless ou infraestrutura global. Mover uma aplicação para uma máquina virtual não basta; a arquitetura está nas decisões operacionais e seus trade-offs.
Por que arquitetura cloud importa
Cloud afeta disponibilidade, implantação, recuperação, segurança, escalabilidade, velocidade de entrega, custo, observabilidade, integração e responsabilidade do time. Pode reduzir carga operacional quando serviços gerenciados encaixam, mas também pode adicionar complexidade, dependência e custo quando serviços são escolhidos por moda.
Problemas que ajuda a esclarecer
- Infraestrutura é escolhida antes de entender o workload.
- Deployment, release, rollback e migrações são tratados como o mesmo problema.
- Segredos e configuração são copiados entre ambientes sem propriedade clara.
- Serviços gerenciados são adotados sem entender limites, observabilidade ou custo de migração.
- Escala é pensada apenas como tráfego e ignora dados, filas, integrações e custos.
- Confiabilidade vira uptime sem restore ou degradação planejada.
- Logs são acumulados sem responder perguntas operacionais ou proteger dados sensíveis.
- Custo aparece como surpresa porque arquitetura e capacidade foram separadas.
Workload e contexto
Decisões cloud começam por tipo de aplicação, tráfego, criticidade, sensibilidade dos dados, latência, geografia, orçamento, frequência de implantação, integrações, crescimento e capacidade técnica. Um produto em validação não deveria herdar a complexidade de uma plataforma madura.
- Projetar para risco e crescimento reais.
- Evitar escolher pelo catálogo do provedor antes dos requisitos.
- Separar validação de produto de necessidades de plataforma.
Modelo de compute
Compute pode ser máquinas virtuais, containers, funções serverless, plataformas gerenciadas, hosting estático, edge ou modelos híbridos. Cada opção muda controle, operação, escala, cold starts, portabilidade, complexidade, custo e observabilidade.
- Não assumir que containers ou serverless são melhores por padrão.
- Usar hosting estático ou plataformas gerenciadas quando a carga é simples.
- Não afirmar necessidade de Kubernetes sem evidência pública.
Dados e armazenamento
Dados cloud incluem relacional, documentos, object storage, caches, filas, backups, replicação, ciclo de vida, retenção, recovery, propriedade, consistência e migrações. A escolha depende de padrões de acesso, operação e risco.
- Projetar restore, não só backups.
- Tratar filas e caches como decisões com falhas próprias.
- Usar Firebase apenas como exemplo gerenciado relevante.
Rede e limites
Networking define exposição pública ou privada, APIs, ingress, egress, DNS, TLS, firewalls, limites de serviço, origin, CDN, proxy, comunicação interna e integrações externas. Reduzir exposição é arquitetura.
- Tornar explícitos os pontos públicos.
- Separar responsabilidades de CDN, proxy e origin.
- Não expor serviços internos se uma API basta.
Identidade e acesso
Arquitetura cloud deve distinguir autenticação da aplicação de acesso à infraestrutura. Usuários, serviços, roles, permissões, least privilege, identidades de máquina, acesso administrativo, ambientes, rotação e auditoria precisam ser nomeados.
- Separar login de usuário de permissões cloud.
- Aplicar least privilege a pessoas e serviços.
- Manter acesso administrativo auditável.
Configuração e segredos
Configuração inclui variáveis de ambiente, valores runtime ou build-time, desenvolvimento local, CI/CD e deployment. Segredos precisam de armazenamento controlado, limites de acesso, rotação e proteção contra source control ou builds públicos.
- Não tratar .env local como estratégia completa.
- Manter segredos fora do código e do output público.
- Planejar rotação por ambiente.
Ambientes e implantação
Development, staging, production e preview devem ter isolamento suficiente para proteger dados e confiança de release sem virar teatro operacional. Deployment move software; release expõe comportamento.
- Manter artifacts e configuração previsíveis.
- Planejar rollback e migrações juntos.
- Não forçar ambientes complexos em projetos simples.
Serviços gerenciados
Serviços gerenciados reduzem manutenção, aceleram entrega e integram disponibilidade, mas trazem limites, pricing, observabilidade, configuração, dependência e custo de migração. Managed nem sempre é mais barato.
- Usá-los quando reduzem risco operacional real.
- Entender limites antes de depender deles.
- Aceitar lock-in útil deliberadamente.
Escalabilidade
Escalabilidade inclui vertical, horizontal, stateless workloads, filas, cache, concorrência, autoscaling, rate limits, backpressure, bottlenecks de dados e custo. Pode significar mais usuários, dados, integrações, tenants, regiões, times ou processos.
- Medir bottlenecks antes de adicionar infraestrutura.
- Usar filas e backpressure quando o síncrono fica frágil.
- Não recomendar microservices automaticamente.
Confiabilidade e resiliência
Confiabilidade exige pensar falhas: retries, timeouts, filas, redundância, backups, restore, degradação, health checks, rollback, dependências e disaster recovery. Nem toda app precisa multi-region.
- Projetar restore, não só backups.
- Usar degradação quando disponibilidade total não é realista.
- Ajustar objetivos ao impacto de negócio.
Observabilidade
Observabilidade deve responder perguntas operacionais com logs, métricas, traces, alertas, health, versão, correlação, latência, falhas, custos e contexto de usuário ou tenant quando apropriado. Mais logs nem sempre ajudam.
- Coletar sinais úteis para decisões.
- Correlacionar frontend, backend e release quando útil.
- Evitar registrar dados sensíveis.
Segurança
Segurança cloud inclui responsabilidade compartilhada, least privilege, criptografia, segredos, patching, exposição de rede, dependências, backups, auditoria, logging, minimização de dados, incident response e limites de ambiente. Não significa segurança absoluta.
- Minimizar exposição e privilégios.
- Tornar visíveis limites de segurança em deployment e operação.
- Não afirmar certificações sem evidência.
Custo e capacidade
Arquitetura e custo se conectam por custos fixos e variáveis, recursos idle, pricing por request, storage, transfer, logging, serviços gerenciados, scaling, budgets, alertas e capacity planning.
- Rastrear drivers de custo cedo.
- Usar budgets e alertas como controles.
- Tratar capacidade como parte da arquitetura.
Portabilidade e dependência de provedor
Lock-in nem sempre é ruim e evitá-lo totalmente também não é grátis. Portabilidade envolve managed services, abstrações, custo de migração, simplicidade operacional, protocolos padrão e capacidades específicas.
- Evitar camadas abstratas sem risco real.
- Usar protocolos padrão quando mantêm opções.
- Documentar custo de migração.
Evolução e dívida técnica
Infraestrutura acumula dívida: drift, recursos sem uso, runtimes antigos, permissões crescentes, deploys manuais, ambientes inconsistentes, upgrades, migrações e serviços depreciados. Replatforming raramente é a primeira resposta.
- Limpar infraestrutura sem uso.
- Automatizar operações repetíveis.
- Evoluir cloud com maturidade de produto e time.
Quando não sobrearquitetar
Um site estático, produto com pouco tráfego, time pequeno, dados simples ou orçamento limitado pode precisar de hosting estático, backend gerenciado, banco administrado ou poucas funções serverless, não uma plataforma distribuída complexa.
- Usar complexidade proporcional.
- Preferir deployment simples se o risco é baixo.
- Não ignorar segurança, backups ou observabilidade básica.
Princípios
Projetar a partir do workload
O catálogo do provedor é insumo, não estratégia. O workload define a forma operacional.
- Nomear tráfego, dados, latência e time.
- Escolher serviços depois dos requisitos.
Usar managed por risco real
Managed services são mais úteis quando removem manutenção que o time não deveria possuir.
- Usá-los deliberadamente.
- Entender limites e migração.
Explicitar identidade e acesso
Sistemas cloud precisam de permissões claras para pessoas e máquinas.
- Separar usuários de infraestrutura.
- Auditar caminhos administrativos.
Tratar falha como esperada
Dependências, deploys e redes falham. A arquitetura precisa de recuperação.
- Planejar retries e timeouts.
- Testar restore.
Ambientes reproduzíveis
Diferenças entre ambientes devem ser intencionais e visíveis.
- Isolar configuração.
- Evitar drift manual.
Observar antes de escalar
Escalar sem sinais costuma mover o bottleneck ou aumentar custo.
- Medir latência, erros e capacidade.
- Escalar a parte limitada.
Custo é arquitetura
A arquitetura decide comportamento de custo com storage, compute, logs, transfer e idle capacity.
- Adicionar budgets e alertas.
- Revisar custo com padrões de uso.
Decisões arquiteturais chave
Modelo de compute
Pergunta: onde roda o workload? VMs, containers, serverless, plataformas gerenciadas e hosting estático mudam operação, custo e escala. Risco: escolher um modelo que o time não consegue operar.
- Ajustar compute ao workload.
- Manter o modelo viável mais simples.
Deployment e release
Pergunta: como código chega à produção e é exposto ao usuário? Trade-off: velocidade versus rollback e migração. Risco: cada deploy vira incidente manual.
- Separar deployment de release.
- Planejar rollback e migrações.
Data stores
Pergunta: que armazenamento encaixa com acesso e recovery? Trade-off: conveniência gerenciada versus limites. Risco: dados difíceis de recuperar ou evoluir.
- Escolher por comportamento dos dados.
- Projetar backups e lifecycle.
Exposição de rede
Pergunta: o que deve ser público, privado ou proxied? Trade-off: acessibilidade versus superfície de ataque. Risco: capacidades internas expostas sem querer.
- Expor só entradas necessárias.
- Clarificar CDN, proxy e origin.
Identidade e acesso
Pergunta: quem pode operar cada capacidade? Trade-off: conveniência versus auditoria. Risco: permissões crescem até ficarem ilegíveis.
- Modelar identidades humanas e de máquina.
- Rotacionar e revisar credenciais.
Estratégia de ambientes
Pergunta: quantos ambientes são necessários? Trade-off: confiança versus custo operacional. Risco: staging não parece produção ou dados vazam.
- Isolar conforme risco.
- Tornar diferenças intencionais.
Managed ou self-managed
Pergunta: que responsabilidades o provedor assume? Trade-off: menos manutenção versus limites. Risco: o time possui operação demais ou fica preso a uma escolha ruim.
- Aceitar lock-in útil.
- Evitar self-managed sem capacidade.
Objetivo de confiabilidade
Pergunta: que falhas o sistema deve suportar? Trade-off: resiliência versus custo. Risco: gastar com falhas imaginárias ou ignorar falhas reais.
- Definir por impacto de negócio.
- Projetar degradação.
Modelo de observabilidade
Pergunta: como o time saberá o que acontece? Trade-off: sinal versus ruído, custo e privacidade. Risco: incidentes sem contexto ou logs sensíveis.
- Nomear perguntas operacionais.
- Coletar sinais seguros.
Controles de custo
Pergunta: como uso vira gasto? Trade-off: elasticidade versus previsibilidade. Risco: custo escala mais rápido que valor.
- Adicionar budgets e alertas.
- Revisar capacidade idle e logs.
Perspectivas futuras em desenvolvimento
Estes temas estão planejados sob o hub de arquitetura cloud. Ainda não são rotas públicas.
- Serverless, containers ou managed platforms: como decidir.
- Arquitetura cloud é mais que hospedagem.
- Como desenhar ambientes production, staging e preview.
- Quando serviços gerenciados valem o lock-in.
- Confiabilidade sem complexidade multi-region prematura.
- Custo como requisito arquitetural.