Cloud-Native | The .NET Blog

Hook azd in Python, TypeScript e .NET: basta script shell

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

Questo articolo è stato tradotto automaticamente. Per la versione originale, clicca qui.

Se hai mai avuto un progetto completamente in .NET e ti sei ritrovato a scrivere script Bash solo per gli hook di azd, conosci bene quella sensazione. Perché passare alla sintassi shell per un passaggio di pre-provisioning quando tutto il resto del progetto è in C#?

Quella frustrazione ha ora una soluzione ufficiale. La CLI di Azure Developer ha appena introdotto il supporto multi-linguaggio per gli hook, ed è esattamente buono come sembra.

Gli hook, in breve

Gli hook sono script eseguiti in punti chiave del ciclo di vita di azd — prima del provisioning, dopo il deployment, e altro ancora. Definiti in azure.yaml, permettono di iniettare logica personalizzata senza modificare la CLI.

Prima erano supportati solo Bash e PowerShell. Ora si può usare Python, JavaScript, TypeScript o .NET — e azd si occupa del resto automaticamente.

Come funziona il rilevamento

Basta puntare l’hook verso un file e azd deduce il linguaggio dall’estensione:

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

Nessuna configurazione aggiuntiva. Se l’estensione è ambigua, si può aggiungere kind: python (o il linguaggio appropriato) per specificarlo esplicitamente.

Dettagli per linguaggio

Python

Inserire un requirements.txt o pyproject.toml vicino allo script (o in una directory padre). azd crea automaticamente un ambiente virtuale, installa le dipendenze ed esegue lo script.

JavaScript e TypeScript

Stesso schema — un package.json vicino allo script e azd esegue prima npm install. Per TypeScript, usa npx tsx senza step di compilazione né tsconfig.json.

.NET

Due modalità disponibili:

Modalità progetto: Se c’è un .csproj vicino allo script, azd esegue automaticamente dotnet restore e dotnet build.
Modalità single-file: Con .NET 10+, i file .cs autonomi vengono eseguiti direttamente via dotnet run script.cs. Nessun file di progetto richiesto.

Configurazione per executor

Ogni linguaggio supporta un blocco config opzionale:

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

Perché è importante per gli sviluppatori .NET

Gli hook erano l’ultimo posto in un progetto basato su azd che costringeva a cambiare linguaggio. Ora l’intera pipeline di deployment può vivere in un unico linguaggio. È possibile riutilizzare le utility .NET esistenti negli hook, referenziare librerie condivise ed eliminare la manutenzione di script shell.

Conclusione

Uno di quei cambiamenti che sembrano piccoli ma che riducono concretamente la frizione quotidiana con azd. Il supporto multi-linguaggio per gli hook è disponibile ora — tutti i dettagli nel post ufficiale.

Global Azure Spain 2026

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

Global Azure Spain 2026 si tiene il 18 aprile 2026 al Kinépolis Diversia ad Alcobendas, Madrid. È il più grande evento comunitario Azure in Spagna, con 38 speaker su 3 track paralleli dedicati ad agenti IA, networking Azure, Cosmos DB, Fabric, IoT, sicurezza e molto altro.

L’evento si svolge dalle 08:30 alle 18:30 e include keynote, pause caffè, pranzo e una sessione di chiusura Q&A.

Punti salienti dell’agenda

Domando Agentes de IA: governance, strumenti e API con Azure AI Foundry e 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!: sistemi multi-agente in azione
Foundry Control Plane como plataforma de Agentes global
Rompiendo el perímetro: Zero Trust aplicado en Azure

Biglietti

L’iscrizione prevede una donazione simbolica — l’intero prezzo del biglietto va direttamente a Plan International, a sostegno dei diritti dei bambini e dell’uguaglianza nel mondo. Posti limitati, prenota il tuo posto in anticipo.

Azure Tour 2026

