Going Serverless with Azure Functions

//Going Serverless with Azure Functions

Azure Functions open a door to new ways of solving business problems that are more focused or isolated in nature. A Function could be a simple task of sending an email when something happens or a more complex chain of dependent processes. The primary benefit is the ability to create small solutions without the need to build an entire web application. The industry term for this cloud-based approach to an application is called “Serverless”.

What is Serverless?

The term “Serverless” seems to be one of the more confusing buzzword terms floating around today. It evokes an esoteric way of viewing an application that involves quite a bit of hand waving. Simply put, “Serverless” means that an application can be developed and deployed without having to manage the hardware OR software on which it will run. The key term there was “OR software” because a “server” also can represent an application in addition to a physical piece of hardware. For example, SQL Server or Internet Information Services (IIS).

This approach falls under the Platform as a Service (PaaS) umbrella with one additional caveat: The code written should not be required to interact with the server or server-application on which it runs. In other words, the code should be “plug-and-play”.

The Windows Service of the Cloud

I like to view Azure Functions as something akin to running a Windows Service (or Linux Daemon) in the cloud. The types of tasks that are great for a Windows Service are usually great for an Azure Function. The main difference being access to different types of systems. A Windows Service would rely on OS systems like Windows Logs, the file system, or other locally installed applications. Azure Functions, on the other hand, would rely on systems like Blob storage, Event Hubs, or Service Bus. Azure Functions also can receive HTTP requests without writing any additional code normally required for self-hosting a web server.

Triggers and Bindings

Functions were built on top of the WebJobs SDK and therefore operate via input and output bindings. Input bindings are the parameters that get passed into your function. Output bindings are what gets returned from your function via a return statement or an “out” C# method parameter.

For any input binding there needs to be a trigger. These triggers are what call the function. They are activated by one of several integrated services that are available on the Azure platform. These integrated services are what allows the function, and thus your code, to not have to interact with the underlying server-application platform.

The following are the current binding types:

  • Schedule (Is a Trigger via the WebJobs/Functions integrated service)
  • HTTP (Is a Trigger via the WebJobs/Functions integrated service)
  • Blob Storage (Is a Trigger via Azure Storage integrated service)
  • Event Hubs Event (Is a Trigger via Azure Event Hubs integrated service)
  • Storage Queues (Is a Trigger via Azure Storage integrated service)
  • Service Bus Queues and Topics (Is a Trigger via Azure Storage integrated service)
  • Storage Tables (via Azure Storage integrated service)
  • Data tables (via Azure Mobile Apps integrated service)
  • No-SQL DB (via Azure Document DB integrated service)
  • Push Notifications (via Azure Notification Hubs integrated service)
  • SMS Text (via Twilio integrated service)
  • SendGrid Email (via SendGrid integrated service)

No IDE Required

Code your Azure Function directly in the Azure portal

Code your Azure Function directly in the Azure portal

That’s right, you can literally write your code in the browser at the Azure portal site (portal.azure.com). Whether it’s C#, F#, or Node you can write your code directly in the browser. Not only are Azure Functions “serverless”, they are also “Clientless”.

This does not exclude IDEs or editors when their usage is required though. There is great support for Visual Studio 2015/2017 as well as VSCode.

Consumption Plan VS App Service Plan

Running your Function can be handled in two ways. The first way is the Consumption Plan with the second being inside an App Service Plan.

The Consumption Plan allows your Function to be a stand alone compute instance among other shared resources. You are only charged when the function is executed. Each compute instance that a function is allocated 1.5GB of memory. As the load on that Function is increased Azure will dynamically scale out to accommodate that load. When the load is decreased Azure will scale back in to reduce the instances of the running Function. When there is no load, the Function goes into an idle state.

The App Service Plan allows your Function to reside on a dedicated VM, just like Web Apps. App Service Plans are billed as one unit so you can have as many functions running as your App Service Plan can support. This also lends itself to reusing existing App Service Plans that have available resources, thus reducing costs.

Functions Are Serverless

As you can see Azure Functions fill the niche of “Serverless” applications quite nicely. There are many different ways in which to leverage this aspect of Azure. I’m sure there are scenarios running through your mind already so go out and give them a spin. As always feel free to reach out to us here at Nebbia for any assistance or guidance in this area. Happy functioning! 😉

By |2017-05-02T13:45:46+00:00May 2nd, 2017|

About the Author: