Fundamentals

Overview

Azure Functions is one of the latest additions to the Azure App Service family, which offers developers a simplified programming model.

To develop Azure functions, all we must do is write code that responds to the event we’re interested in, whether that’s an HTTP request or a queue message. All the code we will write connects these events to the code that handles them and is abstracted away from us (handled by the framework).

As we’ll see shortly, this provides a very lightweight development platform that is particularly suited for a fast style of development where you just focus on the code that meets your business requirements, eliminating a lot of overhead.

Another great benefit of Azure Functions compared to Virtual Machines or Web Applications is that there is no need to have at least one dedicated server running constantly. Instead, you only pay when your function runs. If your function is listening on a queue and no messages ever arrive, you won’t have to pay anything. Isn’t that great?

Azure Functions will automatically scale the number of servers running your functions to meet demand. If there’s no demand, then there might be no servers running your code. However, the framework can spin one up very quickly when required.

As a result, the pay-as-you-go pricing model can result in dramatic cost savings.

Serverless overview

Microsoft is increasingly using the term “serverless” in their marketing efforts for services like Azure Functions. The term has caught on over the last couple of years, and you can find many cloud vendors using it.

In one sense, this term isn’t truly accurate—there are, of course, servers required to run the Azure Functions framework and the code that runs on it. However, one of the key ideas behind serverless is that you basically delegate the overall management and maintenance of your servers to a third-party provider—in this case, Microsoft Azure—so that you can focus purely on business requirements.

In a typical serverless architecture, you would choose to rely on a third-party platform or back-end service—for instance, by using Azure Cosmos DB as your NoSQL cloud database—instead of creating your own virtual machine and installing a database server on it.

The great thing about serverless architecture is that there is a growing number of third-party services that meet many of the common needs of modern cloud applications, whether it’s logging, sending emails, performing full-text search of documents, or accepting online payments.

These third-party services cannot do everything on their own, so there will be a need to write some of your own back-end code. This is where services like Azure Functions fit nicely into serverless.

Instead of provisioning a whole server to run a website or host some background processes, you simply tell Azure Functions which events you need to respond to and what you want to do when those events are triggered, and then you let the framework worry about how many servers you need. This lightweight model is also referred to as function as a service (FaaS).

It’s important to note that on its own, Azure Functions isn’t a serverless framework, but it fulfills the FaaS part of serverless. Therefore, it can be used in conjunction with other cloud offerings and services to create a full serverless architecture.

Let’s consider a very simple real-world example.

Real-world example

Some time ago, I needed to create a relatively simple website to sell a software utility I’d made, which was called Pluglock.

The whole idea behind this tool was that it would use your laptop power cable as a security device. If the utility was running in secure mode and the power cable was unplugged, the tool would sound an alarm, block the volume, lock the session, and prevent anyone except the authorized Windows user from logging back in. After the authorized user logged back in, the computer would be restored to a “safe” state, turn off the alarm, and let the user work again.

I created the tool for myself, as I used to travel quite a bit and found it annoying that every time I was in an airport and needed to run to the toilet, I had to pack my laptop and take it with me. So I thought to myself, why not create a tool that could protect my laptop while I went to the toilet, leaving it plugged in?

Imagine what a surprise someone with thoughts of unplugging my laptop would run into and be exposed to the eyes of everyone else, alerted by an alarm at full volume—not a pleasant scene for that person!

The website was simply static HTML, and it had a Buy button that integrated with a payment provider (which isn’t that complicated, technically speaking).

However, I also needed to handle the webhook callback from the payment provider whenever someone bought the tool. So, what I did was add a web method API to my server to handle that, which needed to generate a license file and send an email in order to provide that information to the customer.

This required the web server to post messages to queues. Then, I needed to add code that would listen to these queues, which ended up on the web server as well. This resulted in more and more code being added to the web server.

Furthermore, the tool also allowed the user to opt-in and report certain things, such as location and tracking information (IP address, latitude, and longitude). This called a webhook, and it also needed to check whether the license was valid.

Finally, a process that ran overnight would summarize all the activity and send a detailed report via email to me.

So what started out to be a very simple website with a Buy button had grown into a full-blown back-end web application with a lot of responsibilities.