Oltre a Madrid, il Global Azure Tour 2026 prevede tappe anche a Saragozza, Tenerife e Siviglia.

Aspire 13.2 aggiunge MongoDB EF Core e Azure Data Lake — Due integrazioni da provare

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

Questo post è stato tradotto automaticamente. Per la versione originale, clicca qui.

Aspire 13.2 è appena arrivato con due nuove integrazioni database che meritano la vostra attenzione: MongoDB Entity Framework Core e Azure Data Lake Storage. Se volevate usare EF Core con MongoDB in un’app Aspire, o avevate bisogno di collegare workload data lake con il service discovery, questa release offre entrambe le cose.

MongoDB incontra EF Core in Aspire

Questa è quella che mi entusiasma di più. Aspire supporta MongoDB da un po’, ma è sempre stato il driver grezzo — niente EF Core, niente DbContext, niente query LINQ sui vostri documenti. Ora avete l’esperienza completa di EF Core con MongoDB, più gli health check automatici e il service discovery di Aspire.

La configurazione segue il classico pattern di Aspire. Nel vostro AppHost:

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

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

Poi nel progetto consumatore, aggiungete l’integrazione EF Core:

dotnet add package Aspire.MongoDB.EntityFrameworkCore

E registrate il vostro DbContext:

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

Da lì in poi, è EF Core standard. Definite le vostre entità, usate il vostro DbContext come fareste con qualsiasi altro provider. L’integrazione gestisce il connection pooling, le trace OpenTelemetry e gli health check dietro le quinte.

Per gli sviluppatori .NET che usavano MongoDB con il driver grezzo e configuravano le connection string manualmente, questo è un bel miglioramento. Ottenete l’astrazione completa di EF Core senza perdere il service discovery di Aspire.

Azure Data Lake Storage entra in gioco

La seconda grande aggiunta è un’integrazione Azure Data Lake Storage (ADLS). Se state costruendo pipeline di dati, processi ETL o piattaforme di analisi, ora potete collegare risorse Data Lake allo stesso modo di qualsiasi altra dipendenza Aspire.

Nell’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);

Nel progetto consumatore:

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

Nessuna gestione manuale delle connection string, nessuna caccia alle credenziali. Aspire effettua il provisioning delle risorse e le inietta. Per chi di noi costruisce app .NET cloud-native che toccano sia dati operazionali che workload analitici, questo fa sentire il data lake come un cittadino di prima classe nel modello Aspire.

Le piccole correzioni che contano

Oltre alle funzionalità principali, ci sono alcuni miglioramenti degni di nota:

Fix della connection string MongoDB — lo slash prima del nome del database ora viene gestito correttamente. Se avevate un workaround, potete rimuoverlo
Export SQL Server — Aspire.Hosting.SqlServer ora esporta opzioni di configurazione server aggiuntive per un controllo più granulare
Aggiornamenti emulatori — emulatore ServiceBus 2.0.0, emulatore App Configuration 1.0.2, e l’emulatore preview di CosmosDB ora include un readiness check
Azure Managed Redis — ora usa rediss:// (Redis Secure) di default, quindi le connessioni sono crittografate fin da subito

L’ultimo punto è sottile ma importante — Redis crittografato di default significa una cosa in meno da configurare in produzione.

Per concludere

Aspire 13.2 è una release incrementale, ma le integrazioni MongoDB EF Core e Data Lake colmano lacune reali. Se stavate aspettando un supporto EF Core adeguato con MongoDB in Aspire, o avevate bisogno del Data Lake come dipendenza di prima classe, aggiornate alla 13.2 e provatele. Il comando aspire add genera tutto il necessario.

Leggete le note di rilascio complete per maggiori dettagli, e date un’occhiata alla galleria delle integrazioni per la lista completa.

Azure Smart Tier è in GA — Ottimizzazione automatica dei costi di Blob Storage senza regole di ciclo di vita

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

Questo post è stato tradotto automaticamente. Per la versione originale, clicca qui.

