Cloud-Native | The .NET Blog

Hooks d'azd en Python, TypeScript i .NET: adéu als scripts de shell

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

Aquesta publicació ha estat traduïda automàticament. Per a la versió original, feu clic aquí.

Si alguna vegada has tingut un projecte completament en .NET i tot i així has hagut d’escriure scripts Bash per als hooks d’azd, coneixes bé aquell dolor. Per què canviar a sintaxi de shell en un pas de pre-provisioning quan tota la resta del projecte és C#?

Aquesta frustració té ara solució oficial. L’Azure Developer CLI acaba de llançar suport multi-llenguatge per a hooks, i és exactament tan bo com sona.

Hooks, breument

Els hooks són scripts que s’executen en punts clau del cicle de vida d’azd — abans del provisioning, després del desplegament, i més. Es defineixen a azure.yaml i permeten injectar lògica personalitzada sense modificar la CLI.

Abans només s’admetien Bash i PowerShell. Ara pots usar Python, JavaScript, TypeScript o .NET — i azd s’encarrega de la resta automàticament.

Com funciona la detecció

Simplement apuntes el hook a un fitxer i azd infereix el llenguatge per l’extensió:

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

Sense configuració addicional. Si l’extensió és ambigua, pots afegir kind: python (o el que correspongui) per especificar-ho explícitament.

Detalls importants per llenguatge

Python

Col·loca un requirements.txt o pyproject.toml al costat del script (o en qualsevol directori pare) i azd crea un entorn virtual, instal·la dependències i executa l’script.

JavaScript i TypeScript

El mateix patró — posa un package.json a prop del script i azd executarà npm install primer. Per a TypeScript, usa npx tsx sense pas de compilació ni tsconfig.json.

.NET

Dos modes disponibles:

Mode projecte: Si hi ha un .csproj al costat del script, azd executa dotnet restore i dotnet build automàticament.
Mode single-file: En .NET 10+, pots posar un fitxer .cs independent i s’executa directament amb dotnet run script.cs. Sense fitxer de projecte.

Configuració per executor

Cada llenguatge admet un bloc config opcional:

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

Per què importa per a desenvolupadors .NET

Els hooks eren l’últim lloc d’un projecte basat en azd que t’obligava a usar un altre llenguatge. Ara tot el pipeline de desplegament pot viure en un sol llenguatge. Pots reutilitzar les teves utilitats .NET existents als hooks, referenciar llibreries compartides i evitar el manteniment de scripts de shell.

Conclusió

És un d’aquells canvis que semblen petits però que eliminen molta fricció del dia a dia amb azd. El suport multi-llenguatge per a hooks ja està disponible — consulta el post oficial per a la documentació completa.

Aspire 13.2 obté MongoDB EF Core i Azure Data Lake: dues integracions que val la pena provar

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

Aspire 13.2 acaba d’aterrar amb dues noves integracions de bases de dades que mereixen la vostra atenció: MongoDB Entity Framework Core i Azure Data Lake Storage. Si heu volgut utilitzar EF Core amb MongoDB en una aplicació Aspire o necessiteu connectar les càrregues de treball del llac de dades amb un descobriment de serveis adequat, aquesta versió ofereix tots dos.

MongoDB compleix EF Core a Aspire

Aquest és el que m’emociona més. Aspire ha donat suport a MongoDB durant un temps, però sempre va ser el controlador en brut: sense EF Core, sense DbContext, sense consultes LINQ als vostres documents. Ara teniu l’experiència completa d’EF Core amb MongoDB, a més de les comprovacions automàtiques de l’estat i el descobriment de serveis d’Aspire.

Configurar-lo és el patró típic d’Aspire. Al vostre AppHost:

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

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

A continuació, al vostre projecte de consum, afegiu la integració d’EF Core:

dotnet add package Aspire.MongoDB.EntityFrameworkCore

I registre el teu DbContext:

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

A partir d’aquí, és EF Core estàndard. Defineix les teves entitats, utilitza el teu DbContext com ho faries amb qualsevol altre proveïdor. La integració gestiona l’agrupació de connexions, les traces d’OpenTelemetry i les comprovacions de salut darrere de les escenes.

Per als desenvolupadors de.NET que han estat utilitzant MongoDB amb el controlador en brut i cablejat manualment les cadenes de connexió, aquesta és una bona actualització de qualitat de vida. Obteniu l’abstracció completa d’EF Core sense perdre el descobriment del servei d’Aspire.

Azure Data Lake Storage s’uneix a la festa

