Aks | The .NET Blog

Aspire 13.3: Soporte de Kubernetes, Registros del Navegador y la Habilidad Aspireify

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

Cinco semanas no es mucho tiempo para una versión, pero Aspire 13.3 no lo parece. Los elementos principales son significativos: despliegue de Kubernetes y AKS de primera clase con Helm, una habilidad de incorporación asistida por agente llamada Aspireify, captura de registros del navegador directamente en el dashboard y resultados de comandos estructurados. Además, 45 nuevas características, 134 mejoras y 93 correcciones de errores.

Vamos a los puntos destacados.

Aspireify: Incorporación Asistida por Agente

Agregar Aspire a un proyecto existente suena simple — coloca un AppHost, listo. En la práctica implica mucha arqueología: qué puertos importan, qué variables de entorno son dependencias reales, qué servicios de Docker Compose deben mapearse a integraciones de Aspire.

La nueva habilidad Aspireify le da a tu agente de código un flujo de trabajo guiado exactamente para esto. Cuando aspire init crea un AppHost esqueleto, la habilidad Aspireify ayuda al agente a inspeccionar el repositorio, entender cómo ya funciona y conectar el AppHost para adaptarse a la aplicación — no al revés.

La postura predeterminada es “minimizar los cambios en tu código.” Si tu aplicación ya lee DATABASE_URL, el agente lo mapea con WithEnvironment() en lugar de pedirte que reescribas tu configuración. Si un puerto está codificado de forma fija, la habilidad le indica al agente cuándo preservarlo.

Este es el tipo de herramientas de IA que realmente ahorran tiempo en lugar de generar más trabajo por revisar.

Despliegue de Kubernetes y AKS de Primera Clase

Esta es una que ha estado en la lista de deseos durante un tiempo. Aspire 13.3 incluye soporte de despliegue de Kubernetes y AKS de primera clase con Helm. Ahora puedes apuntar a AKS como destino de despliegue directamente desde las herramientas de Aspire.

Para los equipos que ya ejecutan cargas de trabajo de producción en AKS, esto cierra una brecha significativa. Tu modelo de aplicación de Aspire ahora tiene un camino limpio desde el desarrollo local hasta Kubernetes sin necesidad de escribir manualmente gráficos Helm.

Registros del Navegador en el Dashboard

Esta es una de esas características que parecen pequeñas hasta que estás depurando un problema de frontend.

La nueva API WithBrowserLogs() adjunta un recurso de navegador rastreado a cualquier recurso capaz de endpoints. Aspire lanza Chromium usando un pipe CDP privado y transmite registros de consola, solicitudes de red y errores directamente al flujo de registros del recurso:

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

El AppHost de TypeScript admite lo mismo:

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

Errores de consola, solicitudes de red fallidas, excepciones del lado del cliente — todo visible en el mismo dashboard donde ya estás observando trazas y métricas. Sin necesidad de cambiar de pestaña a las DevTools del navegador para las cosas básicas.

Resultados de Comandos Estructurados

Los comandos de recursos recibieron una mejora significativa. Hasta ahora, los comandos devolvían éxito/fracaso. Ahora devuelven resultados estructurados: texto, JSON o markdown que fluye a través del modelo, la interfaz del dashboard, la CLI y las herramientas MCP.

El dashboard une todo esto con un nuevo centro de notificaciones en el encabezado. Los resultados de los comandos aparecen como notificaciones con marca de tiempo con renderización de markdown y una acción “Ver respuesta”.

Esto hace que los comandos de recursos sean verdaderamente componibles. Una integración ahora puede exponer un comando que devuelve una salida significativa — como una URL de túnel — en lugar de simplemente cambiar el estado en algún lugar.

Conclusión

Aspire 13.3 vale la actualización aunque sea solo por el soporte de Kubernetes. Los registros del navegador y los resultados de comandos estructurados parecen el tipo de mejoras de calidad de vida que se acumulan rápidamente en el flujo de trabajo de desarrollo cotidiano.