There was a point in time when I was thinking of moving from static HTML to something like WordPress, which would make the editing of the website content easier. However, it was soon clear that it wasn’t possible to migrate it to WordPress because there was already so much back-end .NET code that it would require a complete rewrite in PHP, just so WordPress would be able to support the same functionality I had developed.

This type of scenario probably sounds very familiar to many developers out there—you end up with one server doing everything as a monolith, which is incredibly hard to scale.

The figure that follows represents the process I have just described.

Figure 1-a: Monolithic Architecture

How Azure Functions can help us

In the real-world example I just described, we witnessed what is known as a monolithic architecture—which obviously doesn’t scale well at all.

Let’s see how a serverless architecture and Azure Functions could help us. What we can do is break up some or most of the parts of our monolithic architecture into smaller bits.

Let’s say the webhook for new purchases is going to be handled by an Azure function that posts a message into a queue, and then that message is handled by another function that generates the license file and puts it into a blob.

That blob then creates triggers for another Azure function that emails the license to the customer. As you might have guessed, the reporting webhook is another Azure function that writes a row into Azure Table storage.

The license validation API is another Azure function that performs a database lookup, as well as the nightly process that produces a report.

We still have our web server, which could even be replaced with some static content hosted in blob storage. However, what we’ve managed to do is decompose our monolithic architecture into a set of loosely coupled functions, which you could even think of as nanoservices.

These functions could be wrapped up nicely into a single Azure Functions app, given that they belong together and share configuration settings and local resources.

Here’s how our monolithic architecture would look using Azure Functions instead.

Figure 1-b: Serverless Architecture Using Azure Functions

As you can see, this is much easier to scale than the monolith we previously described, given that each of the steps in the process is a self-contained Azure Function.

Typical use cases

Now that we’ve seen how using Azure Functions can simplify an app’s architecture, what sort of applications are Azure Functions and serverless good for?

Azure Functions is not necessarily right for every scenario, but it makes a lot of sense and adds value in specific cases, such as:

• Experimentation and rapid prototyping: Since it only takes a few minutes to get up and running using Azure Functions, it is possible to have a back end for a fully functioning prototype in no time.

• Automating development processes: Using Azure Functions is a very handy way of automating some of your internal development processes. A good example is that many software teams use Slack for communication, and it might be convenient to integrate it with your build server so that notifications can be sent to team members when a build occurs in case of errors or exceptions. Given that Slack has a rich ecosystem and extensibility model, all you need is a webhook that it can call to integrate it with Azure Functions.

• Decomposing and extending applications: Just like we saw previously, Azure Functions is ideal for simplifying monolithic systems.

• Independent scaling: Azure Functions is great if you have a number of queue handlers that all need different scaling requirements. If you are managing all the servers yourself, then this can suddenly turn into a headache. However, if you’re using Azure Functions, you simply hand that problem over to the framework and let it solve the problem for you.

• Integrating systems: One of the most exciting and useful features of Azure Functions is the ability to integrate various systems. Sometimes you might need to create an intermediate adapter that connects two systems together—for instance, Twitter and Dropbox. Using Azure Functions is a great way to do that.

• Going serverless: Finally, it’s all about not having to worry about managing servers and infrastructure, so using a series of loosely coupled Azure Functions that communicate together is a great way to simplify a back end.

Summary

We’ve covered a bit of ground in this quick introductory chapter by explaining the fundamental aspects of Azure Functions and providing an overview of a serverless architecture.

Serverless describes a style of programming where the servers, scaling, and even the wiring of the events are transparently managed for you, so you can focus purely on writing the code you need to solve your business needs.

An Azure function is nothing more than a small piece of code that responds to an event, so in other words: Azure function = Event + Code.

The Azure Functions framework is built on top of other solid Azure products, like Azure Web Apps and WebJobs.

One of the great things about Azure Functions is its flexibility—it doesn’t force you to go all-in on a serverless architecture. Instead, it can be used a alongside a more traditional architecture—and let’s not forget the ability to do rapid prototyping.

In the next chapter, we’ll be creating our first function application, which will allow us to group various Azure Functions together, and dive straight into code. Finally, some fun!