Se hai mai passato tempo a ottimizzare le policy di ciclo di vita di Azure Blob Storage per poi vederle crollare quando i pattern di accesso sono cambiati, questo è per te. Microsoft ha appena annunciato la disponibilità generale dello smart tier per Azure Blob e Data Lake Storage — una funzionalità di tiering completamente gestita che sposta automaticamente gli oggetti tra i livelli hot, cool e cold in base all’utilizzo reale.

Cosa fa realmente lo smart tier

Il concetto è semplice: lo smart tier valuta continuamente l’ultimo orario di accesso di ogni oggetto nel tuo account di archiviazione. I dati acceduti frequentemente restano in hot, i dati inattivi passano a cool dopo 30 giorni, e poi a cold dopo altri 60 giorni. Quando i dati vengono nuovamente acceduti, vengono promossi subito a hot. Il ciclo ricomincia.

Nessuna regola di ciclo di vita da configurare. Nessuna previsione dei pattern di accesso. Nessun tuning manuale.

Durante la preview, Microsoft ha riportato che oltre il 50% della capacità gestita dallo smart tier si è spostata automaticamente verso livelli più freddi in base ai pattern di accesso reali. È una riduzione dei costi significativa per account di archiviazione di grandi dimensioni.

Perché è importante per gli sviluppatori .NET

Se stai costruendo applicazioni che generano log, telemetria, dati analitici, o qualsiasi tipo di patrimonio dati in crescita — e siamo onesti, chi non lo fa? — i costi di archiviazione si accumulano velocemente. L’approccio tradizionale era scrivere policy di gestione del ciclo di vita, testarle e poi ricalibrarle quando i pattern di accesso della tua applicazione cambiavano. Lo smart tier elimina completamente quel workflow.

Alcuni scenari pratici dove questo aiuta:

Telemetria e log delle applicazioni — hot durante il debug, raramente acceduti dopo qualche settimana
Pipeline di dati e output ETL — acceduti intensamente durante l’elaborazione, poi per lo più cold
Contenuti generati dagli utenti — gli upload recenti sono hot, i contenuti più vecchi si raffreddano gradualmente
Dati di backup e archiviazione — acceduti occasionalmente per conformità, per lo più inattivi

Come configurarlo

Abilitare lo smart tier è una configurazione una tantum:

Account nuovi: Seleziona smart tier come livello di accesso predefinito durante la creazione dell’account di archiviazione (ridondanza zonale richiesta)
Account esistenti: Cambia il livello di accesso blob dall’impostazione predefinita attuale a smart tier

Gli oggetti più piccoli di 128 KiB restano in hot e non generano la tariffa di monitoraggio. Per tutto il resto, paghi le tariffe standard di capacità hot/cool/cold senza costi di transizione tra livelli, senza penali per eliminazione anticipata e senza costi di recupero dati. Una tariffa mensile di monitoraggio per oggetto copre l’orchestrazione.

Il compromesso da conoscere

Le regole di tiering dello smart tier sono statiche (30 giorni → cool, 90 giorni → cold). Se hai bisogno di soglie personalizzate — ad esempio, spostare a cool dopo 7 giorni per un workload specifico — le regole di ciclo di vita restano la strada giusta. E non mescolare entrambi: evita di usare regole di ciclo di vita su oggetti gestiti dallo smart tier, perché possono entrare in conflitto.

Conclusione

Non è rivoluzionario, ma risolve un vero grattacapo operativo. Se gestisci account di blob storage in crescita e sei stanco di mantenere le policy di ciclo di vita, abilita lo smart tier e lascia che Azure se ne occupi. È disponibile oggi in quasi tutte le regioni zonali del cloud pubblico.

Dove dovresti ospitare i tuoi agenti IA su Azure? Una guida decisionale pratica

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

Questo post è stato tradotto automaticamente. Per la versione originale, clicca qui.

