Aks | The .NET Blog

Aspire 13.3: Suporte ao Kubernetes, Logs do Navegador e a Skill Aspireify

Emiliano Montesdeoca — Mon, 18 May 2026 00:00:00 +0000

Cinco semanas não é muito tempo para um lançamento, mas o Aspire 13.3 não parece assim. Os itens principais são significativos: implantação de Kubernetes e AKS de primeira classe com Helm, uma skill de integração assistida por agente chamada Aspireify, captura de logs do navegador diretamente no dashboard e resultados de comandos estruturados. Além disso, 45 novos recursos, 134 melhorias e 93 correções de bugs.

Vamos aos destaques.

Aspireify: Integração Assistida por Agente

Adicionar o Aspire a um projeto existente parece simples — coloque um AppHost, pronto. Na prática, envolve muita arqueologia: quais portas importam, quais variáveis de ambiente são dependências reais, quais serviços do Docker Compose devem ser mapeados para integrações do Aspire.

A nova skill Aspireify fornece ao seu agente de código um fluxo de trabalho guiado exatamente para isso. Quando aspire init cria um AppHost esqueleto, a skill Aspireify ajuda o agente a inspecionar o repositório, entender como já funciona e conectar o AppHost para se adaptar ao aplicativo — não o contrário.

A postura padrão é “minimizar alterações no seu código.” Se o seu aplicativo já lê DATABASE_URL, o agente mapeia isso com WithEnvironment() em vez de pedir que você reescreva sua configuração. Se uma porta está codificada de forma fixa, a skill indica ao agente quando preservá-la.

Este é o tipo de tooling de IA que realmente economiza tempo em vez de gerar mais trabalho para revisar.

Implantação de Kubernetes e AKS de Primeira Classe

Esta estava na lista de desejos há algum tempo. O Aspire 13.3 inclui suporte de implantação de Kubernetes e AKS de primeira classe com Helm. Agora você pode direcionar o AKS como destino de implantação diretamente das ferramentas do Aspire.

Para equipes que já executam cargas de trabalho de produção no AKS, isso fecha uma lacuna significativa. Seu modelo de aplicativo Aspire agora tem um caminho limpo do desenvolvimento local ao Kubernetes sem a necessidade de escrever manualmente charts Helm.

Logs do Navegador no Dashboard

Esta é uma daquelas funcionalidades que parecem pequenas até você estar depurando um problema de frontend.

A nova API WithBrowserLogs() anexa um recurso de navegador rastreado a qualquer recurso capaz de endpoints. O Aspire lança o Chromium usando um pipe CDP privado e transmite logs do console, solicitações de rede e erros diretamente no fluxo de logs do recurso:

var frontend = builder.AddViteApp("frontend", "../frontend")
 .WithHttpEndpoint(port: 3000)
 .WithBrowserLogs();

O AppHost TypeScript suporta o mesmo:

const frontend = await builder.addViteApp("frontend", "../frontend")
 .withHttpEndpoint({ port: 3000 })
 .withBrowserLogs();

Erros de console, solicitações de rede com falha, exceções do lado do cliente — tudo visível no mesmo dashboard onde você já está observando traces e métricas. Sem necessidade de trocar de aba para o DevTools do navegador para as coisas básicas.

Resultados de Comandos Estruturados

Os comandos de recursos receberam uma atualização significativa. Até agora, os comandos retornavam sucesso/falha. Agora eles retornam resultados estruturados: texto, JSON ou markdown que flui pelo modelo, pela interface do dashboard, pela CLI e pelas ferramentas MCP.

O dashboard une tudo isso com um novo centro de notificações no cabeçalho. Os resultados dos comandos aparecem como notificações com carimbo de data/hora com renderização de markdown e uma ação “Ver resposta”.

Isso torna os comandos de recursos verdadeiramente combináveis. Uma integração agora pode expor um comando que retorna uma saída significativa — como uma URL de túnel — em vez de simplesmente alterar o estado em algum lugar.

