Cloud-Native | The .NET Blog

azd Hooks in Python, TypeScript, and .NET: Stop Fighting Shell Scripts

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

If you’ve ever had a fully .NET project and still found yourself writing Bash scripts just to run azd hooks, you know the pain. Why switch to shell syntax just for a pre-provision step when everything else in your project is C#?

That frustration is now officially solved. The Azure Developer CLI just shipped multi-language hook support, and it’s exactly as good as it sounds.

Hooks, quickly, if you’re not familiar

Hooks are scripts that run at key points in the azd lifecycle — before provisioning, after deployment, and more. They’re defined in azure.yaml and let you inject custom logic without forking the CLI itself.

Previously you were limited to Bash and PowerShell. Now you can use Python, JavaScript, TypeScript, or .NET — and azd handles the rest automatically.

How the detection works

You just point the hook at a file and azd infers the language from the extension:

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

That’s it. No extra config. If the extension is ambiguous, you can add an explicit kind: python (or whatever) to override.

Language-specific details worth knowing

Python

Drop a requirements.txt or pyproject.toml next to your script (or anywhere up the directory tree) and azd creates a virtual environment, installs deps, and runs your script:

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

No virtualenv management on your end. azd walks up from the script location to find the nearest project file.

JavaScript and TypeScript

Same pattern — put a package.json near your script and azd runs npm install first. For TypeScript, it uses npx tsx so there’s no compile step and no tsconfig.json required:

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

Want to use pnpm or yarn? There’s a config.packageManager option for that.

.NET

Two modes here, which is nice:

Project mode: If there’s a .csproj next to the script, azd runs dotnet restore and dotnet build automatically.
Single-file mode: On .NET 10+, you can drop a standalone .cs file and it runs directly via dotnet run script.cs. No project file needed.

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

If you’re already on .NET 10, single-file mode is honestly the cleanest option for simple migration or seeding scripts. No project scaffolding, no .csproj to maintain.

Executor-specific config

Each language supports an optional config block when you need to tweak the defaults:

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

You can also mix formats in the same hooks: block — different languages for different lifecycle events, platform-specific overrides for Windows vs. Linux, whatever you need.

Why this matters for .NET developers

The boring answer is “consistency.” But honestly it goes deeper than that. Hooks are often the last place in an azd-based project that forces you into a different language context. Now your entire deployment pipeline — from app code to infrastructure scripts to lifecycle hooks — can live in one language.

More practically: you can now reuse your existing .NET utilities in hooks. Have a shared class library for database schema management? Just reference it in your hook project. Have a Python data-seeding script you already wrote? Drop it straight into azure.yaml.

Wrapping up

This is one of those changes that sounds small but quietly removes a lot of friction from daily azd workflows. Multi-language hook support is available now — check the official post for the full docs, and head to the azd GitHub repo to try it out on your next project.

Global Azure Spain 2026

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

Global Azure Spain 2026 takes place on April 18, 2026 at Kinépolis Diversia in Alcobendas, Madrid. It’s the largest community-driven Azure event in Spain, bringing together 38 speakers across 3 parallel tracks covering AI agents, Azure networking, Cosmos DB, Fabric, IoT, security, and much more.

The event runs from 08:30 to 18:30 and includes keynote, coffee breaks, lunch, and a closing Q&A session.

Highlights from the agenda

Domando Agentes de IA: governance, tools, and APIs with Azure AI Foundry and 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!: multi-agent systems in action
Foundry Control Plane como plataforma de Agentes global
Rompiendo el perímetro: Zero Trust aplicado en Azure

Tickets

Registration is a symbolic donation — the full ticket price goes directly to Plan International, supporting children’s rights and equality worldwide. Limited capacity, so grab your spot early.

Azure Tour 2026

Beyond Madrid, the Global Azure Tour 2026 also includes stops in Zaragoza, Tenerife, and Sevilla.

Aspire 13.2 Gets MongoDB EF Core and Azure Data Lake — Two Integrations Worth Trying

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

Aspire 13.2 just landed with two new database integrations that are worth your attention: MongoDB Entity Framework Core and Azure Data Lake Storage. If you’ve been wanting to use EF Core with MongoDB in an Aspire app, or need to wire up data lake workloads with proper service discovery, this release delivers both.

MongoDB meets EF Core in Aspire

This is the one I’m most excited about. Aspire has supported MongoDB for a while, but it was always the raw driver — no EF Core, no DbContext, no LINQ queries against your documents. Now you get the full EF Core experience with MongoDB, plus Aspire’s automatic health checks and service discovery.