Notas de versión completas: What’s New in Aspire 13.3

¿Dónde deberías alojar tus agentes de IA en Azure? Una guía práctica de decisión

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

Este post fue traducido automáticamente. Para la versión original, haz clic aquí.

Si estás construyendo agentes de IA con .NET ahora mismo, probablemente hayas notado algo: hay muchas formas de alojarlos en Azure. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — y todos suenan razonables hasta que realmente necesitas elegir uno. Microsoft acaba de publicar una guía completa sobre alojamiento de agentes IA en Azure que aclara esto, y quiero desglosarlo desde la perspectiva práctica de un desarrollador .NET.

Las seis opciones de un vistazo

Así es como yo resumiría el panorama:

Opción	Ideal para	Tú gestionas
Container Apps	Control total de contenedores sin complejidad K8s	Observabilidad, estado, ciclo de vida
AKS	Cumplimiento empresarial, multi-clúster, redes personalizadas	Todo (ese es el punto)
Azure Functions	Tareas de agentes cortas y dirigidas por eventos	Casi nada — serverless puro
App Service	Agentes HTTP simples, tráfico predecible	Despliegue, configuración de escalado
Foundry Agents	Agentes sin código vía portal/SDK	Casi nada
Foundry Hosted Agents	Agentes con framework personalizado e infra gestionada	Solo tu código de agente

Las primeras cuatro son computación de propósito general — puedes ejecutar agentes en ellas, pero no fueron diseñadas para eso. Las dos últimas son nativas de agentes: entienden conversaciones, llamadas a herramientas y ciclos de vida de agentes como conceptos de primera clase.

Foundry Hosted Agents — el punto ideal para desarrolladores .NET de agentes

Esto es lo que me llamó la atención. Foundry Hosted Agents se sitúan justo en el medio: obtienes la flexibilidad de ejecutar tu propio código (Semantic Kernel, Agent Framework, LangGraph — lo que sea) pero la plataforma gestiona infraestructura, observabilidad y gestión de conversaciones.

La pieza clave es el Hosting Adapter — una capa de abstracción fina que conecta tu framework de agentes con la plataforma Foundry. Para Microsoft Agent Framework, se ve así:

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()

Esa es toda tu historia de hosting. El adapter gestiona traducción de protocolos, streaming vía server-sent events, historial de conversación y trazado OpenTelemetry — todo automáticamente. Sin middleware personalizado, sin plomería manual.

Desplegar es genuinamente simple

He desplegado agentes en Container Apps antes y funciona, pero terminas escribiendo mucho código de pegamento para gestión de estado y observabilidad. Con Hosted Agents y azd, el despliegue es:

# Instalar la extensión de agente IA
azd ext install azure.ai.agents

# Inicializar desde una plantilla
azd ai agent init

# Construir, subir, desplegar — listo
azd up

Ese único azd up construye tu contenedor, lo sube a ACR, provisiona el proyecto Foundry, despliega endpoints de modelo e inicia tu agente. Cinco pasos colapsados en un solo comando.

Gestión de conversaciones integrada

Esta es la parte que ahorra más tiempo en producción. En lugar de construir tu propio almacén de estado de conversación, Hosted Agents lo gestionan nativamente:

# Crear una conversación persistente
conversation = openai_client.conversations.create()

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

# Segundo turno — el contexto se preserva
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

Sin Redis. Sin almacén de sesiones Cosmos DB. Sin middleware personalizado para serialización de mensajes. La plataforma simplemente lo gestiona.

Mi framework de decisión

Después de revisar las seis opciones, aquí está mi modelo mental rápido:

¿Necesitas cero infraestructura? → Foundry Agents (portal/SDK, sin contenedores)
¿Tienes código de agente personalizado pero quieres hosting gestionado? → Foundry Hosted Agents
¿Necesitas tareas de agente cortas dirigidas por eventos? → Azure Functions
¿Necesitas máximo control de contenedores sin K8s? → Container Apps
¿Necesitas cumplimiento estricto y multi-clúster? → AKS
¿Tienes un agente HTTP simple con tráfico predecible? → App Service