Se stai costruendo agenti IA con .NET in questo momento, probabilmente hai notato qualcosa: ci sono molti modi per ospitarli su Azure. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — e tutti sembrano ragionevoli finché non devi effettivamente sceglierne uno. Microsoft ha appena pubblicato una guida completa all’hosting di agenti IA su Azure che chiarisce tutto, e voglio analizzarla dalla prospettiva pratica di uno sviluppatore .NET.

Le sei opzioni a colpo d’occhio

Ecco come riassumerei il panorama:

Opzione	Ideale per	Gestisci tu
Container Apps	Controllo totale dei container senza complessità K8s	Osservabilità, stato, ciclo di vita
AKS	Compliance aziendale, multi-cluster, networking personalizzato	Tutto (è quello il punto)
Azure Functions	Task di agenti event-driven e di breve durata	Quasi niente — serverless vero
App Service	Agenti HTTP semplici, traffico prevedibile	Deploy, config di scaling
Foundry Agents	Agenti senza codice via portale/SDK	Quasi niente
Foundry Hosted Agents	Agenti con framework personalizzato e infra gestita	Solo il tuo codice agente

Le prime quattro sono compute general-purpose — puoi eseguire agenti su di esse, ma non sono state progettate per quello. Le ultime due sono native per agenti: comprendono conversazioni, chiamate a strumenti e cicli di vita degli agenti come concetti di prima classe.

Foundry Hosted Agents — il punto ideale per sviluppatori .NET di agenti

Questo è ciò che ha catturato la mia attenzione. I Foundry Hosted Agents si posizionano proprio nel mezzo: ottieni la flessibilità di eseguire il tuo codice (Semantic Kernel, Agent Framework, LangGraph — qualsiasi cosa) ma la piattaforma gestisce infrastruttura, osservabilità e gestione delle conversazioni.

Il pezzo chiave è l’Hosting Adapter — un sottile livello di astrazione che collega il tuo framework di agenti alla piattaforma Foundry. Per Microsoft Agent Framework, appare così:

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

Questa è tutta la tua storia di hosting. L’adapter gestisce traduzione di protocolli, streaming via server-sent events, cronologia delle conversazioni e tracing OpenTelemetry — tutto automaticamente. Nessun middleware personalizzato, nessun plumbing manuale.

Il deploy è genuinamente semplice

Ho fatto deploy di agenti su Container Apps prima e funziona, ma finisci per scrivere molto codice di collegamento per gestione dello stato e osservabilità. Con Hosted Agents e azd, il deploy è:

# Installare l'estensione agente IA
azd ext install azure.ai.agents

# Inizializzare da un template
azd ai agent init

# Costruire, pushare, fare deploy — fatto
azd up

Quel singolo azd up costruisce il tuo container, lo pusha su ACR, provisiona il progetto Foundry, fa deploy degli endpoint del modello e avvia il tuo agente. Cinque passaggi condensati in un solo comando.

Gestione conversazioni integrata

Questa è la parte che fa risparmiare più tempo in produzione. Invece di costruire il tuo store di stato delle conversazioni, gli Hosted Agents lo gestiscono nativamente:

# Creare una conversazione persistente
conversation = openai_client.conversations.create()

# Primo 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.",
)

# Secondo turno — il contesto è preservato
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

Niente Redis. Niente session store Cosmos DB. Niente middleware personalizzato per la serializzazione dei messaggi. La piattaforma semplicemente se ne occupa.

Il mio framework decisionale

Dopo aver esaminato tutte e sei le opzioni, ecco il mio modello mentale rapido:

Hai bisogno di zero infrastruttura? → Foundry Agents (portale/SDK, niente container)
Hai codice agente personalizzato ma vuoi hosting gestito? → Foundry Hosted Agents
Hai bisogno di task agente event-driven e di breve durata? → Azure Functions
Hai bisogno di massimo controllo dei container senza K8s? → Container Apps
Hai bisogno di compliance rigorosa e multi-cluster? → AKS
Hai un agente HTTP semplice con traffico prevedibile? → App Service