Conclusão

O Aspire 13.3 vale a atualização mesmo que seja apenas pelo suporte ao Kubernetes. Os logs do navegador e os resultados de comandos estruturados parecem o tipo de melhorias de qualidade de vida que se acumulam rapidamente em um fluxo de trabalho de desenvolvimento diário.

Notas de versão completas: What’s New in Aspire 13.3

Onde hospedar seus agentes de IA no Azure? Um guia prático de decisão

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Este post foi traduzido automaticamente. Para a versão original, clique aqui.

Se você está construindo agentes de IA com .NET agora, provavelmente notou algo: existem muitas formas de hospedá-los no Azure. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — e todos parecem razoáveis até você precisar escolher um. A Microsoft acabou de publicar um guia completo sobre hospedagem de agentes IA no Azure que esclarece isso, e eu quero detalhar tudo pela perspectiva prática de um desenvolvedor .NET.

As seis opções de relance

Aqui está como eu resumiria o cenário:

Opção	Melhor para	Você gerencia
Container Apps	Controle total de containers sem complexidade K8s	Observabilidade, estado, ciclo de vida
AKS	Compliance empresarial, multi-cluster, rede customizada	Tudo (esse é o ponto)
Azure Functions	Tarefas de agentes curtas e orientadas a eventos	Quase nada — serverless real
App Service	Agentes HTTP simples, tráfego previsível	Deploy, config de scaling
Foundry Agents	Agentes sem código via portal/SDK	Quase nada
Foundry Hosted Agents	Agentes com framework customizado e infra gerenciada	Apenas seu código de agente

As quatro primeiras são computação de propósito geral — você pode rodar agentes nelas, mas não foram projetadas para isso. As duas últimas são nativas de agentes: entendem conversas, chamadas de ferramentas e ciclos de vida de agentes como conceitos de primeira classe.

Foundry Hosted Agents — o ponto ideal para desenvolvedores .NET de agentes

Isso foi o que chamou minha atenção. Foundry Hosted Agents ficam bem no meio: você tem a flexibilidade de rodar seu próprio código (Semantic Kernel, Agent Framework, LangGraph — o que for) mas a plataforma cuida da infraestrutura, observabilidade e gerenciamento de conversas.

A peça-chave é o Hosting Adapter — uma camada de abstração fina que conecta seu framework de agentes à plataforma Foundry. Para o Microsoft Agent Framework, fica assim:

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

Essa é toda a sua história de hosting. O adapter cuida da tradução de protocolos, streaming via server-sent events, histórico de conversa e rastreamento OpenTelemetry — tudo automaticamente. Sem middleware customizado, sem encanamento manual.

Deploy é genuinamente simples

Já fiz deploy de agentes no Container Apps antes e funciona, mas você acaba escrevendo muito código de cola para gerenciamento de estado e observabilidade. Com Hosted Agents e azd, o deploy é:

# Instalar a extensão de agente IA
azd ext install azure.ai.agents

# Inicializar a partir de um template
azd ai agent init

# Construir, enviar, fazer deploy — pronto
azd up

Esse único azd up constrói seu container, envia para o ACR, provisiona o projeto Foundry, faz deploy dos endpoints de modelo e inicia seu agente. Cinco etapas condensadas em um único comando.

Gerenciamento de conversas integrado

Essa é a parte que economiza mais tempo em produção. Em vez de construir seu próprio store de estado de conversa, Hosted Agents lidam com isso nativamente:

# Criar uma conversa persistente
conversation = openai_client.conversations.create()

# Primeira rodada
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# Segunda rodada — contexto é preservado
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

Sem Redis. Sem store de sessões Cosmos DB. Sem middleware customizado para serialização de mensagens. A plataforma simplesmente cuida disso.

Meu framework de decisão

Depois de passar pelas seis opções, aqui está meu modelo mental rápido:

Precisa de zero infraestrutura? → Foundry Agents (portal/SDK, sem containers)
Tem código de agente customizado mas quer hosting gerenciado? → Foundry Hosted Agents
Precisa de tarefas de agentes curtas orientadas a eventos? → Azure Functions
Precisa de máximo controle de containers sem K8s? → Container Apps
Precisa de compliance rigorosa e multi-cluster? → AKS
Tem um agente HTTP simples com tráfego previsível? → App Service

Para a maioria dos desenvolvedores .NET construindo com Semantic Kernel ou Microsoft Agent Framework, Hosted Agents é provavelmente o ponto de partida certo. Você obtém scale-to-zero, OpenTelemetry integrado, gerenciamento de conversas e flexibilidade de framework — sem gerenciar Kubernetes ou montar sua própria stack de observabilidade.

Para finalizar

O cenário de hospedagem de agentes no Azure está amadurecendo rápido. Se você está começando um novo projeto de agente IA hoje, eu consideraria seriamente Foundry Hosted Agents antes de recorrer a Container Apps ou AKS por hábito. A infraestrutura gerenciada economiza tempo real, e o padrão hosting adapter permite manter sua escolha de framework.

Confira o guia completo da Microsoft e o repo Foundry Samples para exemplos funcionais.

KubeCon Europe 2026: O que os desenvolvedores .NET realmente precisam saber

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

Este post foi traduzido automaticamente. Para a versão original, clique aqui.

Sabe aquela sensação quando cai um post gigante de anúncios e você fica scrollando pensando “legal, mas o que isso muda pra mim na prática”? É assim que me sinto toda temporada de KubeCon.

A Microsoft acabou de publicar o resumo completo da KubeCon Europe 2026 — escrito pelo próprio Brendan Burns — e sinceramente? Tem conteúdo real aqui. Não são apenas checklists de features, mas melhorias operacionais que mudam como você gerencia as coisas em produção.

Deixa eu explicar o que realmente importa para nós desenvolvedores .NET.

mTLS sem o imposto do service mesh

A coisa com service meshes é: todo mundo quer as garantias de segurança, ninguém quer a carga operacional. O AKS finalmente está fechando essa lacuna.

Azure Kubernetes Application Network te dá TLS mútuo, autorização com reconhecimento de aplicação e telemetria de tráfego — sem implantar um mesh pesado com sidecars. Combinado com Cilium mTLS no Advanced Container Networking Services, você tem comunicação criptografada pod-a-pod usando certificados X.509 e SPIRE para gerenciamento de identidade.

Na prática: suas APIs ASP.NET Core conversando com workers em background, seus serviços gRPC chamando uns aos outros — tudo criptografado e verificado por identidade no nível de rede, sem nenhuma alteração no código. Isso é enorme.

Para times migrando do ingress-nginx, também tem Application Routing com Meshless Istio com suporte completo à Kubernetes Gateway API. Sem sidecars. Baseado em padrões. E lançaram ferramentas ingress2gateway para migração incremental.

Observabilidade de GPU que não é secundária

Se você está rodando inferência de IA junto com seus serviços .NET (e sejamos honestos, quem não está começando?), provavelmente já se deparou com o ponto cego do monitoramento de GPU. Tinha dashboards ótimos de CPU/memória e depois… nada para GPUs sem configuração manual de exportadores.

AKS agora expõe métricas de GPU nativamente no Prometheus e Grafana gerenciados. Mesmo stack, mesmos dashboards, mesmo pipeline de alertas. Sem exportadores custom, sem agentes de terceiros.

No lado de rede, adicionaram visibilidade por fluxo para tráfego HTTP, gRPC e Kafka com uma experiência one-click no Azure Monitor. IPs, portas, workloads, direção do fluxo, decisões de policy — tudo em dashboards integrados.