Para la mayoría de desarrolladores .NET que construyen con Semantic Kernel o Microsoft Agent Framework, Hosted Agents es probablemente el punto de partida correcto. Obtienes scale-to-zero, OpenTelemetry integrado, gestión de conversaciones y flexibilidad de framework — sin gestionar Kubernetes ni montar tu propia pila de observabilidad.

Para terminar

El panorama de alojamiento de agentes en Azure está madurando rápido. Si estás empezando un nuevo proyecto de agente IA hoy, consideraría seriamente Foundry Hosted Agents antes de recurrir a Container Apps o AKS por costumbre. La infraestructura gestionada ahorra tiempo real, y el patrón de hosting adapter te permite mantener tu elección de framework.

Echa un vistazo a la guía completa de Microsoft y al repositorio de ejemplos de Foundry para ejemplos funcionales.

KubeCon Europe 2026: Lo que los desarrolladores .NET deberían saber de verdad

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

Esta publicación fue traducida automáticamente. Para la versión original, haz clic aquí.

¿Conoces esa sensación cuando cae un post de anuncios enorme y estás scrolleando pensando “genial, pero qué cambia esto realmente para mí”? Eso me pasa cada temporada de KubeCon.

Microsoft acaba de publicar su resumen completo de KubeCon Europe 2026 — escrito por el mismísimo Brendan Burns — y sinceramente, hay sustancia real aquí. No solo checkboxes de features, sino mejoras operacionales que cambian cómo manejas las cosas en producción.

Te resumo lo que realmente importa para nosotros los desarrolladores .NET.

mTLS sin el impuesto del service mesh

Aquí va la cosa sobre los service meshes: todo el mundo quiere las garantías de seguridad, nadie quiere la carga operacional. AKS por fin está cerrando esa brecha.

Azure Kubernetes Application Network te da TLS mutuo, autorización basada en identidad de aplicación y telemetría de tráfico — sin desplegar un mesh pesado con sidecars. Combinado con Cilium mTLS en Advanced Container Networking Services, tienes comunicación encriptada pod-a-pod usando certificados X.509 y SPIRE para gestión de identidades.

¿Qué significa esto en la práctica? Tus APIs de ASP.NET Core hablando con workers en segundo plano, tus servicios gRPC llamándose entre sí — todo encriptado y verificado a nivel de red, sin cambios en el código de la aplicación. Eso es enorme.

Para equipos migrando desde ingress-nginx, también hay Application Routing con Meshless Istio con soporte completo de Kubernetes Gateway API. Sin sidecars. Basado en estándares. Y lanzaron herramientas ingress2gateway para migración incremental.

Observabilidad de GPU que no es un añadido secundario

Si estás ejecutando inferencia de IA junto a tus servicios .NET (y seamos honestos, ¿quién no está empezando a hacerlo?), probablemente has topado con el punto ciego del monitoreo de GPU. Tenías dashboards geniales de CPU/memoria y luego… nada para GPUs sin configuración manual de exportadores.

AKS ahora expone métricas de GPU nativamente en Prometheus y Grafana gestionados. Mismo stack, mismos dashboards, mismo pipeline de alertas. Sin exportadores custom, sin agentes de terceros.

En el lado de red, añadieron visibilidad por flujo para tráfico HTTP, gRPC y Kafka con una experiencia one-click en Azure Monitor. IPs, puertos, workloads, dirección de flujo, decisiones de políticas — todo en dashboards integrados.

Y aquí viene la que me hizo mirar dos veces: agentic container networking añade una UI web donde puedes hacer preguntas en lenguaje natural sobre el estado de red de tu cluster. “¿Por qué el pod X no llega al servicio Y?” → diagnósticos de solo lectura desde telemetría en vivo. Eso es genuinamente útil a las 2 AM.

