Cloud-Native | The .NET Blog

Python, TypeScript और .NET में azd Hooks: Shell Scripts से मुक्ति

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

यह पोस्ट स्वचालित रूप से अनुवादित की गई है। मूल संस्करण के लिए, यहाँ क्लिक करें।

अगर आपने कभी पूरी तरह .NET में बना प्रोजेक्ट रखा हो और फिर भी azd hooks के लिए Bash scripts लिखनी पड़ी हों, तो वो दर्द आप समझते हैं। जब प्रोजेक्ट का बाकी सब कुछ C# है, तो pre-provisioning step के लिए shell syntax में क्यों जाएं?

वो frustration अब officially solve हो गई है। Azure Developer CLI ने hooks के लिए multi-language support launch किया है, और यह उतना ही अच्छा है जितना सुनाई देता है।

Hooks क्या हैं

Hooks वो scripts हैं जो azd lifecycle के key points पर run होती हैं — provisioning से पहले, deployment के बाद, और अन्य। ये azure.yaml में define होती हैं और CLI को modify किए बिना custom logic inject करने देती हैं।

पहले सिर्फ Bash और PowerShell support थे। अब Python, JavaScript, TypeScript या .NET use कर सकते हैं — बाकी सब azd automatically handle करता है।

Detection कैसे काम करती है

बस hook को एक file पर point करें और azd extension से language infer करता है:

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

कोई extra config नहीं। अगर extension ambiguous हो तो kind: python (या relevant language) explicitly specify कर सकते हैं।

Language-specific details

Python

Script के साथ (या किसी parent directory में) requirements.txt या pyproject.toml रखें। azd automatically virtual environment बनाएगा, dependencies install करेगा और script run करेगा।

JavaScript और TypeScript

Same pattern — script के पास package.json रखें और azd पहले npm install run करेगा। TypeScript के लिए npx tsx use होता है, बिना compile step और बिना tsconfig.json।

.NET

दो modes उपलब्ध:

Project mode: Script के पास .csproj हो तो azd automatically dotnet restore और dotnet build run करता है।
Single-file mode: .NET 10+ पर standalone .cs files सीधे dotnet run script.cs से run होती हैं। Project file की जरूरत नहीं।

Executor-specific configuration

हर language optional config block support करती है:

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

.NET developers के लिए क्यों मायने रखता है

Hooks azd-based project में वो आखिरी जगह थी जो language switch करने पर मजबूर करती थी। अब पूरा deployment pipeline — app code से लेकर lifecycle hooks तक — एक ही language में रह सकता है। Existing .NET utilities hooks में reuse कर सकते हैं, shared libraries reference कर सकते हैं, और shell script maintenance से छुटकारा मिलता है।

निष्कर्ष

ये उन changes में से एक है जो छोटे लगते हैं लेकिन azd के daily workflow से बहुत friction हटाते हैं। Hooks के लिए multi-language support अभी available है — full documentation के लिए official post देखें।

Aspire 13.2 में MongoDB EF Core और Azure Data Lake — दो Integrations जो आज़माने लायक हैं

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

यह पोस्ट स्वचालित रूप से अनुवादित है। मूल के लिए, यहाँ क्लिक करें.

Aspire 13.2 अभी दो नए database integrations के साथ आया है जो आपका ध्यान आकर्षित करने के लायक हैं: MongoDB Entity Framework Core और Azure Data Lake Storage। अगर आप Aspire app में EF Core के साथ MongoDB उपयोग करना चाहते थे, या proper service discovery के साथ data lake workloads wire up करने की ज़रूरत थी, तो यह release दोनों deliver करती है।

MongoDB meets EF Core in Aspire

यह वो है जिसके बारे में मैं सबसे ज़्यादा excited हूँ। Aspire ने काफी समय से MongoDB को support किया है, लेकिन यह हमेशा raw driver था — कोई EF Core नहीं, कोई DbContext नहीं, documents के खिलाफ कोई LINQ queries नहीं। अब आपको MongoDB के साथ पूरा EF Core experience मिलता है, plus Aspire के automatic health checks और service discovery।