La segona gran incorporació és una integració d’Azure Data Lake Storage (ADLS). Si esteu creant canalitzacions de dades, processos ETL o plataformes d’anàlisi, ara podeu connectar els recursos de Data Lake de la mateixa manera que connectaríeu qualsevol altra dependència d’Aspire.

A l’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 projecte de consum:

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

Sense gestió manual de cadenes de connexió, sense recerca de credencials. Aspire proporciona recursos i els injecta. Per a aquells de nosaltres que creem aplicacions.NET natives del núvol que toquen tant dades operatives com càrregues de treball d’anàlisi, això fa que el llac de dades se senti com un ciutadà de primera classe en el model Aspire.

Les petites solucions que importen

Més enllà de les funcions dels titulars, hi ha algunes millores en la qualitat de vida que cal destacar:

Correcció de cadena de connexió MongoDB: la barra inclinada abans del nom de la base de dades ara es gestiona correctament. Si heu treballat amb això, podeu eliminar aquesta solució
Exporta SQL Server — Aspire.Hosting.SqlServer ara exporta opcions addicionals de configuració del servidor per a un control més detallat
Actualitzacions de l’emulador: l’emulador ServiceBus 2.0.0, l’emulador de configuració d’aplicacions 1.0.2 i l’emulador de vista prèvia de CosmosDB ara inclou una comprovació de la preparació
Azure Managed Redis: ara el valor predeterminat és rediss:// (Redis Secure), de manera que les connexions es xifren de manera immediata

Aquest últim és subtil però important: Redis xifrat per defecte significa una cosa menys per configurar en producció.

Tancant

Aspire 13.2 és una versió incremental, però les integracions MongoDB EF Core i Data Lake omplen buits reals. Si estàveu esperant el suport adequat d’EF Core amb MongoDB a Aspire, o necessiteu que Data Lake sigui una dependència de primera classe, actualitzeu a 13.2 i feu-los una volta. L’ordre aspire add inclou tot el que necessiteu.

Llegiu les notes completes de la versió per obtenir més detalls i consulteu la galeria d’integració per obtenir la llista completa.

Azure Smart Tier és GA: optimització automàtica de costos d'emmagatzematge de blob sense regles de cicle de vida

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

Si alguna vegada heu passat temps ajustant les polítiques de cicle de vida d’Azure Blob Storage i després heu vist com es van trencar quan els patrons d’accés canviaven, aquesta és la vostra. Microsoft acaba d’anunciar la disponibilitat general del nivell intel·ligent per a Azure Blob i Data Lake Storage: una capacitat de nivells totalment gestionada que mou automàticament objectes entre nivells calents, freds i freds en funció de l’ús real.

Què fa realment el nivell intel·ligent

El concepte és senzill: el nivell intel·ligent avalua contínuament el darrer temps d’accés de cada objecte al vostre compte d’emmagatzematge. Les dades a les quals s’accedeix amb freqüència es mantenen en calent, les dades inactives es mouen per refredar-se després de 30 dies i després a fred després de 60 dies més. Quan s’accedeix de nou a les dades, es torna a activar immediatament. El cicle es reinicia.

No hi ha regles de cicle de vida per configurar. No hi ha prediccions de patrons d’accés. Sense sintonització manual.

Durant la previsualització, Microsoft va informar que més del 50% de la capacitat gestionada per nivells intel·ligents es va canviar automàticament a nivells més freds en funció dels patrons d’accés reals. Això suposa una reducció de costos significativa per als comptes d’emmagatzematge grans.

Per què això és important per als desenvolupadors de.NET

Si esteu creant aplicacions que generen registres, telemetria, dades analítiques o qualsevol tipus de fons de dades en creixement, i sincerament, qui no, els costos d’emmagatzematge s’acumulen ràpidament. L’enfocament tradicional era escriure polítiques de gestió del cicle de vida, provar-les i tornar-les a ajustar quan canviaven els patrons d’accés de la vostra aplicació. El nivell intel·ligent elimina tot aquest flux de treball.

Alguns escenaris pràctics on això ajuda:

Telemetria i registres d’aplicacions: calent durant la depuració, rarament s’hi accedeix després d’unes setmanes
Conductes de dades i sortides d’ETL: s’hi accedeix molt durant el processament, després principalment en fred
Contingut generat per l’usuari: les càrregues recents són interessants, el contingut més antic es refreda gradualment
Còpia de seguretat i dades d’arxiu: s’accedeix de tant en tant per complir-ho, principalment inactiu

Configurant-lo

Habilitar el nivell intel·ligent és una configuració única:

Comptes nous: seleccioneu el nivell intel·ligent com a nivell d’accés predeterminat durant la creació del compte d’emmagatzematge (es requereix redundància zonal)
Comptes existents: canvieu el nivell d’accés a blob del nivell predeterminat actual al nivell intel·ligent

Els objectes de menys de 128 KiB es mantenen en calent i no incorren en la taxa de supervisió. Per a la resta, pagueu tarifes estàndard de capacitat calenta/fresca/fred sense càrrecs de transició de nivell, sense despeses d’eliminació anticipada i sense costos de recuperació de dades. Una quota de seguiment mensual per objecte cobreix l’orquestració.

La compensació a conèixer

Les regles de classificació del nivell intel·ligent són estàtiques (30 dies → fred, 90 dies → fred). Si necessiteu llindars personalitzats (per exemple, passar a la refrigeració després de 7 dies per a una càrrega de treball específica), les regles del cicle de vida encara són el camí a seguir. I no barregeu les dues coses: eviteu utilitzar regles de cicle de vida en objectes gestionats per nivell intel·ligent, ja que poden entrar en conflicte.

Tancant

Això no és revolucionari, però soluciona un autèntic mal de cap operatiu. Si gestioneu comptes d’emmagatzematge de blobs en creixement i esteu cansat de mantenir polítiques de cicle de vida, habilita el nivell intel·ligent i deixeu que Azure s’encarregui. Actualment està disponible a gairebé totes les regions de núvol públic de zona.

On hauríeu d'allotjar els vostres agents d'IA a Azure? Una guia pràctica de decisions

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

Si esteu creant agents d’IA amb.NET ara mateix, probablement heu notat alguna cosa: hi ha * moltes * maneres d’allotjar-los a Azure. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents, i tots semblen raonables fins que realment n’has de triar un. Microsoft acaba de publicar una guia completa per a l’allotjament d’agents d’Azure AI que ho aclareix, i vull desglossar-ho des d’una perspectiva pràctica del desenvolupador.NET.

Les sis opcions d’un cop d’ull

Així és com resumiria el paisatge:

Opció	El millor per	Tu gestiones
Aplicacions de contenidors	Control total del contenidor sense complexitat K8s	Observabilitat, estat, cicle de vida
AKS	Compliment empresarial, multi-clúster, xarxes personalitzades	Tot (aquest és el punt)
Funcions d’Azure	Tasques d’agent de curta durada i impulsades per esdeveniments	No gaire, veritat sense servidor
Servei d’aplicacions	Agents HTTP simples, trànsit previsible	Desplegament, configuració d’escalat
Agents de Foundry	Agents opcionals de codi a través del portal/SDK	Gairebé res
Agents allotjats de Foundry	Agents de marc personalitzats amb infraestructures gestionades	Només el vostre codi d’agent

Els quatre primers són càlculs de propòsit general: podeu executar-hi agents, però no estaven dissenyats per a això. Els dos últims són nadius dels agents: entenen les converses, les trucades d’eines i els cicles de vida dels agents com a conceptes de primera classe.

Foundry Hosted Agents: el lloc ideal per als desenvolupadors d’agents.NET

Aquí és el que em va cridar l’atenció. Els agents allotjats de Foundry se situen al centre: teniu la flexibilitat d’executar el vostre propi codi (nucli semàntic, marc d’agents, LangGraph, el que sigui), però la plataforma gestiona la infraestructura, l’observabilitat i la gestió de converses.

La peça clau és l’Adaptador d’allotjament: una capa d’abstracció fina que connecta el vostre marc d’agent amb la plataforma Foundry. Per a Microsoft Agent Framework, té aquest aspecte:

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

Aquesta és tota la vostra història d’allotjament. L’adaptador gestiona la traducció del protocol, la transmissió mitjançant esdeveniments enviats pel servidor, l’historial de converses i el seguiment d’OpenTelemetry, tot automàticament. Sense programari intermedi personalitzat, sense fontaneria manual.

El desplegament és realment senzill

Abans he desplegat agents a Container Apps i funciona, però acabeu escrivint molt codi de cola per a la gestió de l’estat i l’observabilitat. Amb Hosted Agents i azd, el desplegament és:

# Install the AI agent extension
azd ext install azure.ai.agents

# Init from a template
azd ai agent init

# Build, push, deploy — done
azd up

Aquest únic azd up crea el vostre contenidor, l’envia a ACR, subministra el projecte Foundry, desplega els punts finals del model i inicia el vostre agent. Cinc passos es van col·lapsar en una ordre.

Gestió de converses integrada

