As decisões que destruíram a confiança no Azure – o relato de um ex-engenheiro do Azure Core
(isolveproblems.substack.com)- Um ex-engenheiro descreve em detalhes como o acúmulo de decisões irreais dentro do Microsoft Azure Core levou ao caos técnico e ao colapso da confiança
- Entre os principais problemas apontados estão um plano de portar recursos do Windows ignorando restrições de hardware e a proliferação de 173 agentes de gerenciamento
- Essa estrutura complexa sustenta workloads críticos como OpenAI, Anthropic e nuvem governamental, criando o risco de que uma única falha se espalhe como uma interrupção global
- Diante da falta de resposta da liderança, ocorreram desdobramentos como a deterioração da relação com a OpenAI, a perda de confiança do governo dos EUA e o atraso no lançamento de recursos
- Como resultado, isso teria levado ao desaparecimento de US$ 1 trilhão em valor de mercado, reforçando a importância de reconhecer a realidade técnica e manter a simplicidade na operação de infraestrutura de nuvem
Registro interno do colapso de confiança no Azure
- Memórias de um ex-engenheiro sobre o processo interno de decisões irreais na equipe Microsoft Azure Core e a confusão técnica e organizacional resultante
- Já no primeiro dia na equipe de P&D Overlake, ele testemunhou discussões sobre um plano de portar funcionalidades do Windows ignorando limitações de hardware
- Havia 173 agentes de gerenciamento, mas a complexidade e a opacidade eram tão graves que ninguém parecia saber exatamente sua função ou necessidade
- Essa estrutura sustenta workloads essenciais, como OpenAI, Anthropic e nuvens governamentais, o que cria o risco de que um único erro provoque uma falha global
- O autor afirma que isso acabou levando à perda de confiança da OpenAI, à desconfiança pública do Departamento de Defesa dos EUA e ao desaparecimento de US$ 1 trilhão em valor de mercado
Entrada no Azure Core e situação inicial
- Em 1º de maio de 2023, ele entrou como engenheiro sênior na equipe de P&D Overlake, responsável pelo cartão de offload Azure Boost e aceleradores de rede
- Antes disso, havia participado das equipes do Windows e do Core OS, trabalhando em melhorias de kernel e desenvolvimento de plataforma de contêineres, contribuindo para tecnologias centrais como Docker, AKS, App Services e Windows Sandbox
- Também participou do projeto inicial do cartão Overlake (2020~2021), propondo um protocolo de comunicação entre o sistema operacional host e o cartão acelerador
- Retornou como um especialista que havia operado e desenvolvido diretamente a plataforma Azure por mais de 10 anos
O plano irreal visto na primeira reunião
- No primeiro dia, durante a reunião mensal de planejamento da equipe, ele confirmou a existência de um plano para portar componentes do Windows para o cartão Overlake
- Apesar de o cartão Overlake ter capacidade de RAM e orçamento de energia extremamente limitados, a equipe discutia a tentativa de migrar recursos do Windows
- Era um plano impossível dadas as especificações de hardware, e chegou-se até a sugerir: “vamos deixar alguns desenvolvedores juniores tentarem”
- A organização considerava seriamente a direção de portar o Windows para Linux para manter agentes de gerenciamento de VM
- O autor descreve isso como um “plano desconectado da realidade” e concluiu que toda a organização havia iniciado uma marcha rumo a um objetivo impossível
Limitações técnicas e problemas estruturais
- Na época, a stack conseguia processar apenas algumas dezenas de VMs em uma CPU Xeon de 400W, bem abaixo do limite de 1.024 VMs do hipervisor
- Havia também problemas de degradação de desempenho, como jitter nas VMs dos clientes, causados pelo uso excessivo de recursos
- O plano de portar e escalar essa stack ineficiente para um pequeno SoC ARM era tecnicamente inviável
- O autor resume dizendo que “mais urgente do que aprender uma nova tecnologia era trazer toda a organização de volta à realidade”
Conversas internas sobre Azure Linux e Overlake
- Em uma conversa de 90 minutos com o responsável pelo Linux System Group, ele confirmou que 173 agentes haviam sido designados como candidatos a port para o cartão Overlake
- Após investigar, constatou que ninguém dentro da Microsoft conseguia explicar claramente o papel, as interações ou o motivo de existência desses 173 agentes
- O núcleo do Azure é composto por VM, rede e armazenamento, e os demais serviços são construídos sobre isso, mas a complexidade desnecessária foi se acumulando
- Esse conjunto incontrolável de componentes é o que gerencia workloads importantes como OpenAI, Anthropic e nuvens governamentais
Perda de confiança e consequências posteriores
- Essa estrutura complexa estava em um estado capaz de causar riscos graves à segurança nacional e à continuidade dos negócios
- As cartas enviadas depois ao CEO, ao conselho de administração e ao EVP da divisão Cloud+AI terminaram todas sem resposta
- Como consequência, teriam ocorrido a deterioração da relação com a OpenAI, o colapso da confiança do governo dos EUA (com declarações públicas do secretário de Defesa), desperdício de engenharia e ordens de migração para Rust, além de atrasos no lançamento de recursos
- O autor define isso como um “evento que evaporou US$ 1 trilhão em valor de mercado” e alerta empresas que usam Azure sobre os riscos de depender dele em ambientes de produção
Conclusão
- O texto expõe como o acúmulo de complexidade técnica, má gestão e decisões irreais dentro do Azure levou à perda de confiança
- É um caso de uma organização responsável por infraestrutura crítica que perdeu o senso de realidade e continuou marchando rumo a uma falha estrutural
- Destaca-se a importância da estabilidade e da simplicidade na infraestrutura de nuvem, bem como da manutenção do discernimento técnico dentro das organizações
1 comentários
Comentários do Hacker News
Como alguém que usa o Azure todos os dias, se essa denúncia for verdadeira, parece que muita coisa finalmente faz sentido
A UI é mal-acabada, a documentação é imprecisa, como se tivesse sido escrita por IA, e há tantos tipos de serviço que nem dá para saber qual usar
É difícil configurar sem ajuda de consultores e, mesmo depois de configurar, não dá para ter certeza de que está funcionando direito
Sinceramente, é impressionante que isso ainda esteja de pé
Desde então, não confio mais na documentação
Um serviço que rodava de forma estável no GCP ficou imprevisível
Já vi o Azure OpenAI vazar respostas de prompts de outros clientes quando está sob carga
Há até um tweet relacionado
Mas parece que ninguém se importa
A situação parece um completo velho oeste
Fiquei surpreso com o nível de detalhe das alegações deste texto
Dá curiosidade saber se é um denunciante interno ou só um ex-funcionário ressentido
A parte de ter reportado diretamente ao CEO e ao conselho chamou especialmente a atenção
Parece estranho que esse tipo de procedimento seja “de praxe” na cultura corporativa americana
Gostaria de saber, pela experiência real de usuários, se o Azure é mesmo tão instável assim
O Azure não percebe o problema, não sabe a causa e parece que nem se importa
O time inteiro odeia o Azure
Fiquei feliz quando o AWS Bedrock passou a permitir usar modelos da OpenAI, porque assim dava para evitar o Azure
A confiabilidade continua sendo um problema gravíssimo
A estratégia de “lançar rápido e consertar depois” acaba levando exatamente a esse tipo de resultado
Desde então, deixei de confiar
O texto parece um tanto emocional e exagerado, o que dá a impressão de que a intenção original se perdeu
A estrutura interna de cargos do Azure ou problemas de nível Sev2 não são nada tão incomum
O Azure tem problemas, mas, dada a escala, é natural que existam partes ásperas
A verdadeira maturidade, na minha opinião, é tentar melhorar o sistema por dentro
O Azure pode ser uma bagunça, mas a abordagem do autor também pode ter sido parte do problema
Minha impressão do Azure é totalmente negativa
A abordagem do autor acaba reduzindo ainda mais a credibilidade
A frequência com que novos funcionários soltam um “wtf/day” parece quase um indicador de saúde organizacional
Mesmo de fora, o Azure parece ter a qualidade no fundo do poço
Na pressa de alcançar a AWS, foram despejando recursos às pressas e acabaram presos num enorme pântano de dívida técnica
Até recursos básicos como IPv6, azcopy e upgrades de VM continuam instáveis
Um ex-colega usa Azure todos os dias, e toda vez que ouço as explosões de reclamação dele, entendo melhor o conteúdo deste texto
Quando escolhi me especializar em nuvem, 12 anos atrás, experimentei Azure rapidamente e achei uma plataforma lenta e quebrada; este texto confirma aquela impressão
Na parte final, achei marcante o trecho dizendo que a Microsoft demitiu 15.000 pessoas em 2025
Parece um exemplo da realidade por trás do boom da IA
O contrato com a OpenAI era uma questão de capacidade de GPU, e as demissões são outra coisa
O problema real é a rotatividade de engenheiros e a ausência de responsabilidade
Gente nova entra em cada projeto, e o senso de dono desaparece
A parte que diz que, se o host for comprometido, é possível acessar toda a memória das VMs soa extremamente perigosa
Foi irônico ver lado a lado a citação da CNBC de que o salário de Satya Nadella subiu 22%, para US$ 96,5 milhões, e a fala de um astronauta da Artemis II dizendo que “os dois Outlooks não funcionam”
O texto parece exagerado em alguns pontos, mas, como alguém que já operou sistemas parecidos, lembro de ter que lutar sem parar para manter a estabilidade
Vi problemas semelhantes em outras empresas, mas não na gravidade da escala do Azure
Esse tipo de estrutura parece acabar levando a um loop de autodestruição
Usei Azure em 2018, e ele era lento, caro e de péssima qualidade
No fórum do GitHub, eu e outros usuários tentávamos resolver problemas em que até funções básicas não funcionavam
Este texto esclarece dúvidas que eu tinha desde aquela época
Pessoalmente, sempre achei o Google Cloud a plataforma mais bem projetada, mas é uma pena que tenha menos suporte humano do que a AWS
Meu responsável mudou três vezes em três meses, e às vezes pedidos de quota ou dúvidas sobre limites do sistema simplesmente eram ignorados