इसे setup करना typical Aspire pattern है। अपने AppHost में:

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

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

फिर अपने consuming project में, EF Core integration जोड़ें:

dotnet add package Aspire.MongoDB.EntityFrameworkCore

और अपना DbContext register करें:

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

वहाँ से, यह standard EF Core है। अपनी entities define करें, अपने DbContext को किसी भी दूसरे provider की तरह उपयोग करें। Integration connection pooling, OpenTelemetry traces और health checks को behind the scenes handle करता है।

.NET developers के लिए जो raw driver के साथ MongoDB उपयोग कर रहे थे और manually connection strings wire up कर रहे थे, यह एक अच्छा quality-of-life upgrade है। आपको Aspire की service discovery खोए बिना पूरा EF Core abstraction मिलता है।

Azure Data Lake Storage पार्टी में शामिल हुई

दूसरा बड़ा addition एक Azure Data Lake Storage (ADLS) integration है। अगर आप data pipelines, ETL processes, या analytics platforms बना रहे हैं, तो अब आप Data Lake resources को उसी तरह wire up कर सकते हैं जैसे आप किसी दूसरी Aspire dependency को करते हैं।

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

Consuming project में:

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

कोई manual connection string management नहीं, कोई credential hunting नहीं। Aspire resources provision करता है और उन्हें inject करता है। जो लोग cloud-native .NET apps बना रहे हैं जो operational data और analytics workloads दोनों को handle करती हैं, उनके लिए यह data lake को Aspire model में एक first-class citizen जैसा महसूस कराता है।

छोटे fixes जो मायने रखते हैं

Headline features के अलावा, कुछ quality-of-life improvements भी हैं जो ध्यान देने योग्य हैं:

MongoDB connection string fix — database name से पहले forward slash अब सही तरीके से handle होता है। अगर आप इसके आसपास काम कर रहे थे, तो आप वह workaround हटा सकते हैं
SQL Server exports — Aspire.Hosting.SqlServer अब finer-grained control के लिए additional server configuration options export करता है
Emulator updates — ServiceBus emulator 2.0.0, App Configuration emulator 1.0.2, और CosmosDB का preview emulator अब readiness check शामिल करता है
Azure Managed Redis — अब default रूप से rediss:// (Redis Secure) है, इसलिए connections out of the box encrypted हैं

वह आखिरी वाला subtle लेकिन important है — default रूप से encrypted Redis का मतलब है production में configure करने के लिए एक कम चीज़।

अंत में

Aspire 13.2 एक incremental release है, लेकिन MongoDB EF Core और Data Lake integrations real gaps भरते हैं। अगर आप Aspire में MongoDB के साथ proper EF Core support का इंतज़ार कर रहे थे, या Data Lake को first-class dependency बनाने की ज़रूरत थी, तो 13.2 पर upgrade करें और इन्हें आज़माएं। aspire add command आपको ज़रूरत की सब कुछ scaffold कर देती है।

अधिक details के लिए full release notes पढ़ें, और पूरी list के लिए integration gallery देखें।

Azure Smart Tier GA हुआ — Lifecycle Rules के बिना स्वचालित Blob Storage लागत अनुकूलन

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

यह पोस्ट स्वचालित रूप से अनुवादित है। मूल के लिए, यहाँ क्लिक करें.

अगर आपने कभी Azure Blob Storage lifecycle policies tune करने में समय बिताया है और फिर देखा है कि access patterns बदलने पर वे ध्वस्त हो जाती हैं, तो यह खबर आपके लिए है। Microsoft ने Azure Blob और Data Lake Storage के लिए smart tier की general availability की घोषणा की — यह एक fully managed tiering capability है जो वास्तविक उपयोग के आधार पर objects को hot, cool, और cold tiers के बीच स्वचालित रूप से ले जाती है।

Smart tier वास्तव में क्या करता है

अवधारणा सीधी है: smart tier आपके storage account में हर object के last access time का लगातार मूल्यांकन करता है। बार-बार access होने वाला data hot में रहता है, 30 दिनों बाद निष्क्रिय data cool में चला जाता है, और फिर 60 दिनों बाद cold में। जब data फिर से access होता है, तो वो तुरंत hot पर वापस आ जाता है। चक्र फिर से शुरू होता है।

Configure करने के लिए कोई lifecycle rules नहीं। Access pattern predictions नहीं। कोई manual tuning नहीं।

Preview के दौरान, Microsoft ने बताया कि smart-tier-managed capacity का 50% से अधिक हिस्सा actual access patterns के आधार पर स्वचालित रूप से cooler tiers में चला गया। बड़े storage accounts के लिए यह एक सार्थक cost reduction है।

.NET developers के लिए यह क्यों मायने रखता है

अगर आप ऐसी applications बना रहे हैं जो logs, telemetry, analytics data, या किसी भी तरह का growing data estate generate करती हैं — और सच में, कौन नहीं बना रहा — तो storage costs तेज़ी से बढ़ती हैं। पारंपरिक approach थी lifecycle management policies लिखना, उन्हें test करना, और फिर जब app के access patterns बदलें तो फिर से tune करना। Smart tier उस पूरे workflow को हटा देता है।

कुछ व्यावहारिक scenarios जहाँ यह मदद करता है:

Application telemetry और logs — debugging के समय hot, कुछ हफ्तों बाद शायद ही access
Data pipelines और ETL outputs — processing के दौरान भारी access, फिर mostly cold
User-generated content — recent uploads hot हैं, पुराना content धीरे-धीरे ठंडा होता है
Backup और archival data — compliance के लिए कभी-कभी access, mostly idle

इसे Setup करना

Smart tier enable करना एक बार का configuration है:

नए accounts: storage account creation के दौरान smart tier को default access tier के रूप में चुनें (zonal redundancy ज़रूरी है)
मौजूदा accounts: अपने current default से blob access tier को smart tier में switch करें

128 KiB से छोटे objects hot में रहते हैं और monitoring fee नहीं लगती। बाकी सब के लिए, आप standard hot/cool/cold capacity rates pay करते हैं बिना tier transition charges, early deletion fees, या data retrieval costs के। Per object एक monthly monitoring fee orchestration को cover करती है।

जो tradeoff जाननी चाहिए

Smart tier के tiering rules static हैं (30 दिन → cool, 90 दिन → cold)। अगर आपको custom thresholds चाहिए — जैसे किसी specific workload के लिए 7 दिनों में cool पर जाना — तो lifecycle rules अभी भी सही तरीका है। और दोनों को mix न करें: smart-tier-managed objects पर lifecycle rules use करने से बचें, क्योंकि वे conflict कर सकते हैं।

निष्कर्ष

यह क्रांतिकारी नहीं है, लेकिन यह एक real operational सिरदर्द हल करता है। अगर आप बढ़ते blob storage accounts manage करते हैं और lifecycle policies maintain करते-करते थक गए हैं, तो smart tier enable करें और Azure को यह handle करने दें। यह आज लगभग सभी zonal public cloud regions में उपलब्ध है।

Azure पर अपने AI Agents को कहाँ Host करें? एक Practical Decision Guide

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

यह पोस्ट स्वचालित रूप से अनुवादित है। मूल के लिए, यहाँ क्लिक करें.

अगर आप अभी .NET के साथ AI agents build कर रहे हैं, तो आपने शायद एक बात notice की होगी: Azure पर उन्हें host करने के बहुत तरीके हैं। Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — और ये सब तब तक reasonable लगते हैं जब तक आपको actually एक चुनना नहीं पड़ता। Microsoft ने हाल ही में Azure AI agent hosting का एक comprehensive guide publish किया है जो इसे clear करता है, और मैं इसे एक practical .NET developer perspective से break down करना चाहता हूँ।