Networking cross-cluster que no requiere un doctorado

Multi-cluster en Kubernetes históricamente ha sido una experiencia de “trae tu propio pegamento de red”. Azure Kubernetes Fleet Manager ahora incluye networking cross-cluster mediante Cilium cluster mesh gestionado:

Conectividad unificada entre clusters AKS
Registro global de servicios para descubrimiento cross-cluster
Configuración gestionada centralmente, no repetida por cluster

Si estás corriendo microservicios .NET en varias regiones por resiliencia o cumplimiento, esto reemplaza mucho pegamento custom frágil. El Servicio A en West Europe puede descubrir y llamar al Servicio B en East US a través del mesh, con políticas de routing y seguridad consistentes.

Upgrades que no requieren valentía

Seamos honestos — los upgrades de Kubernetes en producción son estresantes. “Actualizar y rezar” ha sido la estrategia de facto para demasiados equipos, y es la razón principal por la que los clusters se quedan atrás en versiones.

Dos nuevas capacidades cambian esto:

Blue-green agent pool upgrades crean un pool de nodos paralelo con la nueva configuración. Valida el comportamiento, mueve tráfico gradualmente y mantén un camino limpio de rollback. No más mutaciones in-place en nodos de producción.

Agent pool rollback te permite revertir un pool de nodos a su versión anterior de Kubernetes e imagen de nodo después de que un upgrade sale mal — sin reconstruir el cluster.

Juntos, finalmente dan a los operadores control real sobre el ciclo de vida de upgrades. Para equipos .NET, esto importa porque la velocidad de la plataforma controla directamente qué tan rápido puedes adoptar nuevos runtimes, parches de seguridad y capacidades de red.

Los workloads de IA se convierten en ciudadanos de primera clase de Kubernetes

El trabajo upstream en open-source es igualmente importante. Dynamic Resource Allocation (DRA) acaba de llegar a GA en Kubernetes 1.36, haciendo del scheduling de GPU una feature de primera clase en lugar de un workaround.

Algunos proyectos que vale la pena seguir:

Proyecto	Qué hace
AI Runway	API común de Kubernetes para inferencia — despliega modelos sin saber K8s, con descubrimiento en HuggingFace y estimaciones de costo
HolmesGPT	Troubleshooting agéntico para cloud-native — ahora proyecto CNCF Sandbox
Dalec	Builds declarativos de imágenes de contenedor con generación de SBOM — menos CVEs en la etapa de build

La dirección es clara: tu API .NET, tu capa de orquestación con Semantic Kernel y tus workloads de inferencia deberían correr todos en un modelo de plataforma consistente. Estamos llegando ahí.

Por dónde empezaría esta semana

Si estás evaluando estos cambios para tu equipo, esta es mi lista honesta de prioridades:

Observabilidad primero — habilita métricas de GPU y logs de flujo de red en un cluster no-prod. Mira lo que te has estado perdiendo.
Prueba blue-green upgrades — testea el workflow de rollback antes de tu próximo upgrade de cluster en producción. Construye confianza en el proceso.
Pilotea networking con identidad — elige un path de servicio interno y habilita mTLS con Cilium. Mide el overhead (spoiler: es mínimo).
Evalúa Fleet Manager — si corres más de dos clusters, el networking cross-cluster se paga solo en reducción de pegamento custom.

Experimentos pequeños, feedback rápido. Esa es siempre la jugada.

Para cerrar

Los anuncios de KubeCon pueden ser abrumadores, pero esta tanda genuinamente mueve la aguja para equipos .NET en AKS. Mejor seguridad de red sin overhead de mesh, observabilidad real de GPU, upgrades más seguros y bases más fuertes para infraestructura de IA.

Si ya estás en AKS, es un gran momento para ajustar tu baseline operacional. Y si estás planeando mover workloads .NET a Kubernetes — la plataforma acaba de ponerse significativamente más lista para producción.