Azure Functions Explained With a Simple Example

Azure Functions confuses people mostly because of the term "serverless," which sounds like there's no server involved at all. There is a server, you just never have to think about it. Here's what that actually means with a real example.

The basic idea

An Azure Function is a small piece of code that runs in response to something happening, and then stops. No server sits running and idle waiting for you. Instead, Azure spins up the resources needed only when your function is triggered, runs your code, and then shuts back down. You're billed based on how often it runs and how long it takes, not for keeping a server on around the clock.

This is the opposite of a virtual machine or a typical web app, which runs continuously whether it's doing anything or not. Functions are built for work that happens occasionally or in response to specific events, not for something that needs to be constantly available and running.

A simple example

Say you have a folder in Azure storage where invoices get uploaded. You want every new invoice automatically converted to a standard format and emailed to your finance team. Instead of running a server all day just waiting to notice a new file, you write an Azure Function with a trigger tied to that storage folder. The moment a new file lands there, the function wakes up, runs your code to convert and send the file, and then goes back to doing nothing until the next upload.

You never manage a server for this. You write the code, set the trigger, and Azure handles when and how it runs. If ten invoices arrive at once, Azure can run multiple instances of your function in parallel automatically, without you configuring anything extra for that.

What triggers can be

Triggers aren't limited to file uploads. A function can run on a schedule, like every night at 2am, in response to an HTTP request, essentially acting as a small API endpoint, or in response to a message landing in a queue, which is common for connecting different systems together without them needing to talk to each other directly.

When it's the right tool

Functions are great for small, event driven jobs: processing a file, sending a notification, running a scheduled cleanup task, or connecting two systems together. They're the wrong tool if you need something running continuously with consistent low latency, or if your workload is genuinely large and steady rather than occasional and event driven. For the right kind of small, triggered job, though, they're one of the simplest and cheapest ways to get something built in Azure without managing any infrastructure yourself.