Aquesta és la peça que estalvia més temps en la producció. En lloc de crear el vostre propi magatzem d’estat de conversa, els agents allotjats ho gestionen de manera nativa:

# Create a persistent conversation
conversation = openai_client.conversations.create()

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

# Second turn — context is preserved
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

No Redis. No hi ha botiga de sessions de Cosmos DB. No hi ha programari intermediari personalitzat per a la serialització de missatges. La plataforma només ho gestiona.

El meu marc de decisió

Després de revisar les sis opcions, aquí teniu el meu model mental ràpid:

Necessites zero infraestructura? → Agents de Foundry (portal/SDK, sense contenidors)
Tens un codi d’agent personalitzat però vols un allotjament gestionat? → Agents allotjats de Foundry
Necessiteu tasques d’agent de curta durada i basades en esdeveniments? → Azure Functions
Necessites el màxim control dels contenidors sense K8? → Aplicacions de contenidors
Necessites un compliment estricte i múltiples clústers? → AKS
Teniu un agent HTTP senzill amb trànsit previsible? → Servei d’aplicacions

Per a la majoria de desenvolupadors de.NET que creen amb Semantic Kernel o Microsoft Agent Framework, Hosted Agents és probablement el punt de partida adequat. Obteniu una escala a zero, OpenTelemetry integrada, gestió de converses i flexibilitat de marc, sense gestionar Kubernetes ni connectar la vostra pròpia pila d’observabilitat.

Tancant

El paisatge d’allotjament d’agents a Azure està madurant ràpidament. Si inicieu un nou projecte d’agent d’IA avui, m’agradaria considerar seriosament els agents allotjats de Foundry abans d’arribar a Container Apps o AKS per costum. La infraestructura gestionada estalvia temps real i el patró de l’adaptador d’allotjament us permet mantenir la vostra elecció de marc.

Consulteu la guia completa de Microsoft i el repositori de mostres de Foundry per obtenir exemples de treball.

KubeCon Europe 2026: què haurien de preocupar-se realment als desenvolupadors.NET

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

Coneixes aquesta sensació quan cau una publicació d’anunci massiva i t’estàs desplaçant per ella pensant “genial, però què canvia això realment per a mi”? Soc jo cada temporada de la KubeCon.

Microsoft acaba de publicar el seu resum complet de KubeCon Europe 2026, escrit pel mateix Brendan Burns, i sincerament? Aquí hi ha substància real. No només inclouen les caselles de selecció, sinó també el tipus de millores operatives que canvien la manera d’executar les coses en producció.

Permeteu-me desglossar el que realment importa per als desenvolupadors de.NET.

mTLS sense l’impost de malla de servei

Això és el que passa amb les malles de servei: tothom vol les garanties de seguretat, ningú vol la sobrecàrrega operativa. AKS finalment està tancant aquesta bretxa.

Azure Kubernetes Application Network us ofereix TLS mutu, autorització conscient de l’aplicació i telemetria de trànsit, sense desplegar una malla plena de sidecars. Combinat amb Cilium mTLS a Advanced Container Networking Services, obteniu una comunicació xifrada de pod a pod mitjançant certificats X.509 i SPIRE per a la gestió d’identitats.

Què significa això a la pràctica: les vostres API ASP.NET Core parlen amb treballadors en segon pla, els vostres serveis gRPC es trucen entre ells, tot xifrat i verificat per la identitat a nivell de xarxa, sense canvis en el codi de l’aplicació. Això és enorme.

Per als equips que migren des de ingress-nginx, també hi ha Application Routing with Meshless Istio amb suport complet de l’API de Kubernetes Gateway. Sense sidecars. Basat en estàndards. I van enviar eines ingress2gateway per a la migració incremental.

Observabilitat de la GPU que no és una idea posterior

Si utilitzeu una inferència d’IA juntament amb els vostres serveis.NET (i siguem sincers, qui no comença a fer-ho?), probablement heu arribat al punt cec de supervisió de la GPU. Obtindreu grans taulers de CPU/memòria i després… res per a les GPU sense una fontaneria d’exportació manual.

AKS ara mostra les mètriques de la GPU de manera nativa a Prometheus i Grafana gestionats. Mateixa pila, mateixos taulers de comandament, mateix canal d’alertes. Sense exportadors personalitzats, ni agents de tercers.

Al costat de la xarxa, van afegir visibilitat per flux per al trànsit HTTP, gRPC i Kafka amb una experiència d’Azure Monitor amb un sol clic. IP, ports, càrregues de treball, direcció del flux, decisions polítiques, tot en taulers integrats.

