Construindo Azure que Sobrevive ao Mundo Real — com Mike Martin [MVP]

A arquitetura no Azure parece simples quando tudo funciona. O verdadeiro teste começa quando dependências falham, regiões ficam indisponíveis, o tráfego dispara, premissas se revelam erradas, os requisitos mudam e alguém finalmente faz a pergunta incômoda: por que projetamos isso desta forma, afinal?

Neste episódio do M365.FM, Mirko Peters conversa com Mike Martin [MVP] sobre como é a arquitetura do Azure quando precisa sobreviver às condições reais de produção, e não apenas parecer boa em um diagrama.
Mike traz décadas de experiência em desenvolvimento, infraestrutura, arquitetura, liderança, coaching, treinamento e Microsoft Azure. Uma de suas observações mais fortes é que muitos dos problemas que os arquitetos enfrentam hoje não são realmente novos. O DNS ainda quebra. Dependências de IP ainda importam. Os custos ainda se tornam um problema. As integrações ainda falham. As dependências ainda desaparecem no pior momento possível.
O que mudou foi o nível de complexidade que construímos em torno desses problemas.

DO VISUAL BASIC À ARQUITETURA MODERNA DO AZURE
Mike relembra quase três décadas de TI, começando como desenvolvedor de Visual Basic nos anos 1990 e passando por sistemas distribuídos, redes, software corporativo, infraestrutura e, por fim, Azure.
Sua principal observação é simples: o setor continua resolvendo muitos dos mesmos problemas fundamentais, mas as arquiteturas ao redor deles tornaram-se muito mais complexas.
Os sistemas modernos migraram de aplicações cliente-servidor para arquiteturas distribuídas, plataformas em nuvem, contêineres, microsserviços, Kubernetes, ambientes híbridos e, agora, desenvolvimento assistido por IA.
Isso cria possibilidades enormes, mas também um novo risco: a superengenharia.
Mike argumenta que muitas equipes atualmente tornam problemas simples desnecessariamente complicados. Uma boa arquitetura muitas vezes não depende de adicionar mais tecnologia, e sim de saber o que não adicionar.

O QUE UM ARQUITETO DE AZURE FAZ DE FATO?
Para Mike, arquitetura não é escolher o maior número de serviços do Azure nem produzir um diagrama impressionante.
Trata-se de entender quais componentes pertencem uns aos outros, quais devem ser evitados, quais são necessários e como construir algo que seja sustentável, escalável, seguro e resiliente.
A arquitetura inclui muito mais do que computação:

• Identidade
• Redes
• Fluxos de dados
• Segurança
• Monitoramento
• Integração
• Dependências
• Escalabilidade
• Operações
• Recuperação
• Implantação
• Custo

Mike também questiona a ideia de que cloud-native significa automaticamente Kubernetes ou contêineres. O Azure oferece muitos serviços gerenciados e nativos que resolvem problemas sem introduzir sobrecarga operacional desnecessária.
O papel do arquiteto é compreender a solução completa e escolher a arquitetura mais simples que ainda atenda aos requisitos reais.

COMECE PELOS REQUISITOS DE NEGÓCIO, NÃO PELOS SERVIÇOS DO AZURE
Uma das lições mais importantes deste episódio é simples: não comece pela tecnologia.
Antes de decidir entre Azure Kubernetes Service, App Service, Azure Functions, contêineres, Service Bus ou outra plataforma, as equipes devem entender o que a solução realmente precisa fazer.
Perguntas a fazer:

• A solução é interna ou voltada para o cliente?
• Quantos usuários dependerão dela?
• Ela precisa escalar globalmente?
• Por quanto tempo pode ficar indisponível?
• Quantos dados o negócio pode se dar ao luxo de perder?
• Quais requisitos de conformidade se aplicam?
• O que acontece se a aplicação ficar fora do ar por várias horas?
• Quem é afetado?
• Qual nível de suporte operacional é necessário?

Essas perguntas levam diretamente a conceitos como SLAs, SLOs, RTOs e RPOs. Elas também determinam se a arquitetura deve ser de região única, multirregião, ativo-ativo, ativo-passivo ou algo bem mais simples.

RTO E RPO SEM OS JARGÕES
RTO e RPO costumam ser discutidos como siglas técnicas, mas seu significado real é voltado para o negócio.