एक नज़र में छह options

यहाँ बताया गया है कि मैं इस landscape को कैसे summarize करूँगा:

Option	सबसे अच्छा	आप manage करते हैं
Container Apps	K8s complexity के बिना full container control	Observability, state, lifecycle
AKS	Enterprise compliance, multi-cluster, custom networking	सब कुछ (यही तो point है)
Azure Functions	Event-driven, short-running agent tasks	ज़्यादा नहीं — true serverless
App Service	Simple HTTP agents, predictable traffic	Deployment, scaling config
Foundry Agents	Code-optional agents via portal/SDK	लगभग कुछ नहीं
Foundry Hosted Agents	Custom framework agents with managed infra	केवल आपका agent code

पहले चार general-purpose compute हैं — आप उन पर agents चला सकते हैं, लेकिन वे इसके लिए design नहीं किए गए। अंतिम दो agent-native हैं: वे conversations, tool calls, और agent lifecycles को first-class concepts के रूप में समझते हैं।

Foundry Hosted Agents — .NET agent developers के लिए sweet spot

यहाँ जो मेरा ध्यान खींचा। Foundry Hosted Agents बीच में sit करते हैं: आपको अपना code चलाने की flexibility मिलती है (Semantic Kernel, Agent Framework, LangGraph — जो भी) लेकिन platform infrastructure, observability, और conversation management handle करता है।

मुख्य piece है Hosting Adapter — एक thin abstraction layer जो आपके agent framework को Foundry platform से bridge करता है। Microsoft Agent Framework के लिए, यह इस तरह दिखता है:

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

यही आपकी पूरी hosting story है। Adapter protocol translation, server-sent events के ज़रिये streaming, conversation history, और OpenTelemetry tracing handle करता है — सब automatically। कोई custom middleware नहीं, कोई manual plumbing नहीं।

Deploy करना genuinely simple है

मैंने पहले Container Apps पर agents deploy किए हैं और यह काम करता है, लेकिन आप state management और observability के लिए काफी glue code लिखते हैं। Hosted Agents और azd के साथ, deployment है:

# AI agent extension install करें
azd ext install azure.ai.agents

# Template से init करें
azd ai agent init

# Build, push, deploy — हो गया
azd up

वह single azd up आपका container build करता है, उसे ACR में push करता है, Foundry project provision करता है, model endpoints deploy करता है, और आपका agent start करता है। पाँच steps एक command में।

Built-in conversation management

यही production में सबसे ज़्यादा समय बचाता है। अपना conversation state store बनाने की बजाय, Hosted Agents इसे natively handle करते हैं:

# एक persistent conversation बनाएं
conversation = openai_client.conversations.create()

# पहला 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.",
)

# दूसरा turn — context preserve होता है
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

कोई Redis नहीं। कोई Cosmos DB session store नहीं। Message serialization के लिए कोई custom middleware नहीं। Platform बस इसे handle कर लेता है।

मेरा decision framework

सभी छह options को देखने के बाद, यह मेरा quick mental model है:

क्या आपको zero infrastructure चाहिए? → Foundry Agents (portal/SDK, no containers)
क्या आपके पास custom agent code है लेकिन managed hosting चाहिए? → Foundry Hosted Agents
क्या आपको event-driven, short-lived agent tasks चाहिए? → Azure Functions
क्या आपको K8s के बिना maximum container control चाहिए? → Container Apps
क्या आपको strict compliance और multi-cluster चाहिए? → AKS
क्या आपके पास predictable traffic वाला simple HTTP agent है? → App Service

Semantic Kernel या Microsoft Agent Framework के साथ build करने वाले ज़्यादातर .NET developers के लिए, Hosted Agents likely सही starting point है। आपको scale-to-zero, built-in OpenTelemetry, conversation management, और framework flexibility मिलती है — Kubernetes manage किए बिना या अपनी observability stack wire up किए बिना।

निष्कर्ष