Setting it up is the typical Aspire pattern. In your AppHost:

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

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

Then in your consuming project, add the EF Core integration:

dotnet add package Aspire.MongoDB.EntityFrameworkCore

And register your DbContext:

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

From there, it’s standard EF Core. Define your entities, use your DbContext like you would with any other provider. The integration handles connection pooling, OpenTelemetry traces, and health checks behind the scenes.

For .NET developers who’ve been using MongoDB with the raw driver and manually wiring up connection strings, this is a nice quality-of-life upgrade. You get the full EF Core abstraction without losing Aspire’s service discovery.

Azure Data Lake Storage joins the party

The second big addition is an Azure Data Lake Storage (ADLS) integration. If you’re building data pipelines, ETL processes, or analytics platforms, you can now wire up Data Lake resources the same way you’d wire up any other Aspire dependency.

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

In the consuming project:

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

No manual connection string management, no credential hunting. Aspire provisions resources and injects them. For those of us building cloud-native .NET apps that touch both operational data and analytics workloads, this makes the data lake feel like a first-class citizen in the Aspire model.

The small fixes that matter

Beyond the headline features, there are a few quality-of-life improvements worth noting:

MongoDB connection string fix — the forward slash before the database name is now handled correctly. If you’ve been working around this, you can remove that workaround
SQL Server exports — Aspire.Hosting.SqlServer now exports additional server configuration options for finer-grained control
Emulator updates — ServiceBus emulator 2.0.0, App Configuration emulator 1.0.2, and CosmosDB’s preview emulator now includes a readiness check
Azure Managed Redis — now defaults to rediss:// (Redis Secure), so connections are encrypted out of the box

That last one is subtle but important — encrypted Redis by default means one less thing to configure in production.

Wrapping up

Aspire 13.2 is an incremental release, but the MongoDB EF Core and Data Lake integrations fill real gaps. If you’ve been waiting for proper EF Core support with MongoDB in Aspire, or needed Data Lake to be a first-class dependency, upgrade to 13.2 and give them a spin. The aspire add command scaffolds everything you need.

Read the full release notes for more details, and check out the integration gallery for the complete list.

Azure Smart Tier Is GA — Automatic Blob Storage Cost Optimization Without Lifecycle Rules

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

If you’ve ever spent time tuning Azure Blob Storage lifecycle policies and then watched them fall apart when access patterns shifted, this one’s for you. Microsoft just announced the general availability of smart tier for Azure Blob and Data Lake Storage — a fully managed tiering capability that automatically moves objects between hot, cool, and cold tiers based on real usage.

What smart tier actually does

The concept is straightforward: smart tier continuously evaluates the last access time of each object in your storage account. Frequently accessed data stays in hot, inactive data moves to cool after 30 days, and then to cold after another 60 days. When data is accessed again, it’s promoted back to hot immediately. The cycle restarts.

No lifecycle rules to configure. No access pattern predictions. No manual tuning.

During the preview, Microsoft reported that over 50% of smart-tier-managed capacity automatically shifted to cooler tiers based on actual access patterns. That’s a meaningful cost reduction for large storage accounts.

Why this matters for .NET developers

If you’re building applications that generate logs, telemetry, analytics data, or any kind of growing data estate — and honestly, who isn’t — storage costs add up fast. The traditional approach was writing lifecycle management policies, testing them, and then re-tuning when your app’s access patterns changed. Smart tier removes that entire workflow.

Some practical scenarios where this helps:

Application telemetry and logs — hot when debugging, rarely accessed after a few weeks
Data pipelines and ETL outputs — accessed heavily during processing, then mostly cold
User-generated content — recent uploads are hot, older content gradually cools
Backup and archival data — accessed occasionally for compliance, mostly idle

Setting it up

Enabling smart tier is a one-time configuration:

New accounts: Select smart tier as the default access tier during storage account creation (zonal redundancy required)
Existing accounts: Switch the blob access tier from your current default to smart tier

Objects smaller than 128 KiB stay in hot and don’t incur the monitoring fee. For everything else, you pay standard hot/cool/cold capacity rates with no tier transition charges, no early deletion fees, and no data retrieval costs. A monthly monitoring fee per object covers the orchestration.

The tradeoff to know about

Smart tier’s tiering rules are static (30 days → cool, 90 days → cold). If you need custom thresholds — say, moving to cool after 7 days for a specific workload — lifecycle rules are still the way to go. And don’t mix both: avoid using lifecycle rules on smart-tier-managed objects, as they can conflict.

Wrapping up

This isn’t revolutionary, but it solves a real operational headache. If you manage growing blob storage accounts and you’re tired of maintaining lifecycle policies, enable smart tier and let Azure handle it. It’s available today in nearly all zonal public cloud regions.

Where Should You Host Your AI Agents on Azure? A Practical Decision Guide

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

If you’re building AI agents with .NET right now, you’ve probably noticed something: there are a lot of ways to host them on Azure. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — and they all sound reasonable until you actually need to pick one. Microsoft just published a comprehensive guide to Azure AI agent hosting that clears this up, and I want to break it down from a practical .NET developer perspective.

The six options at a glance

Here’s how I’d summarize the landscape:

Option	Best for	You manage
Container Apps	Full container control without K8s complexity	Observability, state, lifecycle
AKS	Enterprise compliance, multi-cluster, custom networking	Everything (that’s the point)
Azure Functions	Event-driven, short-running agent tasks	Not much — true serverless
App Service	Simple HTTP agents, predictable traffic	Deployment, scaling config
Foundry Agents	Code-optional agents via portal/SDK	Almost nothing
Foundry Hosted Agents	Custom framework agents with managed infra	Your agent code only

The first four are general-purpose compute — you can run agents on them, but they weren’t designed for it. The last two are agent-native: they understand conversations, tool calls, and agent lifecycles as first-class concepts.

Foundry Hosted Agents — the sweet spot for .NET agent developers

Here’s what caught my attention. Foundry Hosted Agents sit right in the middle: you get the flexibility of running your own code (Semantic Kernel, Agent Framework, LangGraph — whatever) but the platform handles infrastructure, observability, and conversation management.

The key piece is the Hosting Adapter — a thin abstraction layer that bridges your agent framework to the Foundry platform. For Microsoft Agent Framework, it looks like this:

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

That’s your entire hosting story. The adapter handles protocol translation, streaming via server-sent events, conversation history, and OpenTelemetry tracing — all automatically. No custom middleware, no manual plumbing.

Deploying is genuinely simple

I’ve deployed agents to Container Apps before and it works, but you end up writing a lot of glue code for state management and observability. With Hosted Agents and azd, the deployment is:

# 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

That single azd up builds your container, pushes it to ACR, provisions the Foundry project, deploys model endpoints, and starts your agent. Five steps collapsed into one command.

Built-in conversation management

This is the part that saves the most time in production. Instead of building your own conversation state store, Hosted Agents handle it natively:

# 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 Cosmos DB session store. No custom middleware for message serialization. The platform just handles it.

My decision framework

After going through all six options, here’s my quick mental model:

Do you need zero infrastructure? → Foundry Agents (portal/SDK, no containers)
Do you have custom agent code but want managed hosting? → Foundry Hosted Agents
Do you need event-driven, short-lived agent tasks? → Azure Functions
Do you need maximum container control without K8s? → Container Apps
Do you need strict compliance and multi-cluster? → AKS
Do you have a simple HTTP agent with predictable traffic? → App Service

For most .NET developers building with Semantic Kernel or Microsoft Agent Framework, Hosted Agents is likely the right starting point. You get scale-to-zero, built-in OpenTelemetry, conversation management, and framework flexibility — without managing Kubernetes or wiring up your own observability stack.

Wrapping up

The agent hosting landscape on Azure is maturing fast. If you’re starting a new AI agent project today, I’d seriously consider Foundry Hosted Agents before reaching for Container Apps or AKS out of habit. The managed infrastructure saves real time, and the hosting adapter pattern lets you keep your framework choice.

Check out the full guide from Microsoft and the Foundry Samples repo for working examples.

KubeCon Europe 2026: What .NET Developers Should Actually Care About

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

You know that feeling when a massive announcement post drops and you’re scrolling through it thinking “cool, but what does this actually change for me”? That’s me every KubeCon season.

Microsoft just published their full KubeCon Europe 2026 roundup — written by Brendan Burns himself — and honestly? There’s real substance here. Not just feature checkboxes, but the kind of operational improvements that change how you run things in production.

Let me break down what actually matters for us .NET developers.

mTLS without the service mesh tax

Here’s the thing about service meshes: everyone wants the security guarantees, nobody wants the operational overhead. AKS is finally closing that gap.