• RTO — Recovery Time Objective (Objetivo de Tempo de Recuperação): Com que rapidez o sistema deve voltar após uma falha?
• RPO — Recovery Point Objective (Objetivo de Ponto de Recuperação): Quanta perda de dados é aceitável?

Um sistema usado para monitoramento não crítico pode tolerar várias horas de indisponibilidade ou perda de dados. Já um sistema que dá suporte a equipes de primeira resposta, operações financeiras, comércio ou infraestrutura crítica pode exigir recuperação em minutos.
O ponto importante é que esses números não devem ser inventados pelo arquiteto. Eles devem vir do impacto real que uma falha causa ao negócio.
Depois que esses requisitos são compreendidos, podem ser traduzidos em decisões técnicas de projeto.

RESILIÊNCIA NÃO É O MESMO QUE ALTA DISPONIBILIDADE
Mike usa uma analogia simples para explicar a diferença entre disponibilidade e resiliência.
Um sistema altamente disponível pode ter outro componente pronto para assumir quando o principal falha.
Um sistema resiliente é projetado para absorver problemas, continuar funcionando, se recuperar com elegância e voltar ao normal sem entrar em colapso completo.
Essa distinção é importante. Uma aplicação pode estar tecnicamente disponível e, ainda assim, oferecer uma experiência ruim. Ela pode estar:

• Lenta
• Limitada por throttling
• Parcialmente indisponível
• Dependente de um backend com falhas
• Afetada por um problema de integração
• Sob pressão regional

A verdadeira resiliência, portanto, exige mais do que tempo de atividade. Exige uma arquitetura capaz de lidar com carga, erros de aplicação, falhas parciais, problemas regionais, dependências quebradas, incidentes operacionais e recuperação após o incidente.

O AZURE NÃO TORNA SUA APLICAÇÃO RESILIENTE AUTOMATICAMENTE
Uma suposição perigosa é que, como o próprio Azure é altamente disponível, qualquer aplicação executada nele herda automaticamente essa resiliência.
Não herda.
A Microsoft fornece os serviços e recursos que tornam possíveis arquiteturas resilientes. Os clientes ainda precisam projetar para resiliência.
É aqui que os padrões arquiteturais importam:

• Circuit breakers
• Acoplamento fraco
• Processamento assíncrono
• Escalabilidade independente
• Múltiplas zonas de disponibilidade
• Múltiplas regiões
• Mecanismos de failover
• Monitoramento
• Infraestrutura como Código
• Procedimentos de recuperação testados

A Microsoft oferece os blocos de construção. A arquitetura determina se esses blocos realmente criam um sistema resiliente.

POR QUE O PROJETO ASSÍNCRONO IMPORTA
Um dos exemplos mais fortes do episódio vem de sistemas que enfrentam picos de tráfego previsíveis, como portais tributários governamentais.
Um problema comum de projeto ocorre quando cada ação depende de uma operação síncrona no backend.
O usuário clica em um botão. O frontend aguarda o backend. O backend aguarda outro serviço. Uma dependência fica lenta. Eventualmente, toda a experiência do usuário é afetada.
Mike explica por que sistemas com acoplamento fraco costumam ser mais resilientes. Em vez de forçar o frontend a esperar por cada operação do backend, as aplicações podem colocar o trabalho em filas ou sistemas orientados a eventos e permitir que os componentes processem as tarefas de forma independente.
Isso traz várias vantagens:

• Componentes diferentes podem escalar de forma independente
• Um serviço pode falhar sem derrubar toda a plataforma
• Os backends podem processar o trabalho de forma assíncrona
• Picos de tráfego se tornam mais fáceis de absorver
• Os componentes voltados ao usuário ficam menos dependentes do tempo do backend
• As falhas tornam-se mais fáceis de isolar

O MITO DOS 100 POR CENTO DE TEMPO DE ATIVIDADE
Outro tema importante da discussão é a obsessão por 100 por cento de disponibilidade. Mike é muito claro: 100 por cento de tempo de atividade não é um objetivo de arquitetura realista.
Uma solução geralmente é composta por vários serviços. Cada serviço tem seu próprio SLA. Quando várias dependências são combinadas, a disponibilidade composta da solução cai na prática.