Azure पर agent hosting landscape तेज़ी से mature हो रहा है। अगर आप आज एक नया AI agent project शुरू कर रहे हैं, तो habit से Container Apps या AKS पर जाने से पहले Foundry Hosted Agents को seriously consider करें। Managed infrastructure real time बचाती है, और hosting adapter pattern आपको अपना framework choice रखने देता है।

Microsoft का पूरा guide और working examples के लिए Foundry Samples repo देखें।

KubeCon Europe 2026: .NET Developers को वास्तव में क्या जानना चाहिए

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

यह पोस्ट स्वचालित रूप से अनुवादित है। मूल के लिए, यहाँ क्लिक करें.

आप उस feeling को जानते हैं जब एक massive announcement post आती है और आप उसे scroll करते हुए सोच रहे होते हैं “cool, लेकिन यह actually मेरे लिए क्या बदलता है”? हर KubeCon season मेरे साथ यही होता है।

Microsoft ने अभी अपना पूरा KubeCon Europe 2026 roundup publish किया — Brendan Burns द्वारा लिखा गया — और सच में? यहाँ real substance है। सिर्फ feature checkboxes नहीं, बल्कि उस तरह के operational improvements जो बदलते हैं कि आप production में चीज़ें कैसे चलाते हैं।

आइए breakdown करें कि हम .NET developers के लिए क्या मायने रखता है।

service mesh overhead के बिना mTLS

Service meshes के बारे में बात यह है: सभी security guarantees चाहते हैं, कोई operational overhead नहीं चाहता। AKS आखिरकार उस gap को बंद कर रहा है।

Azure Kubernetes Application Network आपको mutual TLS, application-aware authorization, और traffic telemetry देता है — बिना full sidecar-heavy mesh deploy किए। Advanced Container Networking Services में Cilium mTLS के साथ combined, आपको X.509 certificates और identity management के लिए SPIRE का उपयोग करके encrypted pod-to-pod communication मिलती है।

व्यवहार में इसका मतलब: आपके ASP.NET Core APIs background workers से बात कर रहे हों, आपके gRPC services एक-दूसरे को call कर रहे हों — सब network level पर encrypted और identity-verified, zero application code changes के साथ। यह बहुत बड़ी बात है।

ingress-nginx से migrate करने वाली teams के लिए, Application Routing with Meshless Istio भी है जिसमें full Kubernetes Gateway API support है। कोई sidecars नहीं। Standards-based। और उन्होंने incremental migration के लिए ingress2gateway tooling ship की।

GPU observability जो afterthought नहीं है

अगर आप अपनी .NET services के साथ AI inference चला रहे हैं (और honestly, कौन शुरू नहीं कर रहा?), तो आपने शायद GPU monitoring blind spot देखा होगा। आपको CPU/memory के लिए बेहतरीन dashboards मिलते थे और फिर… manual exporter plumbing के बिना GPUs के लिए कुछ नहीं।

AKS अब GPU metrics को natively managed Prometheus और Grafana में expose करता है। वही stack, वही dashboards, वही alerting pipeline। कोई custom exporters नहीं, कोई third-party agents नहीं।

Network side पर, उन्होंने HTTP, gRPC, और Kafka traffic के लिए per-flow visibility one-click Azure Monitor experience के साथ जोड़ी। IPs, ports, workloads, flow direction, policy decisions — सब built-in dashboards में।

और यहाँ वह है जिसने मुझे double-take कराया: agentic container networking एक web UI जोड़ता है जहाँ आप अपने cluster की network state के बारे में natural-language questions पूछ सकते हैं। “Pod X service Y तक क्यों नहीं पहुँच रहा?” → live telemetry से read-only diagnostics। रात 2 बजे यह genuinely useful है।

Cross-cluster networking जिसके लिए PhD नहीं चाहिए

Multi-cluster Kubernetes historically एक “अपना networking glue लाओ” experience रहा है। Azure Kubernetes Fleet Manager अब managed Cilium cluster mesh के ज़रिए cross-cluster networking ship करता है:

AKS clusters में unified connectivity
Cross-cluster discovery के लिए global service registry
Configuration centrally managed, हर cluster पर repeat नहीं

अगर आप resilience या compliance के लिए regions में .NET microservices चला रहे हैं, तो यह बहुत सारी fragile custom plumbing की जगह लेता है। West Europe में Service A, East US में Service B को mesh के ज़रिए discover और call कर सकती है, consistent routing और security policies के साथ।

Upgrades जिनके लिए हिम्मत की ज़रूरत नहीं

सच कहें — production में Kubernetes upgrades stressful होते हैं। “Upgrade और उम्मीद करो” बहुत teams के लिए de facto strategy रही है, और यही मुख्य कारण है कि clusters version पर पिछड़ जाते हैं।

दो नई capabilities इसे बदलती हैं:

Blue-green agent pool upgrades नए configuration के साथ एक parallel node pool बनाते हैं। Behavior validate करें, traffic gradually shift करें, और एक clean rollback path रखें। Production nodes पर in-place mutations नहीं।

Agent pool rollback आपको upgrade बिगड़ने के बाद एक node pool को उसके पिछले Kubernetes version और node image पर revert करने देता है — cluster rebuild किए बिना।

साथ में, ये operators को upgrade lifecycle पर real control देते हैं। .NET teams के लिए, यह मायने रखता है क्योंकि platform velocity directly नियंत्रित करती है कि आप नए runtimes, security patches, और networking capabilities कितनी जल्दी adopt कर सकते हैं।

AI workloads Kubernetes के first-class citizens बन रहे हैं

Upstream open-source work equally important है। Dynamic Resource Allocation (DRA) Kubernetes 1.36 में GA हो गया, जो GPU scheduling को एक proper first-class feature बनाता है बजाय workaround के।

कुछ projects जो देखने लायक हैं:

Project	क्या करता है
AI Runway	Inference के लिए common Kubernetes API — K8s जाने बिना models deploy करें, HuggingFace discovery और cost estimates के साथ
HolmesGPT	Cloud-native के लिए agentic troubleshooting — अब CNCF Sandbox project
Dalec	SBOM generation के साथ declarative container image builds — build stage पर कम CVEs

दिशा स्पष्ट है: आपकी .NET API, आपकी Semantic Kernel orchestration layer, और आपके inference workloads सभी एक consistent platform model पर चलने चाहिए। हम वहाँ पहुँच रहे हैं।

इस हफ्ते मैं कहाँ से शुरू करूँगा

अगर आप अपनी team के लिए इन changes का मूल्यांकन कर रहे हैं, तो यहाँ मेरी honest priority list है:

Observability पहले — non-prod cluster में GPU metrics और network flow logs enable करें। देखें आप क्या miss कर रहे थे।
Blue-green upgrades आज़माएं — अपने अगले production cluster upgrade से पहले rollback workflow test करें। Process में confidence बनाएं।
Identity-aware networking pilot करें — एक internal service path चुनें और Cilium के साथ mTLS enable करें। Overhead measure करें (spoiler: यह minimal है)।
Fleet Manager evaluate करें — अगर आप दो से अधिक clusters चलाते हैं, तो cross-cluster networking reduced custom glue में खुद की cost justify कर देता है।

छोटे experiments, fast feedback। यही हमेशा सही move है।

निष्कर्ष

KubeCon announcements overwhelming हो सकती हैं, लेकिन यह batch genuinely AKS पर .NET teams के लिए needle move करती है। Mesh overhead के बिना बेहतर networking security, real GPU observability, safer upgrades, और मज़बूत AI infrastructure foundations।

अगर आप पहले से AKS पर हैं, तो यह आपका operational baseline tight करने का एक बढ़िया मौका है। और अगर आप .NET workloads को Kubernetes पर move करने की planning कर रहे हैं — platform अभी-अभी काफी ज़्यादा production-ready हो गया है।