Per la maggior parte degli sviluppatori .NET che costruiscono con Semantic Kernel o Microsoft Agent Framework, Hosted Agents è probabilmente il punto di partenza giusto. Ottieni scale-to-zero, OpenTelemetry integrato, gestione conversazioni e flessibilità di framework — senza gestire Kubernetes o montare il tuo stack di osservabilità.

Per concludere

Il panorama dell’hosting di agenti su Azure sta maturando velocemente. Se stai iniziando un nuovo progetto di agente IA oggi, considererei seriamente Foundry Hosted Agents prima di ricorrere a Container Apps o AKS per abitudine. L’infrastruttura gestita fa risparmiare tempo reale, e il pattern hosting adapter ti permette di mantenere la tua scelta di framework.

Dai un’occhiata alla guida completa di Microsoft e al repo Foundry Samples per esempi funzionanti.

KubeCon Europe 2026: Cosa dovrebbero davvero sapere gli sviluppatori .NET

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

Questo post è stato tradotto automaticamente. Per la versione originale, clicca qui.

Conosci quella sensazione quando esce un post di annunci enorme e scrolli pensando “bello, ma cosa cambia davvero per me”? Mi succede ogni stagione KubeCon.

Microsoft ha appena pubblicato il riassunto completo di KubeCon Europe 2026 — scritto da Brendan Burns in persona — e onestamente? C’è sostanza vera. Non solo checklist di feature, ma miglioramenti operativi che cambiano come gestisci le cose in produzione.

Vediamo cosa conta davvero per noi sviluppatori .NET.

mTLS senza la tassa del service mesh

Il punto sui service mesh: tutti vogliono le garanzie di sicurezza, nessuno vuole il carico operativo. AKS sta finalmente colmando questo divario.

Azure Kubernetes Application Network ti dà mutual TLS, autorizzazione application-aware e telemetria del traffico — senza deployare un mesh pesante con sidecar. Combinato con Cilium mTLS in Advanced Container Networking Services, ottieni comunicazione crittografata pod-a-pod usando certificati X.509 e SPIRE per la gestione delle identità.

Cosa significa in pratica: le tue API ASP.NET Core che parlano con worker in background, i tuoi servizi gRPC che si chiamano a vicenda — tutto crittografato e verificato a livello di rete, senza modifiche al codice applicativo. È enorme.

Per i team che migrano da ingress-nginx, c’è anche Application Routing con Meshless Istio con supporto completo per Kubernetes Gateway API. Niente sidecar. Basato su standard. E hanno rilasciato strumenti ingress2gateway per la migrazione incrementale.

Osservabilità GPU che non è un ripensamento

Se stai eseguendo inferenza IA accanto ai tuoi servizi .NET (e siamo onesti, chi non sta iniziando?), probabilmente hai incontrato il punto cieco del monitoraggio GPU. Avevi dashboard fantastiche per CPU/memoria e poi… niente per le GPU senza configurazione manuale degli exporter.

AKS ora espone le metriche GPU nativamente in Prometheus e Grafana gestiti. Stesso stack, stesse dashboard, stessa pipeline di alerting. Nessun exporter custom, nessun agent di terze parti.

Sul lato rete, hanno aggiunto visibilità per flusso per traffico HTTP, gRPC e Kafka con un’esperienza Azure Monitor one-click. IP, porte, workload, direzione del flusso, decisioni di policy — tutto in dashboard integrate.

E quella che mi ha fatto guardare due volte: agentic container networking aggiunge un’interfaccia web dove puoi fare domande in linguaggio naturale sullo stato di rete del tuo cluster. “Perché il pod X non raggiunge il servizio Y?” → diagnostica read-only dalla telemetria live. Genuinamente utile alle 2 di notte.

Networking cross-cluster senza bisogno di un dottorato