E aqui vem a que me fez olhar duas vezes: agentic container networking adiciona uma UI web onde você pode fazer perguntas em linguagem natural sobre o estado de rede do seu cluster. “Por que o pod X não alcança o serviço Y?” → diagnósticos read-only a partir de telemetria ao vivo. Genuinamente útil às 2 da manhã.

Networking cross-cluster que não exige doutorado

Multi-cluster em Kubernetes historicamente foi uma experiência de “traga sua própria cola de rede”. Azure Kubernetes Fleet Manager agora entrega networking cross-cluster através de Cilium cluster mesh gerenciado:

Conectividade unificada entre clusters AKS
Registro global de serviços para descoberta cross-cluster
Configuração gerenciada centralmente, não repetida por cluster

Se você roda microsserviços .NET em várias regiões para resiliência ou compliance, isso substitui muita cola custom frágil. O Serviço A no West Europe pode descobrir e chamar o Serviço B no East US através do mesh, com políticas de roteamento e segurança consistentes.

Upgrades que não exigem coragem

Sejamos honestos — upgrades de Kubernetes em produção são estressantes. “Atualizar e torcer” tem sido a estratégia de facto para muitos times, e é a razão principal pela qual clusters ficam defasados nas versões.

Duas novas capacidades mudam isso:

Blue-green agent pool upgrades criam um pool de nós paralelo com a nova configuração. Valide o comportamento, mova tráfego gradualmente e mantenha um caminho limpo de rollback. Nada mais de mutações in-place em nós de produção.

Agent pool rollback permite reverter um pool de nós para a versão anterior do Kubernetes e imagem de nó quando um upgrade dá errado — sem reconstruir o cluster.

Juntos, finalmente dão aos operadores controle real sobre o ciclo de vida de upgrades. Para times .NET, isso importa porque a velocidade da plataforma controla diretamente quão rápido você pode adotar novos runtimes, patches de segurança e capacidades de rede.

Workloads de IA se tornam cidadãos de primeira classe no Kubernetes

O trabalho upstream em open-source é igualmente importante. Dynamic Resource Allocation (DRA) acabou de chegar em GA no Kubernetes 1.36, tornando o scheduling de GPU uma feature de primeira classe ao invés de um workaround.

Alguns projetos que vale a pena acompanhar:

Projeto	O que faz
AI Runway	API Kubernetes comum para inferência — deploy de modelos sem saber K8s, com descoberta HuggingFace e estimativas de custo
HolmesGPT	Troubleshooting agêntico para cloud-native — agora projeto CNCF Sandbox
Dalec	Builds declarativos de imagens de container com geração de SBOM — menos CVEs na fase de build

A direção é clara: sua API .NET, sua camada de orquestração com Semantic Kernel e seus workloads de inferência deveriam todos rodar em um modelo de plataforma consistente. Estamos chegando lá.

Por onde eu começaria esta semana

Se você está avaliando essas mudanças para seu time, aqui vai minha lista honesta de prioridades:

Observabilidade primeiro — habilite métricas de GPU e logs de fluxo de rede em um cluster não-prod. Veja o que você andou perdendo.
Teste blue-green upgrades — experimente o workflow de rollback antes do seu próximo upgrade de cluster em produção. Construa confiança no processo.
Pilote networking com identidade — escolha um caminho de serviço interno e habilite mTLS com Cilium. Meça o overhead (spoiler: é mínimo).
Avalie Fleet Manager — se você roda mais de dois clusters, networking cross-cluster se paga sozinho em redução de cola custom.

Experimentos pequenos, feedback rápido. Essa é sempre a jogada.

Finalizando

Anúncios de KubeCon podem ser avassaladores, mas essa leva realmente move a agulha para times .NET no AKS. Melhor segurança de rede sem overhead de mesh, observabilidade real de GPU, upgrades mais seguros e fundações mais fortes para infraestrutura de IA.

Se você já está no AKS, é um ótimo momento para reforçar sua baseline operacional. E se está planejando mover workloads .NET para Kubernetes — a plataforma ficou significativamente mais pronta para produção.