Cloud-Native | The .NET Blog

Hooks de azd en Python, TypeScript y .NET: adiós a los scripts de shell

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

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

Si alguna vez has tenido un proyecto completamente en .NET y aun así tuviste que escribir scripts Bash solo para los hooks de azd, conoces bien ese dolor. ¿Por qué cambiar a sintaxis de shell en un paso de pre-provisioning cuando todo lo demás en el proyecto es C#?

Esa frustración tiene solución oficial. La Azure Developer CLI acaba de lanzar soporte multi-lenguaje para hooks, y es exactamente tan bueno como suena.

Hooks, brevemente, por si no los conoces

Los hooks son scripts que se ejecutan en puntos clave del ciclo de vida de azd — antes del provisioning, después del despliegue, y más. Se definen en azure.yaml y permiten inyectar lógica personalizada sin modificar la CLI.

Antes solo se admitían Bash y PowerShell. Ahora puedes usar Python, JavaScript, TypeScript o .NET — y azd se encarga del resto automáticamente.

Cómo funciona la detección

Simplemente apuntas el hook a un archivo y azd infiere el lenguaje por la extensión:

hooks:
 preprovision:
 run: ./hooks/setup.py
 postdeploy:
 run: ./hooks/seed.ts
 postprovision:
 run: ./hooks/migrate.cs

Eso es todo. Sin config adicional. Si la extensión es ambigua, puedes añadir kind: python (o el que corresponda) para especificarlo explícitamente.

Detalles importantes por lenguaje

Python

Coloca un requirements.txt o pyproject.toml junto al script (o en cualquier directorio padre) y azd crea un entorno virtual, instala dependencias y ejecuta el script:

hooks/
├── setup.py
└── requirements.txt

Sin gestión manual de virtualenv. azd busca hacia arriba desde el script el archivo de proyecto más cercano.

JavaScript y TypeScript

El mismo patrón — pon un package.json cerca del script y azd ejecutará npm install primero. Para TypeScript, usa npx tsx sin paso de compilación ni tsconfig.json:

hooks/
├── seed.ts
└── package.json

¿Quieres usar pnpm o yarn? Hay una opción config.packageManager para eso.

.NET

Dos modos disponibles:

Modo proyecto: Si hay un .csproj junto al script, azd ejecuta dotnet restore y dotnet build automáticamente.
Modo single-file: En .NET 10+, puedes poner un archivo .cs independiente y se ejecuta directamente con dotnet run script.cs. Sin archivo de proyecto.

hooks:
 postprovision:
 run: ./hooks/migrate.cs

Si ya estás en .NET 10, el modo single-file es la opción más limpia para scripts simples de migración o seeding. Sin scaffolding, sin .csproj que mantener.

Config por ejecutor

Cada lenguaje soporta un bloque config opcional para ajustar los valores por defecto:

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postdeploy:
 run: ./hooks/seed.py
 config:
 virtualEnvName: .venv
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

También puedes mezclar formatos en el mismo bloque hooks: — distintos lenguajes para distintos eventos del ciclo de vida, overrides por plataforma para Windows vs. Linux, lo que necesites.

Por qué importa para desarrolladores .NET

La respuesta aburrida es “consistencia”. Pero en la práctica va más allá. Los hooks eran el último lugar de un proyecto basado en azd que te obligaba a usar otro lenguaje. Ahora todo el pipeline de despliegue — código de app, scripts de infraestructura y hooks del ciclo de vida — puede vivir en un solo lenguaje.

Más concreto: puedes reutilizar tus utilidades .NET existentes en los hooks. ¿Tienes una librería compartida para gestión de esquemas de base de datos? Simplemente referencíala en el proyecto del hook. ¿Tienes un script Python de seeding que ya escribiste? Ponlo directamente en azure.yaml.

Conclusión

Es uno de esos cambios que parecen pequeños pero que eliminan mucha fricción del día a día con azd. El soporte multi-lenguaje para hooks ya está disponible — revisa el post oficial para la documentación completa y el repositorio de azd en GitHub para probarlo en tu próximo proyecto.

Global Azure Spain 2026

Sat, 18 Apr 2026 00:00:00 +0000

Global Azure Spain 2026 se celebra el 18 de abril de 2026 en Kinépolis Diversia en Alcobendas, Madrid. Es el mayor evento de la comunidad Azure en España, reuniendo a 38 ponentes en 3 tracks paralelos que cubren agentes de IA, networking en Azure, Cosmos DB, Fabric, IoT, seguridad y mucho más.

El evento transcurre de 08:30 a 18:30 e incluye keynote, pausas para café, almuerzo y una sesión de cierre con preguntas.