Il multi-cluster Kubernetes storicamente è stato un’esperienza “porta la tua colla di rete”. Azure Kubernetes Fleet Manager ora offre networking cross-cluster tramite Cilium cluster mesh gestito:

Connettività unificata tra cluster AKS
Registro globale dei servizi per la scoperta cross-cluster
Configurazione gestita centralmente, non ripetuta per cluster

Se esegui microservizi .NET su più regioni per resilienza o compliance, questo sostituisce molto collante custom fragile. Il Servizio A in West Europe può scoprire e chiamare il Servizio B in East US attraverso il mesh, con policy di routing e sicurezza consistenti.

Aggiornamenti che non richiedono coraggio

Siamo onesti — gli aggiornamenti Kubernetes in produzione sono stressanti. “Aggiornare e sperare” è stata la strategia de facto per troppi team, ed è la ragione principale per cui i cluster restano indietro con le versioni.

Due nuove capacità cambiano questo:

Blue-green agent pool upgrade creano un pool di nodi parallelo con la nuova configurazione. Valida il comportamento, sposta il traffico gradualmente e mantieni un percorso di rollback pulito. Niente più mutazioni in-place su nodi di produzione.

Agent pool rollback permette di riportare un pool di nodi alla versione Kubernetes e all’immagine nodo precedenti dopo che un aggiornamento va storto — senza ricostruire il cluster.

Insieme, danno finalmente agli operatori un vero controllo sul ciclo di vita degli aggiornamenti. Per i team .NET, questo è importante perché la velocità della piattaforma controlla direttamente quanto rapidamente puoi adottare nuovi runtime, patch di sicurezza e capacità di rete.

I workload IA diventano cittadini di prima classe in Kubernetes

Il lavoro upstream open-source è altrettanto importante. Dynamic Resource Allocation (DRA) è appena andato in GA in Kubernetes 1.36, rendendo lo scheduling GPU una feature di prima classe invece di un workaround.

Alcuni progetti da tenere d’occhio:

Progetto	Cosa fa
AI Runway	API Kubernetes comune per l’inferenza — deploy di modelli senza conoscere K8s, con scoperta HuggingFace e stime dei costi
HolmesGPT	Troubleshooting agentico per il cloud-native — ora un progetto CNCF Sandbox
Dalec	Build dichiarativi di immagini container con generazione SBOM — meno CVE nella fase di build

La direzione è chiara: la tua API .NET, il tuo layer di orchestrazione con Semantic Kernel e i tuoi workload di inferenza dovrebbero tutti girare su un modello di piattaforma consistente. Ci stiamo arrivando.

Da dove partirei questa settimana

Se stai valutando questi cambiamenti per il tuo team, ecco la mia lista onesta di priorità:

Osservabilità prima — abilita le metriche GPU e i log di flusso di rete in un cluster non-prod. Guarda cosa ti sei perso.
Prova i blue-green upgrade — testa il workflow di rollback prima del tuo prossimo aggiornamento di cluster in produzione. Costruisci fiducia nel processo.
Pilota il networking identity-aware — scegli un percorso di servizio interno e abilita mTLS con Cilium. Misura l’overhead (spoiler: è minimo).
Valuta Fleet Manager — se gestisci più di due cluster, il networking cross-cluster si ripaga da solo in riduzione di collante custom.

Piccoli esperimenti, feedback veloce. È sempre la mossa giusta.

Per concludere

Gli annunci KubeCon possono essere travolgenti, ma questa tornata muove davvero l’ago per i team .NET su AKS. Migliore sicurezza di rete senza overhead di mesh, vera osservabilità GPU, aggiornamenti più sicuri e fondamenta più solide per l’infrastruttura IA.

Se sei già su AKS, è un ottimo momento per rafforzare la tua baseline operativa. E se stai pianificando di spostare workload .NET su Kubernetes — la piattaforma è appena diventata significativamente più pronta per la produzione.