Olá pessoALL, eu preciso confessar uma coisa: sou fã do Azure App Service. Fã de carteirinha. Daqueles que acompanham desde a época em que o serviço nem se chamava App Service, era Azure Websites, lá em 2013, 2014. E ao longo desses anos todos, vi muita gente questionar essa escolha. "Por que não usar VM?" "Por que não ir direto pra containers?" "Será que PaaS dá conta de algo sério?"

Pois bem. Na última semana, o time do App Service na Microsoft publicou um artigo chamado Continued Investment in Azure App Service, deixando claro que o serviço continua em desenvolvimento ativo. E quando li aquilo, pensei: esse é o momento certo pra compartilhar meu ponto de vista de quem usa esse serviço desde o dia um.

Não é um resumo do artigo deles. É a minha perspectiva como alguém que já colocou (e continua colocando) aplicações críticas em produção no App Service. Vamos lá?

De Azure Websites a App Service — uma jornada que eu vivi

Antes de falar do presente, preciso voltar no tempo. Você que trabalha com .NET há alguns anos sabe do que estou falando.

Hospedar uma aplicação web no Azure em 2013 significava, na maioria dos casos, provisionar uma Virtual Machine, instalar o IIS, configurar bindings, renovar certificado SSL manualmente, criar scripts de deploy via FTP ou Web Deploy, e rezar pra ninguém mexer na configuração da máquina entre um deploy e outro.

Sim. Eu também. Já fiz tudo isso. Já perdi noite atualizando certificado SSL que expirou porque ninguém lembrou. Já debuguei problemas de IIS que só aconteciam em produção porque o Application Pool reciclava num horário inconveniente. Já fiz deploy por FTP — e não me orgulho disso.

Quando o Azure Websites apareceu, a proposta era simples: você sobe seu código, a plataforma cuida do resto. Sem IIS pra configurar. Sem Windows Update pra gerenciar. Sem patching manual.

A proposta era boa. Mas a execução inicial era limitada. Os planos eram básicos, o suporte a frameworks era restrito, e a customização era mínima. Muita gente olhava e pensava: "legal pra um projeto de teste, mas pra produção eu preciso de uma VM."

Você já ouviu essa frase? Eu já ouvi dezenas de vezes.

E sabe o que aconteceu? O serviço evoluiu. De Azure Websites virou Web Apps, depois virou App Service com um ecossistema completo — Web Apps, API Apps, Mobile Apps, Logic Apps. Deployment slots surgiram. Auto-scale ficou maduro. VNet Integration deixou de ser um sonho. Custom domains com certificados gerenciados gratuitamente. Diagnósticos avançados no portal.

A cada ano, uma nova razão pra NÃO voltar pra VM.

O que o App Service resolve (e por que empresas SaaS deveriam se importar)

Se você constrói SaaS e hospeda no Azure, o App Service não é apenas uma opção. Na minha opinião, é a opção mais estratégica pra maioria dos cenários .NET.

Por quê? Porque SaaS exige previsibilidade operacional. Você não pode ter seu time parando o desenvolvimento de features pra ficar gerenciando infraestrutura. Cada hora que um desenvolvedor gasta configurando VM, atualizando OS ou troubleshootando problemas de rede é uma hora que ele não está entregando valor pro produto.

O App Service resolve isso:

• Com Deployment Slots, você faz deploy em staging, valida, e faz swap pra produção com zero downtime. Quantas empresas SaaS perdem clientes porque o deploy derruba o sistema por 2 minutos? Com slots, isso não existe.
• O Auto-scale escala horizontalmente baseado em métricas (CPU, memória, HTTP queue length). Seu SaaS vendeu mais que o esperado? A plataforma acompanha.
• Certificados TLS gerenciados eliminam renovação manual e expiração surpresa. Pra quem gerencia dezenas de custom domains num SaaS multi-tenant, isso é libertador.
• Diagnósticos integrados com Application Insights, Log Stream, Kudu console. Tudo acessível sem SSH, sem RDP, sem acesso direto ao servidor.
• Com VNet Integration, você conecta seu App Service a recursos privados (bancos de dados, APIs internas) sem expor nada na internet pública.