Azure Kubernetes Application Network gives you mutual TLS, application-aware authorization, and traffic telemetry — without deploying a full sidecar-heavy mesh. Combined with Cilium mTLS in Advanced Container Networking Services, you get encrypted pod-to-pod communication using X.509 certificates and SPIRE for identity management.

What this means in practice: your ASP.NET Core APIs talking to background workers, your gRPC services calling each other — all encrypted and identity-verified at the network level, with zero application code changes. That’s huge.

For teams migrating off ingress-nginx, there’s also Application Routing with Meshless Istio with full Kubernetes Gateway API support. No sidecars. Standards-based. And they shipped ingress2gateway tooling for incremental migration.

GPU observability that’s not an afterthought

If you’re running AI inference alongside your .NET services (and let’s be honest, who isn’t starting to?), you’ve probably hit the GPU monitoring blind spot. You’d get great CPU/memory dashboards and then… nothing for GPUs without manual exporter plumbing.

AKS now surfaces GPU metrics natively into managed Prometheus and Grafana. Same stack, same dashboards, same alerting pipeline. No custom exporters, no third-party agents.

On the network side, they added per-flow visibility for HTTP, gRPC, and Kafka traffic with a one-click Azure Monitor experience. IPs, ports, workloads, flow direction, policy decisions — all in built-in dashboards.

And here’s the one that made me do a double-take: agentic container networking adds a web UI where you can ask natural-language questions about your cluster’s network state. “Why is pod X not reaching service Y?” → read-only diagnostics from live telemetry. That’s genuinely useful at 2 AM.

Cross-cluster networking that doesn’t require a PhD

Multi-cluster Kubernetes has historically been a “bring your own networking glue” experience. Azure Kubernetes Fleet Manager now ships cross-cluster networking through managed Cilium cluster mesh:

Unified connectivity across AKS clusters
Global service registry for cross-cluster discovery
Configuration managed centrally, not repeated per cluster

If you’re running .NET microservices across regions for resilience or compliance, this replaces a lot of fragile custom plumbing. Service A in West Europe can discover and call Service B in East US through the mesh, with consistent routing and security policies.

Upgrades that don’t require courage

Let’s be honest — Kubernetes upgrades in production are stressful. “Upgrade and hope” has been the de facto strategy for too many teams, and it’s the main reason clusters fall behind on versions.

Two new capabilities change this:

Blue-green agent pool upgrades create a parallel node pool with the new configuration. Validate behavior, shift traffic gradually, and keep a clean rollback path. No more in-place mutations on production nodes.

Agent pool rollback lets you revert a node pool to its previous Kubernetes version and node image after an upgrade goes sideways — without rebuilding the cluster.

Together, these finally give operators real control over the upgrade lifecycle. For .NET teams, this matters because platform velocity directly controls how fast you can adopt new runtimes, security patches, and networking capabilities.

AI workloads are becoming first-class Kubernetes citizens

The upstream open-source work is equally important. Dynamic Resource Allocation (DRA) just went GA in Kubernetes 1.36, making GPU scheduling a proper first-class feature instead of a workaround.

A few projects worth watching:

Project	What it does
AI Runway	Common Kubernetes API for inference — deploy models without knowing K8s, with HuggingFace discovery and cost estimates
HolmesGPT	Agentic troubleshooting for cloud-native — now a CNCF Sandbox project
Dalec	Declarative container image builds with SBOM generation — fewer CVEs at the build stage

The direction is clear: your .NET API, your Semantic Kernel orchestration layer, and your inference workloads should all run on one consistent platform model. We’re getting there.

Where I’d start this week

If you’re evaluating these changes for your team, here’s my honest priority list:

Observability first — enable GPU metrics and network flow logs in a non-prod cluster. See what you’ve been missing.
Try blue-green upgrades — test the rollback workflow before your next production cluster upgrade. Build confidence in the process.
Pilot identity-aware networking — pick one internal service path and enable mTLS with Cilium. Measure the overhead (spoiler: it’s minimal).
Evaluate Fleet Manager — if you run more than two clusters, cross-cluster networking pays for itself in reduced custom glue.

Small experiments, fast feedback. That’s always the move.

Wrapping up

KubeCon announcements can be overwhelming, but this batch genuinely moves the needle for .NET teams on AKS. Better networking security without mesh overhead, real GPU observability, safer upgrades, and stronger AI infrastructure foundations.

If you’re already on AKS, this is a great moment to tighten your operational baseline. And if you’re planning to move .NET workloads to Kubernetes — the platform just got significantly more production-ready.