I aquesta és la que m’ha fet fer una doble presa: xarxa de contenidors agent afegeix una interfície d’usuari web on podeu fer preguntes en llenguatge natural sobre l’estat de la xarxa del vostre clúster. “Per què el pod X no arriba al servei Y?” → diagnòstics de només lectura de la telemetria en directe. Això és realment útil a les 2 del matí.

Xarxes entre clústers que no requereixen un doctorat

Històricament, Kubernetes multiclúster ha estat una experiència de “porta la teva pròpia cola de xarxa”. Azure Kubernetes Fleet Manager ara s’envia xarxes entre clústers mitjançant la malla de clúster de Cilium gestionada:

Connectivitat unificada entre clústers AKS
Registre global de serveis per a la descoberta entre clústers
Configuració gestionada de manera centralitzada, no repetida per clúster

Si utilitzeu microserveis.NET en diferents regions per a la seva resiliència o compliment, això substitueix una gran quantitat de fontaneria personalitzada fràgil. El servei A a l’oest d’Europa pot descobrir i trucar al servei B a l’est dels EUA a través de la malla, amb polítiques d’encaminament i seguretat coherents.

Actualitzacions que no requereixen valentia

Siguem sincers: les actualitzacions de Kubernetes en producció són estressants. “Actualitzar i esperar” ha estat l’estratègia de facto per a massa equips, i és el principal motiu pel qual els clústers es queden endarrerits en les versions.

Dues noves capacitats canvien això:

Les actualitzacions del grup d’agents blau-verd creen un grup de nodes paral·lels amb la nova configuració. Valideu el comportament, canvieu el trànsit gradualment i manteniu un camí de retrocés net. No més mutacions in situ als nodes de producció.

La recuperació de l’agrupació d’agents us permet revertir una agrupació de nodes a la seva versió anterior de Kubernetes i a la imatge de node després d’una actualització de costat, sense haver de reconstruir el clúster.

En conjunt, finalment donen als operadors un control real sobre el cicle de vida de l’actualització. Per als equips.NET, això és important perquè la velocitat de la plataforma controla directament la rapidesa amb què podeu adoptar nous temps d’execució, pedaços de seguretat i capacitats de xarxa.

Les càrregues de treball d’IA s’estan convertint en ciutadans de primer nivell de Kubernetes

El treball de codi obert amunt és igual d’important. L’assignació dinàmica de recursos (DRA) acaba de passar a GA a Kubernetes 1.36, fent que la programació de la GPU sigui una funció adequada de primera classe en lloc d’una solució alternativa.

Alguns projectes que val la pena veure:

Projecte	Què fa
AI Runway	API comuna de Kubernetes per a la inferència: implementeu models sense conèixer els K8, amb el descobriment d’HuggingFace i les estimacions de costos
HolmesGPT	Resolució de problemes d’agent per als nadius del núvol: ara un projecte Sandbox CNCF
Dalec	La imatge de contenidor declarativa es construeix amb la generació SBOM: menys CVE en l’etapa de creació

La direcció és clara: la vostra API.NET, la vostra capa d’orquestració del nucli semàntic i les vostres càrregues de treball d’inferència s’han d’executar en un model de plataforma coherent. Hi arribem.

Per on començaria aquesta setmana

Si esteu avaluant aquests canvis per al vostre equip, aquí teniu la meva llista de prioritats honesta:

Observabilitat primer: activeu les mètriques de la GPU i els registres de flux de xarxa en un clúster que no sigui de producte. Mira què t’has perdut.
Proveu les actualitzacions blau-verd: proveu el flux de treball de retrocés abans de la propera actualització del clúster de producció. Generar confiança en el procés.
Pilota de xarxes conscients de la identitat: trieu una ruta de servei interna i activeu mTLS amb Cilium. Mesureu la sobrecàrrega (spoiler: és mínim).
Avalueu el gestor de flotes: si executeu més de dos clústers, la xarxa entre clústers es compensa amb una cola personalitzada reduïda.

Petits experiments, feedback ràpid. Aquest és sempre el moviment.

Tancant

Els anuncis de KubeCon poden ser aclaparadors, però aquest lot realment mou l’agulla dels equips.NET a AKS. Millor seguretat de xarxes sense sobrecàrrega de malla, observabilitat real de la GPU, actualitzacions més segures i bases d’infraestructura d’IA més sòlides.

Si ja esteu a AKS, aquest és un bon moment per endurir la vostra línia de base operativa. I si teniu previst traslladar les càrregues de treball.NET a Kubernetes, la plataforma s’acaba de preparar molt més per a la producció.