Muita gente acha que App Service é só pra projetos simples. Mas as empresas SaaS mais sérias que conheço, empresas que faturam milhões por ano, rodam suas aplicações web e APIs no App Service. Não porque é fácil. Porque é confiável, previsível, e libera o time pra focar no que realmente importa: o produto.

Ser PaaS era visto como limitação. "Eu não tenho acesso ao servidor", "não consigo instalar aquela DLL". Mas hoje, essa "limitação" é exatamente o que libera os times de operações que não entregam valor. Você não quer acesso ao servidor. Você quer que sua aplicação rode, escale, e se recupere sozinha.

Os investimentos recentes e por que eles importam

Agora que já defendi meu ponto, vamos ao que motivou esse artigo. O time do App Service publicou um panorama dos investimentos recentes, e cada item reforça uma direção clara: a plataforma está em desenvolvimento ativo, e a Microsoft está dobrando a aposta.

Vou destacar os pontos que mais me chamaram atenção, com minha análise de quem acompanha isso no dia a dia com clientes.

Premium v4 (Pv4)

O Premium v4 traz hardware mais moderno, mais opções de CPU e memória, e melhor relação custo-benefício. Pra quem hoje está no Pv3, o upgrade é direto e traz ganhos reais de performance sem mudar uma linha de código.

Na prática, isso significa que workloads que antes precisavam de planos maiores (ou até VMs) agora cabem confortavelmente num Pv4 com custo menor. Você está rodando aplicações .NET de alta demanda? APIs que recebem milhares de requests por segundo? O Pv4 é feito pra você.

App Service Managed Instance

Esse aqui me surpreendeu positivamente. O App Service Managed Instance é a resposta pra aquele cenário que todo consultor conhece: o cliente tem uma aplicação Windows legada que precisa de controle mais profundo do ambiente — isolamento de plano, networking privado, customização de OS, mas não quer (e não deveria) gerenciar VMs.

E quando achávamos que o App Service tinha atingido seu teto de flexibilidade... MAS (aqui entra um GRANDE MAS) — o Managed Instance expande o alcance do App Service pra cenários que antes só eram viáveis com VM ou Service Fabric. Ele mantém o modelo gerenciado (patching, scaling, identidade, diagnósticos) enquanto dá o controle que aplicações legadas precisam.

Quantas migrações pra nuvem que você já viu travaram porque a aplicação "precisava de uma VM"? Agora existe um caminho intermediário que não exige reescrever a aplicação.

Aspire no App Service — GA

A gente espera isso há tempos. O Aspire no Azure App Service atingiu General Availability, e isso faz diferença pra quem constrói aplicações distribuídas em .NET.

Com o Aspire, você define a orquestração dos seus serviços via código (AppHost model), e faz deploy diretamente pro App Service. Nada de YAML infinito. Nada de pipeline complexo pra orquestrar 5 microserviços. Código C# definindo a topologia, e a plataforma executa.

Pra empresas SaaS que estão quebrando seu monolito em serviços (e eu falo com muitas que estão nesse momento), isso reduz drasticamente a fricção entre desenvolver localmente e rodar em produção.

Runtime, Reliability e Deployment

Além dos grandes lançamentos, o artigo reforça investimentos em três áreas que parecem "chatas" mas são fundamentais:

• Suporte a runtimes atualizados: .NET, Node.js, Python, Java, PHP, sempre na versão mais recente. Você não precisa esperar meses pra adotar o .NET 10 no App Service.
• Availability Zones expandidas, com mais opções de resiliência e configuração simples. Pra SaaS com SLA agressivo, isso é obrigatório.
• Melhorias no workflow de deploy com GitHub Actions e Azure DevOps, menos fricção do build à produção.

Não são headlines. Mas são exatamente o tipo de investimento que faz você confiar na plataforma a longo prazo. Uma plataforma que mantém os runtimes atualizados e melhora a confiabilidade continuamente é uma plataforma que respeita quem constrói em cima dela.

AI Workloads no App Service

O artigo também menciona que cada vez mais clientes estão rodando aplicações com AI no App Service. Não me surpreende.

