Azure Functions is the Microsoft’s way of providing a Serverless computing platform for developers allowing them to quickly create solutions buy just writing the code you need for the problem at hand without the need to think about the infrastructure that the application needs to run on. At the heart of Azure Functions, you find the idea of Code and Events. Code is the component that you as a developer supplies as a solution for the problem at hand and a function that can be written in C#, F#, Node.js etc. Then you can tell what Event should trigger that code. Azure Functions does the rest. Azure Functions is a fantastic solution for Integrating Systems, Data Processing, Microservices, IoT Solutions and for Simple APIs.

You write small prices of code “Functions” and run these in the cloud. This makes it much more easy and productive to provide solutions, especially when you don’t need to worry about creating the infrastructure necessary to run the code, worry about scaling the solutions since Azure Functions takes care of scaling as and when its needed. But for me one of the most important things is the cost, you only pay for the time your code is running and no more. This allows us to develop solutions in fractions of the cost, compared it with let’s say an application running on a Virtual Machine on Azure.

If you think about it, Azure Functions allows us to run our Code as a response to an Event trigger, but we can achieve the same thing with the current offerings that Azure provides such as Cloud Services, Azure Web App and Web Jobs. So, the question arises,

Why Do We Need Azure Functions?

Let’s start from the beginning. One of the first solutions we had to deploy out applications in the cloud is the Azure Virtual Machines, an Infrastructure as a Service (IaaS) offering where we provision Virtual Machines, install whatever we need on them and deploy our applications. Even though this approach provides us a lot of control over the aspects of the application and the environment itself, it comes with the disadvantage of the hassle of maintaining the Virtual Machines and scaling.

Then came Azure Cloud Services a Platform as a Service (PaaS) offering, where there was Web Roles for your web applications and APIs and Worker Roles for your background tasks. Removing the hassle of maintaining and scaling to Azure. This was much easier to work with than Virtual Machines but provides less control over the OS the application was running on.

Then the newer Azure Web Applications and Web Jobs came along as a part of Azure App Services which was another PaaS offering. Web Applications was the replacement for the Web Roles in Cloud Services (a much better option to Web Roles I might add) and the Web Job was an alternative for Worker Roles. Actually, Web Jobs was the stepping stone for Azure Functions and Azure Functions are built on top of the Azure Web Job SDK.

Looking at all 3 offerings they all have a certain bit of overhead when creating application. For example, take a scenario where you need to respond to a message that was put on a Queue and do some processing. In all the above offerings, you need to write a considerable amount of code to lay the foundation for your actually work to be done. The actual work is Do some processing when a message is put in to a queue, but in order to do that you need to write the code to handle the operations with the queue to read the message etc. Which was sometimes painful, boring and takes the focus away from the actual business requirement.

Azure Functions provide a more Simplified Programming Model where you need only to write the code to respond to the event (In our case respond to the message placed on the queue after some processing). This removed the boilerplate code we need to write in order to connect to the events, get everything setup and lets us focus on the Business Requirement instead.

Azure Functions also provide a New Pricing Model you pay only for what you use and no more. In all 3 previous Azure offerings, you need to have at least one instance running all the time and you need to pay for that. But with Azure Functions you have a pay as you go approach. Where you only pay for what resources you use. Let’s take the example we talked about with respect to Azure Functions. When we are looking at a queue until a message pops up on the queue, if we are using Azure Functions, if a message does not come, we don’t pay. But in Cloud Services or Web Jobs, we need to pay because those offerings are consuming resources even if they are not doing any work at all.

Features of Azure Functions

Azure Functions provide numerous feature for developers that stands out from the other offerings that developers can use to create solutions.

Pay Per Use Pricing Model

Pay Per Use Pricing Model allows you to pay only for the time you ran your code. However, you have 2 options when it comes to pricing.

First option is Consumption Plan, which fall in to the Pay as You Go category of things. You only pay for what you use and Azure takes care of providing all the computational resources for you. The Consumption billing model has 2 metrics when it measures resource usage. First one is the Number of Executions which means the number of times your functions execute. And the second one is CPU Time x RAM Usage, where CPU time (measured in seconds) your functions run is multiplied with the Amount of RAM (measured in Giga Bytes) your functions use. This unit is called Giga Byte Seconds (Gb-s) This approach provides you with enough free monthly grant to get you started. The free monthly grant provides 1 Million Executions and 400000 Gb-s for your use.

