This entry is meant as a “getting started” entry with pointers to documentation and general discussion. We’ll dive deeper in future articles.
What is serverless computing?
It doesn’t mean, as this blog’s introduction image suggests, that our code runs in æther. Code still runs on servers at the end of the day.
In general, serverless refers to an economical model where we pay for compute resources used as opposed to “servers”.
Wait… isn’t that what the Cloud is about?
Well, yes, on a macro-scale it is, but serverless brings it to a micro-scale.
In the cloud we can provision a VM, for example, run it for 3 hours and pay for 3 hours. But we can’t pay for 5 seconds of compute on a VM because it won’t have time to boot.
A lot of compute services have a “server-full” model. In Azure, for instance, a Web App comes in number of instances. Each instance has a VM associated to it. We do not manage that VM but we pay for its compute regardless of the number of requests it processes.
In a serverless model, we pay for micro-transactions.
Serverless in Azure
Azure Functions are at the center of serverless discussion in Azure, but they aren’t the only serverless service by any stretch.
The online documentation does a thorough comparison between Azure Functions, Flow, Logic Apps & WebJobs.
Other services are also serverless. Here is a non-comprehensive list:
- DataLake Analytics: Big Data as a Service
- Azure Storage: pay-per-query service
- Azure Automation: pay-per-runbook-run service
- Data Factory: Data integration service
- Traffic Manager
- Azure DNS
We can learn about Azure Function with the online documentation.
As a quick aside, although Azure Function is the poster kid for serverless in Azure, it is also possible to have dedicated compute to run Azure Functions. Serverless works with “consumption” App Service Plans, where we pay for micro transactions, while dedicated works with traditional App Service Plan.
At the time of this writing (end of November 2017), Azure Functions fully support the following language:
The following languages aren’t Generally Available (GA) but can be used with Azure Functions:
- Batch (.cmd, .bat)
All those language are supported in a scripting capacity. C# & Java can now be used in a compiled mode where entire packages can easily be deployed to Azure Functions using development tools: Visual Studio for C# & Maven for Java.
Both Windows and Linux can host the platform in Azure. It is also Open Sourced on GitHub and can be deployed on premise (it is also available on Azure Stack).
Functions are triggered by events: HTTP request, Schedule (timer), Blob added to a Blob container, Message arrived to an Azure queue / Service Bus queue / Topic, third party webhook, etc. .
A strength of Functions is their bindings. Not only can an event trigger a function, but the runtime takes care of the connectivity with the event’s service. For instance, when a is added to a blob container, it triggers a function using a blob-binding which means the function directly has access to the blob without using the Azure Storage SDK. This makes Azure Functions free of a lot of plumbing that plague integration solutions.
Binding can be in input as we just discussed, but they can also be in output. A function could react to a blob being added by sending a message to a Service Bus topic. The topic would be accessed using binding, again freeing the function’s code from dealing with the details of Service Bus SDK.
Where to use
Now that we discussed some general aspects of Azure Functions, let’s discuss where they are a good fit.
Event based programming
An obvious sweet spot is event processing.
Typical event processing implementation have 2 agent instances monitoring a queue to process messages.
That approach has two weaknesses:
- When we process few messages, our solution isn’t efficient economically since our agents (e.g. VMs) are sitting incurring while doing little work.
- If we have a spike of messages higher than our agents can process, we will need to wait for the agents to process them.
Azure Functions address both of those weakness:
- If there are no messages to process, there are no costs
- When a surge of messages will come, Azure Functions will provision multiple resources to handle the load
Azure Functions scale naturally.
A solution often contain little bits of logic ran either seldomly or on schedule ; e.g. periodically clean-up this data, poke that service for news, etc. . We often do not know where to put that logic, especially when we take High Availability into account. Ever considered how to implement a scheduler that needs to run at 12:00 when you have a cluster of 2 VMs (with no guarantee that either of them is up, but that the cluster is up with %99.95 SLA)?
Azure Functions is a great solution for those bits of logics.
Azure Functions is great at integrating with Azure native services but also external services.
As a part of Logic Apps
Azure Functions are a key serverless offering in Azure and a strong integration platform.
Its economical model (micro pay-per-use) makes it an appealing service for scalable solution.