Back in summer 2010 I called for a notification mechanism within Azure, something that would call customer-defined code to take action when something happen within your subscription, e.g. a file added to blob storage, a message added to a queue, etc. .
Back then I called it an Event Bus, because buses were cool in 2010.
Finally, I got what I wanted in Azure Functions!
What it is
We can see Azure Functions as a micro-execution engine, or micro-compute on demand.
But really, an Azure Function is the Cloud equivalent to a C# event handler. This is pretty powerful.
The model also includes Inputs & Outputs. This integrates into the function code. For instance, in C# inputs are passed as input parameter to the function.
You can hook the function to source control to quickly deploy new versions.
What it brings to the table
Why is this interesting? Can’t you do that today by having a Web Job (or even a Worker Role) monitoring queues, blob storage and all?
Yes, you can. In that sense, Azure Function doesn’t bring new capabilities, it facilitates it.
Instead of having a Web Job containing many handlers for disparate tasks, you have a lightweight, script-like component that react to one trigger.
Azure Functions really are an evolution of Web Jobs. They use the same SDK, hook to the same triggers and… run in the same compute: App Service.
Another great things about Azure Functions is that it comes with the possibility of using a Dynamic App Service Plan. With a Dynamic plan, you pay only for the compute milliseconds (up to 100ms) you use as oppose to standing up instances waiting for triggers to fire. This brings a lot of cost agility to the table, although 10 instances still is the upper limit if many instances are required to run many functions at the same time.
Where to find more
Azure functions bring a new way to create cloud event handlers. It enables elastic computing by having those scripts running only when triggers are activated.