However, in the Consumption Plan your function execution is limited to 5 minutes per execution. After that the execution will end. But you can also set daily quota in Giga Byte Seconds (GBs) to limit over spending on this Pricing model.

The second option is the use of already existing App Service Plans. You can use App Service Plans as your Azure Function pricing model if you want a dedicated pricing model for Azure Functions, this will allow you to have a predictable monthly cost for your Functions and especially if you are already using some powerful Virtual Machines as a part of you App Service Plan, you can use that plan without additional cost. So, your Azure Functions will run like your normal Web, Mobile and API apps with a predictable pricing plan.

Multiple Supported Languages

Azure Functions support multiple languages for developers to write functions as well as batch, bash and executable files. You can use C#, F#, Node.js Python and PHP to write Azure Functions and have them executed using a variety of Events.

Support for Dependency Packages

Azure Functions support NuGet and NPM packages so you can bring in any external library you want to use in your Azure Functions to provide solutions for your business requirements.

Support for Integrations with Other Offerings

Azure Functions support integrating with a number of Azure Offerings and SaaS offerings. For example, you can use Azure DocumentDB, Azure Event Hubs, Azure Mobile Apps, Azure Notifications Hubs, Azure Service Bus Queues and Topics, Azure Storage Queues, Blobs and Tables and even integrate with no Azure offerings like GitHub using webhooks and Twilio SMS messaging services.

Integrated Security

Azure Functions support OAuth providers such as Azure Active Directory, Facebook, Google, Twitter and Microsoft Accounts to protect your HTTP triggered functions so you can provide security for your Functions.

Flexible Development & Deployments

You can use the portal to code your Azure Functions and deploy them directly or you can develop them away from the portal and setup Continuous Integration and deploy your code using Visual Studio Team Service, GitHub or directly from your Visual Studio IDE, Eclipse and IntelliJ IDEs or automated deployments using Command line tools.

 

Types of Triggers for Azure Functions

There are several types of triggers that you can use to start the execution of Azure Functions. But only one type of trigger is supported for each function. Meaning you cannot trigger a single Azure Function by using multiple types of triggers.

HTTP Triggers

HTTP triggers will execute your function as a response to a HTTP Request. You have the flexibility to configure HTTP Triggers to respond to only a specific HTTP method or for all HTTP methods. A HTTP Trigger will respond to the request with an HTTP OK 200 status code by default.

There are 2 types of HTTP Triggers, Standard and Webhook. A Webhook trigger expects a JSON payload where the Standard HTTP Trigger does not expect a particular type of payload. Also, webhook trigger can be tailored to a specific webhook provider (GitHub and Slack is supported as of now) where provider’s validation logic is executed by Azure Function Runtime.

Timer Triggers

A Timer Trigger will trigger a Function on a schedule defined using a CORN Expression. By default, the CORN Expression uses Coordinated Universal Time (UTC) but you have the option to configure the time zone to any time zone you like using an App Settings on the Function App.

Storage Blob Trigger

A Storage Blob Trigger allows you to monitor a storage container on an Azure Storage Account and when blob in that storage container is updated or a new blob is added the function gets triggered.

Storage Queue Trigger

A Storage Queue Trigger allows you to monitor a storage queue for new messages and react to those messages.

Event Hub Trigger

This will respond to events delivered to an Azure Event Hub event stream. Read access to the event hub is required to set up the trigger. When the event hub is triggered the message that triggered the event hub event stream is passed into the function as a string. This is useful in IoT Scenarios, Application Instrumentation, workflow processing etc.

Service Bus Triggers

The Service Bus triggers respond to messages from Service Bus Queue or Topic.

Azure Functions provides a great set of features for developers who are willing to go the Serverless architecture. It’s a great option to do experimenting and prototyping for applications, as an extension for an existing application to add functionality and it’s great for integrating with different systems fast and easily. We will talk about how to create Azure Functions and its uses in the upcoming articles. I’ll see you in the next one.

Azure Functions: Going Serverless on Azure Platform -  All Articles

• Going Serverless on Azure Platform - #1 Introduction (This Article)
• Going Serverless on Azure Platform - #2 Creating a Function App in the Azure Portal
• Going Serverless on Azure Platform - #3.1 Creating a Function Pipeline Using the Azure Portal – Part I
• Going Serverless on Azure Platform - #3.2 Creating a Function Pipeline Using the Azure Portal – Part II