Aks | The .NET Blog

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 हो गया है।