Azure Functions are built for short, reactive tasks triggered by external events. Functions only cost money when they run. For workflows that spike or barely show up, this keeps spend tight without constant tuning. If you’re using .NET, the execution model matters. By 2026, the in-process model is deprecated. Isolated Functions are the only viable path forward - with more control, more setup, and fewer surprises. This article breaks down what Azure Functions are, where they make sense, and what the .NET shift means for long-term architecture.
What are Azure Functions
Azure Functions is a serverless platform where your code runs only in response to events and uses temporary compute resources with no need to manage servers.
Serverless, Platform as a Service (PaaS), Event-Driven
Azure Functions don’t run until something triggers them. You don’t keep a server warm or pay for idle time. The function runs when an event occurs - then it stops.
It’s not IaaS, you never touch the host. It fits the PaaS bucket - this is compute built for short, reactive tasks - not background daemons or long-lived workflows.
Common use: file processing, API endpoints, scheduled jobs, automation tasks that don’t need to persist. Wrong use: long-running services, real-time guarantees at scale, anything with state or custom runtimes.
You don’t define scaling rules. Azure monitors demand and scales out as needed. But that flexibility comes with tradeoffs — cold start is real on the consumption plan. If your workload needs sub-second startup every time, you’ll need premium pricing for always-ready instances.
It works best when the workload is unpredictable, lightweight, and stateless. If it runs every few minutes or waits on external input, this is the right fit. If it needs to respond in milliseconds at all hours, it’s not.
Common Triggers & Bindings
An Azure Function only runs when something triggers it. Always one trigger, no exceptions. If there’s no trigger, there’s no execution.
Triggers map to events: an HTTP call, a file upload, a queue message, a scheduled time. You choose the one that matches what you’re reacting to. And when it fires, it brings some data with it - the request body, the blob contents, the queue payload - so your function has what it needs from the start.
Bindings take care of the rest. Instead of writing code to fetch data or push results to storage, you declare it. You say “this output goes to a queue,” or “read from this blob.” Azure wires that up. You don’t write SDK calls unless you want to - and if you are, it probably means you missed a binding that could’ve done the job faster.
.NET Azure Functions (In-Process vs. Isolated Worker)
.NET Azure Functions are Azure Functions written in .NET languages like C# or F#. They refer specifically to functions built with .NET, separate from JavaScript, Python, or other supported languages.
.NET Azure Functions come in two execution models. One is heading for deprecation. The other is the only viable future.
The in-process model runs your function code inside Azure’s function runtime. That was fine when the only goal was minimal setup and fast startup. But it locked your code to Microsoft’s .NET version and after November 2026, you inherit the problem of maintaining a model that no longer gets support.
The isolated model separates your function from Azure’s runtime entirely. It launches in its own process. That means you pick the .NET version - 8, 9, even .NET Framework if you really must - and you control startup, dependency injection, and middleware like you would in a regular ASP.NET Core app. You write your Program.cs, build your service container, and decide what gets injected.
It matches modern .NET development, scales better with complexity, and avoids version friction when Azure updates its own platform internals.
Isolated is the only model that supports long-term architecture. Every new .NET Function project should start here. And every old one in-process is a migration waiting to happen.
Recommended posts
Portfolio
Our Clients' Feedback













We have been working for over 10 years and they have become our long-term technology partner. Any software development, programming, or design needs we have had, Belitsoft company has always been able to handle this for us.
Founder from ZensAI (Microsoft)/ formerly Elearningforce