TL;DR
A maturidade de uma arquitetura no Azure é sustentada por três pilares complementares. O Well-Architected Review (WAR) baseia-se em respostas humanas, enquanto o Azure Advisor foca em telemetria de recursos ativos. Nenhum deles atua antes do deployment. O Azure Architecture Diagram Builder preenche essa lacuna com uma validação estruturada em nível de design, utilizando um pipeline híbrido: uma triagem determinística seguida por análise de LLM. É uma abordagem preventiva, não competitiva.
Por que a validação em tempo de design (design-time) é crucial?
Todo incidente de segurança, estouro de orçamento ou gargalo de performance que já depurei teria sido ordens de magnitude mais barato de mitigar no quadro branco do que em ambiente produtivo. Contudo, o mercado de ferramentas WAF (Well-Architected Framework) historicamente assume que a infraestrutura já existe, seja pela necessidade de telemetria (como o Advisor) ou pelo nível de maturidade necessário para responder a 60+ perguntas de um assessment (como o WAR).
Isso gera um vácuo perigoso: o que acontece entre o desenho inicial (o rascunho) e o provisionamento efetivo no resource group? É exatamente aí que o Diagram Builder entra, criando feedback imediato para as equipes de engenharia.
Como os algoritmos oficiais da Microsoft operam?
É fundamental distinguir o funcionamento das ferramentas que o ecossistema Azure já provê:
1. Azure Well-Architected Review (WAR)
Focado em diagnósticos profundos e periódicos, o WAR é um auto-assessment baseado em questionários.
| Aspecto | Detalhe |
|---|---|
| Input | Respostas humanas para ~60 questões mapeadas no checklist do WAF |
| Scoring | Derivado das respostas; cada "não" ou omissão subtrai pontos da maturidade |
| Uso | Revisões trimestrais; baselining de greenfield ou auditoria em brownfield |
2. Azure Advisor Score
Esta é nossa ferramenta de referência determinística, operando sobre o estado real dos recursos.
O Advisor calcula a saúde baseando-se na proporção de recursos saudáveis contra o total avaliável, integrando o Secure Score do Microsoft Defender for Cloud para a camada de segurança. Ele é indispensável em Runtime, mas, naturalmente, não possui visibilidade sobre o que ainda não foi publicado via pipeline de CI/CD.
O elo perdido: A fase de design
O design-time, o runtime (Advisor) e o review periódico (WAR) são fases complementares. Nossa ferramenta de design adiciona um loop de feedback early-stage, onde os custos de mudança são mínimos.
Funcionamento técnico: O pipeline de validação
O validador combina regras estáticas (deterministic) com a capacidade de análise de LLMs. A lógica vive essencialmente em três arquivos que orquestram a detecção de padrões e a inferência de IA.
Fase 1: O pré-scan determinístico
Executa localmente (client-side) contra a topologia. São 73 regras baseadas em padrões anti-pattern (como single-database ou no-identity) que descontam pontos fixos (ex: -12 para crítico) de um baseline de 100.
Fase 2: Refinamento via Inteligência Artificial
O output do scan é enviado para o LLM. É um recorte focado: o modelo recebe sugestões de melhoria, não apenas uma nota cega. Cada descoberta é rotulada como rule-based ou ai-analysis, oferecendo auditabilidade clara para o arquiteto.
Exemplo Prático
Se desenhamos uma aplicação multi-region sem Microsoft Entra ID ou Azure Key Vault, a ferramenta detecta esses dois patterns de imediato. A IA, por sua vez, complementa o diagnóstico apontando a falta de slots no App Service para deploys seguros e a ausência de documentação de RTO/RPO para o geo-replication do SQL Database. O resultado final é uma arquitetura com score 71/100, com Security aparecendo como o pilar mais crítico.
Perguntas Frequentes
- A validação em tempo de design substitui o Azure Advisor ou o Well-Architected Review (WAR)?
Não, elas são complementares. Enquanto o WAR foca em revisões profundas e periódicas, e o Advisor atua com telemetria sobre recursos já implantados, a validação de design-time atua na fase de desenho, permitindo correções preventivas antes que os custos de refatoração aumentem. - Como funciona o motor de validação do Diagram Builder?
Ele utiliza um pipeline híbrido de duas fases: primeiro, um motor determinístico local (client-side) escaneia topologia e padrões contra 73 regras baseadas em WAF; em seguida, um LLM refina a análise fornecendo contexto e sugestões práticas sem que o prompt precise conter todo o catálogo de regras. - Quais são as principais limitações da ferramenta de design-time?
A ferramenta não possui acesso a telemetria ao vivo da infraestrutura, sofre variações de pontuação (drift) conforme o modelo LLM utilizado e não possui, até o momento, branches dedicados a workloads altamente especializados, como SAP ou IoT complexos.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
