Consider this scenario: you have a certain function you want to host on Azure. This function is triggered using an event – for example upon the arrival of new sensor reading from an IoT device, or upon receiving a new message into a Service Bus Topic. You want this function to be executed without having to worry about the underlying infrastructure (compute, memory, storage). Upon completion the resources used to execute this function are now free to be used by other computations, and you pay only for the resources used by the function.

This is what Azure Functions provides.

But wait, isn’t that the whole idea of PaaS – where Azure App Services belong in the first place?

Well, no! Let’s revise this: PaaS relieves us from managing the underlying infrastructure, but it does not relieve us from thinking about scaling. So say we’re hosting a web application or web api using Web Apps or API Apps. The web application or api is sitting there active waiting for new requests. During planning we still need to figure out sizing and say for example that we need to 4 instances to run our application. Later we might scale up or out based on the load we monitor. Your payment depends on the number of instances you have consumed (pay-per-use model). That’s PaaS.

There is another concept – mostly called Function As A Service (FaaS) – that takes away the burden of thinking about sizing and scaling. It is a higher level abstraction from PaaS and truly abstracts away every resource management concern. With FaaS, the compute function is NOT active consuming resources while waiting to be invoked. Instead it is triggered only by a certain trigger and only then the required event happens, the required resources (compute, memory, storage) are allocated dynamically and scaling happens also automatically based on processing requirements. The function lives for few milliseconds, and upon completion the resources are released. You then pay based on the resources consumed only while processing the function (pay-per-execution model). Azure Functions is a FaaS implementation. Another examples are Amazon Lambda and Google Cloud Functions.

This model of computing is also called Serverless computing. The name does indicate there is no servers or that compute does not happen on servers; rather as I explained, it means that you do not manage servers yourself (that obviously an oversimplification – read this for more details about Serverless computing: http://martinfowler.com/articles/serverless.html )

Logic Apps vs. Azure Functions

What is the difference between Logic Apps which we saw before, and Azure Functions? They seem to perform the same kind of work.

Well to start with, we already established that Logic Apps are a PaaS offering, while Azure Functions are a FaaS offering – or using the more common terminology they are a form of serverless computing.

From a functional perspective however, Logic Apps are about building orchestrations that could get fairly complex – with concerns such as transactions and reliability (retries).

Azure Functions are meant to be used to create lightweight functionality (some call this nanoservices – things that are even lighter than microservices; but let’s keep this discussion away for a moment) that runs for milliseconds.

Demo

Let’s create a simple Function App to get a sense of it.

Note: till this time of writing there is no complete tooling support for Function Apps from Visual Studio. Therefore I will use the portal to create an app.

First locate the Function App in the Azure portal:

You will then supply the configuration for a new Function App:

Few important things to note:

In the App Service plan you can select either Classic or Dynamic.

• The Dynamic plan models what I explained before: nothing is reserved for the Function App; everything is allocated dynamically and you pay only for the execution time. The Memory Allocation option then allows us to select the amount of memory to reserve while the Function App is running. Note though that the allocated memory is per the entire Function App, which may include multiple functions as we’ll see in a moment.
• In the Classic plan, the underlying resources where the Function App runs remain reserved. This means that just like any App Services PaaS offering (such as the Web Apps and API Apps), we need to specify the resources of our Function App. So why exactly would we select this plan? Doesn’t this negate the complete idea of Serverless computing? Well, yes but there is a scenario where this plan makes sense: when we select the Classic plan we can then run our Function App on an existing App Service plan which might include other App Services such as Web App or API App. This means that if you have reserved resources for these apps that are not being used, then these resources could be used for the Function App. This way you do not pay extra for a Dynamic plan and instead completely utilize what you have already reserved.

Finally, the storage account is used for diagnostics and status.

Now within the Function App created we can create multiple functions:

When you select New Function, you will be presented with a variety of templates to start with. Select for example HttpTrigger-C# to create a function that is triggered upon receiving an Http request:

Supply the name for your function and for simplicity select Anonymous access:

Once you create the function, you will get a set of options to code, setup, and configure your function. For example below you see the Function Url which will be exposed to accept Http requests (remember this function is triggered via Http requests). And of course you see the code of the function – the portal provides an editor for this!

There is also a section which allows you to provide input and test run the function:

Play around with the code of the function – which as you see in this case just echoes an input string. Once you’re done click the Save button, and of course you can test it via the Run section as above. Then you can trigger this function via the URL you saw at the beginning.

Obviously there are a lot more options as you can see from the portal, play around with these to discover the feature set of Azure Functions.