Puntos destacados de la agenda

Domando Agentes de IA: gobernanza, herramientas y APIs con Azure AI Foundry y Azure API Management
Construyendo agentes con LibreChat en Azure
How Can I Steal Your Data with Azure Private Endpoints
Stop Building APIs. Forge Agents with Azure
Agentic DevOps Meets IoT: Real-Time Systems with Fabric and GitHub Copilot
El regreso de los tamagotchis!: sistemas multi-agente en acción
Foundry Control Plane como plataforma de Agentes global
Rompiendo el perímetro: Zero Trust aplicado en Azure

Entradas

La inscripción es una donación simbólica — el precio completo de la entrada se destina directamente a Plan International, apoyando los derechos de los niños y la igualdad en todo el mundo. Aforo limitado, así que reserva tu plaza pronto.

Azure Tour 2026

Además de Madrid, el Global Azure Tour 2026 también incluye paradas en Zaragoza, Tenerife y Sevilla.

¿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.

Aspire 13.2 incorpora MongoDB EF Core y Azure Data Lake — Dos integraciones que vale la pena probar

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

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

Aspire 13.2 acaba de llegar con dos nuevas integraciones de bases de datos que merecen tu atención: MongoDB Entity Framework Core y Azure Data Lake Storage. Si querías usar EF Core con MongoDB en una app de Aspire, o necesitabas conectar cargas de trabajo de data lake con service discovery, esta versión trae ambas cosas.

MongoDB se encuentra con EF Core en Aspire

Esta es la que más me entusiasma. Aspire ha soportado MongoDB desde hace tiempo, pero siempre fue con el driver directo — sin EF Core, sin DbContext, sin consultas LINQ contra tus documentos. Ahora tienes la experiencia completa de EF Core con MongoDB, además de los health checks automáticos y el service discovery de Aspire.

Configurarlo sigue el patrón típico de Aspire. En tu AppHost:

var mongodb = builder.AddMongoDB("mongodb")
 .WithDataVolume()
 .WithLifetime(ContainerLifetime.Persistent);

var apiService = builder.AddProject<Projects.ApiService>("api")
 .WithReference(mongodb);

Luego en tu proyecto consumidor, añade la integración de EF Core:

dotnet add package Aspire.MongoDB.EntityFrameworkCore

Y registra tu DbContext:

builder.AddMongoDbContext<MyDbContext>("mongodb", "mydb");

A partir de ahí, es EF Core estándar. Define tus entidades, usa tu DbContext como lo harías con cualquier otro proveedor. La integración se encarga del connection pooling, trazas de OpenTelemetry y health checks en segundo plano.

Para desarrolladores .NET que han estado usando MongoDB con el driver directo y configurando connection strings manualmente, esto es una mejora de calidad de vida muy bienvenida. Obtienes la abstracción completa de EF Core sin perder el service discovery de Aspire.

Azure Data Lake Storage se une a la fiesta

La segunda gran adición es una integración de Azure Data Lake Storage (ADLS). Si estás construyendo pipelines de datos, procesos ETL o plataformas de analítica, ahora puedes conectar recursos de Data Lake de la misma forma que conectarías cualquier otra dependencia de Aspire.

En el AppHost:

var storage = builder.AddAzureStorage("azure-storage");
var dataLake = storage.AddDataLake("data-lake");
var fileSystem = storage.AddDataLakeFileSystem("data-lake-file-system");

var analyticsService = builder.AddProject<Projects.AnalyticsService>("analytics")
 .WithReference(dataLake)
 .WithReference(fileSystem);

En el proyecto consumidor:

builder.AddAzureDataLakeServiceClient("data-lake");
builder.AddAzureDataLakeFileSystemClient("data-lake-file-system");

Sin gestión manual de connection strings, sin buscar credenciales. Aspire aprovisiona los recursos y los inyecta. Para los que construimos apps .NET cloud-native que tocan tanto datos operacionales como cargas de trabajo analíticas, esto hace que el data lake se sienta como un ciudadano de primera clase en el modelo de Aspire.

Las pequeñas correcciones que importan

Más allá de las funcionalidades principales, hay algunas mejoras de calidad de vida que vale la pena mencionar:

Corrección del connection string de MongoDB — la barra diagonal antes del nombre de la base de datos ahora se maneja correctamente. Si habías implementado un workaround, ya puedes eliminarlo
Exports de SQL Server — Aspire.Hosting.SqlServer ahora exporta opciones de configuración adicionales del servidor para un control más granular
Actualizaciones de emuladores — emulador de ServiceBus 2.0.0, emulador de App Configuration 1.0.2, y el emulador preview de CosmosDB ahora incluye una verificación de disponibilidad
Azure Managed Redis — ahora usa rediss:// (Redis Secure) por defecto, así que las conexiones están cifradas desde el inicio

