Já experimentei as alternativas. Já coloquei coisas em produção na AWS, explorei o GCP e passei algum tempo no DigitalOcean e no Fly.io. Todos funcionam. Mas continuo a voltar para o Azure, e a esta altura já não é por acidente.
Isto não é uma comparação de funcionalidades nem um benchmark. É apenas a resposta honesta a uma pergunta que me fazem com alguma frequência: porquê o Azure?
Encaixa na Stack que Uso de Facto
Desenvolvo com .NET e React. É o meu padrão. E o Azure é feito pela mesma empresa que faz o .NET. Esse alinhamento não é cosmético. A integração com o SDK é genuinamente melhor. A documentação usa exemplos em C# em primeiro lugar. O App Service tem suporte de primeira classe para runtimes .NET desde o primeiro dia, não semanas depois de um lançamento. Quando o .NET 9 saiu, o Azure tinha-o disponível quase de imediato.
Na AWS, o .NET é um cidadão de segunda classe. Funciona, mas sente-se o atrito. No Azure, as coisas simplesmente encaixam.
O Portal É Realmente Utilizável
A consola da AWS é um labirinto. Uso-a há anos e ainda assim por vezes não encontro o que procuro. O portal do Azure não é perfeito, mas tem um modelo mental coerente. Os recursos pertencem a grupos de recursos. Os grupos de recursos vivem em subscrições. As subscrições pertencem a um tenant. Essa hierarquia faz sentido e torna a gestão de acessos, faturação e limpeza muito mais simples.
As ferramentas de gestão de custos do Azure também são genuinamente boas. Podes etiquetar recursos, definir orçamentos com alertas e obter uma divisão por serviço que é realmente legível. Já apanhei surpresas na faturação cedo graças a isso.
O Entra ID Muda a Forma Como Pensas na Autenticação
Antes de começar a usar o Azure a sério, a autenticação era sempre um mini projeto. Configurar uma biblioteca, gerir segredos, ligar tokens de atualização. No Azure, uma vez dentro do ecossistema, o Entra ID (anteriormente Azure AD) trata de tanto disso que quase te esqueces que existe.
As managed identities são o melhor exemplo. O meu App Service consegue falar com uma base de dados, uma conta de armazenamento ou um Key Vault sem uma única connection string na configuração. O serviço autentica-se a si próprio. Não há nada para rodar, nada para acidentalmente fazer commit para o controlo de versões. É uma daquelas coisas que parece uma conveniência menor até teres uma fuga de credenciais e perceberes quanta superfície de ataque tinhas.
O Ecossistema Cobre a Maior Parte do Que Preciso
Num projeto típico vou usar: alojamento (App Service ou Container Apps), uma base de dados (Azure SQL ou Cosmos DB), blob storage, uma CDN, um key vault, talvez um service bus. No Azure, todos esses são serviços de primeira parte com autenticação consistente, RBAC consistente e ferramentas consistentes através do Azure CLI e Bicep.
Não estou a colar serviços de cinco fornecedores diferentes. Tudo está num só lugar, faturado num só lugar, monitorizado num só lugar. Pode parecer aborrecido, mas infraestrutura aborrecida é boa infraestrutura.
O Azure DevOps Ainda É o Melhor CI/CD que Usei
Sei que este ponto é controverso. As pessoas adoram o GitHub Actions, e é razoável. Mas o Azure DevOps Pipelines dá-te mais controlo sobre ambientes, aprovações e gates de deployment do que qualquer outra coisa que experimentei. Para qualquer coisa além de uma aplicação web simples — com múltiplos ambientes, release trains ou requisitos de conformidade — o Azure DevOps é difícil de superar.
A integração com recursos Azure é sólida. Fazer deploy para App Service a partir de uma pipeline são algumas linhas de YAML e uma service connection. O audit trail vem incluído. Os fluxos de aprovação vêm incluídos. Não tens de construir isso tudo à mão.
Escala Sem Reescrever Tudo
Começar pequeno no Azure não te prende. Um App Service plan pode escalar vertical ou horizontalmente. Se o ultrapassares, moves-te para Container Apps ou AKS sem alterar o código da aplicação. O modelo de rede, o modelo de identidade e a camada de armazenamento mantêm-se. Não começas do zero quando os requisitos mudam.
Já vi equipas migrar de App Service para AKS numa semana porque já usavam recursos Azure ao longo de tudo. A mesma migração noutra cloud teria sido muito mais trabalhosa.
Não É Perfeito
O Azure tem arestas. Alguns serviços têm nomes confusos. A documentação pode ser inconsistente entre experiências antigas e novas do portal. Os preços em alguns serviços, em particular o egress de rede, são genuinamente irritantes.
E se a tua equipa vive no mundo AWS, mudar tem um custo real de aprendizagem. Ferramentas, modelos mentais e configurações IAM existentes não se transferem facilmente. A melhor cloud é muitas vezes aquela que a tua equipa já conhece.
Mas para um programador .NET a construir software de produção, o Azure é onde o ecossistema, as ferramentas e os padrões se alinham melhor. É por isso que continuo a voltar.
