Aplicando padrões WAF a arquiteturas reais

Aplicar padrões do WAF a arquiteturas reais não é um exercício teórico — exige avaliar cada decisão de design com base nos cinco pilares e fazer compensações fundamentadas. Um ponto de partida comum é o diagrama da arquitetura: trace o caminho de uma solicitação do usuário por cada componente e pergunte, em cada etapa, o que acontece se esse componente falhar, quanto ele custa e como ele é protegido.

Considere um aplicativo Web monolítico tradicional: uma única VM executando um servidor Web e um banco de dados juntos, atrás de um IP público. Em relação aos pilares do WAF, ele apresenta uma pontuação baixa nos cinco: nenhuma redundância (confiabilidade), banco de dados no mesmo host que a camada Web (segurança), VM sempre ligada independentemente do tráfego (custo), nenhum CI/CD (excelência operacional) e somente dimensionamento vertical (eficiência de desempenho).

Para abordar o pilar de Confiabilidade, distribua a camada Web entre várias VMs em diferentes zonas de disponibilidade, faça a replicação geográfica do banco de dados para uma região secundária e coloque um Balanceador de Carga do Azure na frente. Isso elimina o ponto único de falha e permite que o aplicativo continue funcionando após uma interrupção em uma zona ou região, sem intervenção manual.

Para o pilar de Segurança, separe a camada Web e o banco de dados em sub-redes diferentes, com regras de NSG que permitam somente que a camada Web se conecte à porta do banco de dados. Armazene a cadeia de conexão do banco de dados no Azure Key Vault e use uma identidade gerenciada no aplicativo Web para recuperá-la em tempo de execução, eliminando credenciais codificadas diretamente no código do aplicativo e nos arquivos de configuração.

Para a Otimização de Custos, substitua as VMs sempre ligadas por um conjunto de dimensionamento de Máquinas Virtuais que reduza a capacidade fora dos horários de pico. Para o banco de dados, avalie se um serviço PaaS gerenciado, como o Azure SQL Database, com uma camada de DTU apropriada, custa menos do que uma VM completa com o SQL Server. Adquira Instâncias Reservadas para qualquer capacidade básica que possa ser prevista com 12 meses de antecedência.

Melhore a Excelência Operacional definindo toda a infraestrutura como modelos Bicep ou ARM armazenados no controle de versão. Crie um pipeline de CI/CD no Azure Pipelines ou no GitHub Actions que implante automaticamente alterações na infraestrutura e no código do aplicativo. Adicione etapas de aprovação da implantação — testes automatizados de fumaça e aprovação manual — antes que as alterações cheguem à produção.

Para a Eficiência de Desempenho, introduza o Azure Cache for Redis na frente do banco de dados para armazenar em cache as consultas lidas com frequência e reduzir a carga do banco de dados. Implante recursos estáticos (imagens, CSS, JavaScript) por meio do Azure CDN para disponibilizá-los a partir de nós de borda próximos aos usuários em todo o mundo. Faça testes de carga no aplicativo após cada alteração para confirmar que as melhorias são mensuráveis.

Toda alteração arquitetural envolve uma compensação. Por exemplo, migrar para uma arquitetura com várias zonas melhora a confiabilidade, mas aumenta o custo (duas zonas = duas VMs). Adicionar o cache do Redis melhora o desempenho, mas acrescenta complexidade operacional (mais um serviço para monitorar e manter). Uma boa documentação da arquitetura registra essas compensações explicitamente, para que os futuros arquitetos entendam por que as decisões foram tomadas.

Evite tentar alcançar a perfeição em uma única reformulação — essa abordagem é cara, arriscada e lenta. Em vez disso, adote um ciclo de melhoria iterativa: faça uma revisão Well-Architected, identifique os três problemas de maior impacto, corrija-os, meça a melhoria e repita o processo. Essa abordagem alinha as melhorias arquiteturais à entrega ágil e torna o progresso visível para as partes interessadas a cada sprint.

A Microsoft publica arquiteturas de referência para padrões comuns de cargas de trabalho no Centro de Arquitetura do Azure. Elas incluem arquiteturas de aplicativos Web, microsserviços no AKS, pipelines de análise de dados e muitas outras. Cada arquitetura de referência já foi avaliada em relação aos pilares do WAF e inclui observações sobre as compensações feitas para aquele padrão específico.

Use Registros de Decisões de Arquitetura (ADRs) para documentar escolhas arquiteturais importantes, o contexto em que foram tomadas, as alternativas consideradas e as implicações para os pilares do WAF. Os ADRs armazenados no controle de versão junto à base de código criam um histórico auditável que ajuda os novos integrantes da equipe a entender por que a arquitetura tem o formato atual.

Teste sua compreensão dos conceitos do Microsoft Azure Fundamentals (AZ-900) abordados nesta lição.

Nesta lição, você aprendeu que os padrões do WAF são aplicados avaliando cada decisão arquitetural em relação aos cinco pilares; as melhorias podem ser feitas iterativamente, começando pelos problemas de maior impacto; e as compensações devem ser documentadas para que os futuros arquitetos entendam o raciocínio. A seguir, exploraremos os SLAs do Azure e como calcular SLAs compostos para arquiteturas com vários serviços.