Pensa comigo: se você tem uma API .NET que chama o Azure OpenAI, ou um front-end que integra com Semantic Kernel, onde você vai hospedar isso? Subir um AKS só pra isso? O App Service já tem Managed Identity, VNet Integration, auto-scale. É a escolha óbvia pra quem quer adicionar AI sem complicar a operação.

A plataforma que cresce com você, inclusive quando "crescer" significa adicionar inteligência artificial.

Quando o App Service não é a resposta

Você sabe que eu prezo por honestidade nos meus artigos. Então me diz: o App Service resolve tudo? Não. E tudo bem. Reconhecer os limites de uma ferramenta é tão importante quanto conhecer seus pontos fortes.

Quando o App Service não é o melhor caminho:

• Se você precisa de dezenas de microserviços com service mesh, auto-discovery, e rolling updates granulares, o AKS (Azure Kubernetes Service) é a ferramenta certa. O App Service roda containers, sim, mas não foi feito pra ser um orquestrador.
• Workloads puramente event-driven (filas, triggers de storage, timers) ficam melhor no Azure Functions. Menor custo, modelo de execução mais enxuto.
• O App Service é fundamentalmente HTTP/HTTPS. Precisa de TCP puro ou gRPC server-side streaming? Considere Container Apps ou AKS.
• Se cada milissegundo importa e você precisa de controle total sobre runtime, garbage collection, e afinidade de CPU, uma VM dedicada com tuning manual ainda pode fazer sentido.

Mas vamos ser honestos: pra 80% dos cenários de aplicações web e APIs em .NET, o App Service é a melhor escolha. Não falo isso por fanatismo. Falo por experiência acumulada ao longo de mais de uma década ajudando empresas a hospedar aplicações no Azure.

Por que eu continuo apostando no App Service

Se você chegou até aqui, obrigado pela paciência. Vou fechar com o que realmente importa.

Desenvolvedores se importam com a trajetória de longo prazo das plataformas em que constroem. Previsibilidade, transparência, e investimento contínuo constroem confiança. Essa frase não é minha — é do próprio artigo do time do App Service. E eu assino embaixo.

Quando olho pra trás, dos tempos de Azure Websites com FTP deploy até o App Service de hoje com Pv4, Managed Instance, e Aspire GA, o que vejo é uma plataforma que cresceu junto com quem usa. Que ouviu feedback. Que evoluiu sem quebrar o que já funcionava.

Pra quem constrói SaaS no Azure, isso é tudo. Você precisa de uma plataforma que:

1. Escale quando seus clientes crescem
2. Mantenha-se atualizada com os runtimes que você usa
3. Reduza a carga operacional do seu time
4. Evolua sem exigir que você rearquitete sua aplicação
5. Dê previsibilidade de custo e comportamento

O App Service entrega os cinco pontos. Não é perfeito — nenhum serviço é. Mas é a plataforma que mais evoluiu ao longo do tempo no Azure, na minha experiência. E os investimentos recentes mostram que a Microsoft concorda que vale a pena continuar investindo nela.

Lembro daqueles dias configurando IIS em VMs, renovando certificados manualmente, fazendo deploy por FTP. Hoje, faço deploy com git push, escalo com um slider, e durmo tranquilo sabendo que a plataforma cuida do patching e da disponibilidade.

Não volto atrás. E recomendo o mesmo pra você.

Links Úteis

Artigo Original e Blog do Time do App Service

• Continued Investment in Azure App Service — Artigo do time do App Service sobre os investimentos recentes na plataforma
• App Service Team Blog — Versão original no blog da equipe

Aspire no App Service

• Aspire on Azure App Service — GA — Anúncio de General Availability do Aspire no App Service

Documentação e Referência

• Documentação do Azure App Service — Guias, tutoriais e referência completa da plataforma
• Criar seu primeiro web app — Deploy em minutos usando portal, CLI ou VS Code
• Preços e planos do App Service — Comparação de tiers incluindo Premium v4
• Arquiteturas de referência no Azure Architecture Center — Boas práticas e arquiteturas de referência para produção

Deixe nos comentários: qual é o serviço do Azure que você mais usa e que mais evoluiu ao longo do tempo? Eu fiz minha escolha. Quero ouvir a sua.

[]s e até a próxima