Esa última es sutil pero importante — Redis cifrado por defecto significa una cosa menos que configurar en producción.

Para cerrar

Aspire 13.2 es una versión incremental, pero las integraciones de MongoDB EF Core y Data Lake llenan vacíos reales. Si estabas esperando soporte adecuado de EF Core con MongoDB en Aspire, o necesitabas que Data Lake fuera una dependencia de primera clase, actualiza a 13.2 y pruébalas. El comando aspire add genera todo lo que necesitas.

Lee las notas de la versión completas para más detalles, y consulta la galería de integraciones para la lista completa.

Azure Smart Tier ya está en GA — Optimización automática de costes en Blob Storage sin reglas de ciclo de vida

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 alguna vez dedicaste tiempo a ajustar las políticas de ciclo de vida de Azure Blob Storage y luego las viste desmoronarse cuando cambiaron los patrones de acceso, esto te interesa. Microsoft acaba de anunciar la disponibilidad general de smart tier para Azure Blob y Data Lake Storage — una capacidad de tiering completamente administrada que mueve automáticamente los objetos entre los niveles hot, cool y cold según el uso real.

Qué hace realmente smart tier

El concepto es sencillo: smart tier evalúa continuamente el último tiempo de acceso de cada objeto en tu cuenta de almacenamiento. Los datos accedidos frecuentemente se quedan en hot, los datos inactivos pasan a cool después de 30 días, y luego a cold tras otros 60 días. Cuando se accede de nuevo a los datos, se promueven de vuelta a hot inmediatamente. El ciclo se reinicia.

Sin reglas de ciclo de vida que configurar. Sin predicciones de patrones de acceso. Sin ajustes manuales.

Durante la preview, Microsoft reportó que más del 50% de la capacidad gestionada por smart tier se movió automáticamente a niveles más fríos según los patrones reales de acceso. Es una reducción de costes significativa para cuentas de almacenamiento grandes.

Por qué esto importa para los desarrolladores .NET

Si estás construyendo aplicaciones que generan logs, telemetría, datos analíticos, o cualquier tipo de patrimonio de datos creciente — y seamos honestos, ¿quién no? — los costes de almacenamiento se acumulan rápido. El enfoque tradicional era escribir políticas de gestión de ciclo de vida, probarlas, y luego reajustarlas cuando los patrones de acceso de tu aplicación cambiaban. Smart tier elimina todo ese flujo de trabajo.

Algunos escenarios prácticos donde esto ayuda:

Telemetría y logs de aplicaciones — hot cuando estás depurando, rara vez accedidos después de unas semanas
Pipelines de datos y salidas de ETL — accedidos intensamente durante el procesamiento, luego mayormente cold
Contenido generado por usuarios — las subidas recientes están en hot, el contenido más antiguo se enfría gradualmente
Datos de backup y archivo — accedidos ocasionalmente por cumplimiento, mayormente inactivos

Cómo configurarlo

Habilitar smart tier es una configuración de una sola vez:

Cuentas nuevas: Selecciona smart tier como el nivel de acceso predeterminado durante la creación de la cuenta de almacenamiento (se requiere redundancia zonal)
Cuentas existentes: Cambia el nivel de acceso de blob de tu configuración actual a smart tier

Los objetos menores de 128 KiB se quedan en hot y no incurren en la tarifa de monitoreo. Para todo lo demás, pagas las tarifas estándar de capacidad hot/cool/cold sin cargos por transición de nivel, sin penalizaciones por eliminación temprana, y sin costes de recuperación de datos. Una tarifa mensual de monitoreo por objeto cubre la orquestación.

El compromiso que debes conocer

Las reglas de tiering de smart tier son estáticas (30 días → cool, 90 días → cold). Si necesitas umbrales personalizados — digamos, mover a cool después de 7 días para una carga de trabajo específica — las reglas de ciclo de vida siguen siendo el camino a seguir. Y no mezcles ambos: evita usar reglas de ciclo de vida sobre objetos gestionados por smart tier, ya que pueden entrar en conflicto.

Conclusión

Esto no es revolucionario, pero resuelve un dolor de cabeza operacional real. Si gestionas cuentas de blob storage en crecimiento y estás cansado de mantener políticas de ciclo de vida, habilita smart tier y deja que Azure se encargue. Está disponible hoy en casi todas las regiones zonales de la nube pública.

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.