Category: serverless

eBook: Serverless Apps: Architecture, Patterns, and Azure Implementation by Jeremy Likness 5

eBook: Serverless Apps: Architecture, Patterns, and Azure Implementation by Jeremy Likness

eBook: Serverless Apps: Architecture, Patterns, and Azure Implementation by Jeremy Likness 6The “Serverless Apps: Architecture, Patterns, and Azure Implementation” eBook, authored by Jeremy Likness, is a guide for cloud native development of applications using serverless compute. This eBook highlights the benefits of serverless architectures, as well as the potential drawbacks of developing serverless apps. Additionally, the book covers a few different serverless design patterns. Read More

A Tour of Azure Messaging Services (Queues, Event Grid, IoT Hub, and More) 7
ArchitectureInfrastructureserverlessService Bus

A Tour of Azure Messaging Services (Queues, Event Grid, IoT Hub, and More)

A Tour of Azure Messaging Services (Queues, Event Grid, IoT Hub, and More) 8In the early days of Microsoft Azure, there were only a couple message queue service; Azure Storage Queue and Service Bus. This was way back in early 2010. Over the years, there have been a few different messaging and message queue services introduced into the Microsoft Azure platform. Each of these messaging services are a little different than each other and offer a pretty wide range of messaging offerings to choose from. This article walks through the primary features of each of the Microsoft Azure messaging services, and will help give you an understanding of when to use each for your own applications and enterprise scenarios. Read More

Azure Functions: Extend Execution Timeout Past 5 Minutes 9

Azure Functions: Extend Execution Timeout Past 5 Minutes

Azure Functions: Extend Execution Timeout Past 5 Minutes 10Azure Functions is the Serverless compute option within the Microsoft Azure platform. One of the biggest benefits of Azure Functions, and Serverless compute, is that you only pay when your code is actually executing. However, there has been a limitation of Azure Functions in the duration of how long a Function of code can run. This execution time was limited by a hard limit originally set to 5 minutes. For background processes that can be very limiting under certain circumstances. Thankfully, there has recently been an update to Azure Functions that allows you to configure your Azure Functions “maximum execution timeout” to be a little higher! Read More

Azure Functions vs Web Jobs: How to choose? 11

Azure Functions vs Web Jobs: How to choose?

There are a few choices when it comes to implementing custom background processing tasks. The main options in the Microsoft Azure cloud are to use either Azure Functions or Azure Web Jobs. Functions are newer, cooler, and may seem to be the obvious choice going forward, however, the choice isn’t really that easy. This article outlines the points you need to consider when deciding between Azure Functions or Azure Web Jobs.

Azure Functions are Web Jobs

Before we get into the specifics of when Azure Functions are appropriate, or when Azure Web Jobs are appropriate, it’s best to mention that Azure Functions are built on top of the Azure Web Jobs foundation. So, essentially, Azure Functions are Web Jobs. You could almost say that between the two, it’s Web Jobs all the way down.

With Azure App Service and Web Apps, Microsoft implemented Azure Web Jobs as a means to more easily host background processes, long or short running. Web Jobs are hosted within an App Service Plan either stand-alone or along side a Web App (or API App, or Mobile App).

When you get down to it, Azure App Service is hosted on Managed VMs (Virtual Machines) underneath. An Azure App Service Plan is the way that the PaaS (Platform as a Service) services within Azure App Service (Web Apps, Mobile Apps, and API Apps) define the underlying VM.

Web Jobs allow for you to share the resources of an App Service Plan between a Web App and Web Job if you wish in order to help save on hosting cost. Or, alternatively, you could choose to host the Web Jobs in their own dedicated App Service Plan.

With Web Jobs, your background processes can be executed as any command-line executable or script (.ps1, bash, executable, etc). This can be very convenient, but it still requires you to deploy out an entire application often times, since most custom background processes require more complex code bases than a PowerShell script or other command-line script.

In an effort to make the implementation of background processing easier in Azure, Microsoft built out Azure Functions. Azure Functions are actually built on top of Azure Web Jobs in the underlying platform. Consequently, at the core of Azure Functions is the same functionality of Web Jobs. You can setup and run any command-line executable or script as an Azure Function too.

The main different with Azure Functions is that it’s a service that takes the PaaS offering of Web Jobs and turns it up to the max. Instead of building an entire application, you only need to author and deploy individual methods (or functions) of code in an even further managed PaaS platform.

Now with the true difference and similarity of Azure Functions and Web Jobs defined, let’s get into the specifics of when you would choose to use one over the other.

Choosing Web Jobs

Do you have background processing that you need to implement? If yes, then Azure Web Jobs is a viable solution to fill that need. You can implement any type of background processing task as an Azure Web Job. There really isn’t much of a limit to what you can do.

Here are some highlights of the features of Azure Web Jobs:

  • Web Jobs can be configured to be manually triggered or run on a schedule.
  • Web Jobs can be configured to be Continuously running (aka running constantly, all the time)
  • Web Jobs can be setup to be Triggered based on events in other Azure Services, such as a new messaged added to a Storage Queue or Service Buss Queue or Topic
  • Web Jobs can be long running
  • Web Jobs can be short running
  • Web Jobs can be implemented in any language as either a command-line executable or script

As you can see from the above list, Azure Web Jobs can be implemented to fill any background processing need. Implementing background processing with Azure Web Jobs in an App Service Plan is generally a cheaper option over other IaaS based approaches.

Choosing Azure Functions

All the same features listed above for Azure Web Jobs also apply to Azure Functions. You can implement Azure Functions in any language as either a command-line script or executable. They can be manually executed, scheduled, or even triggered by other Azure Services in a similar way.

Even though Azure Functions can be long or short running, there are some caveats to that. Let’s go through what those are.

Consumption Plan

With the Azure Functions Consumption Plan you only pay for your functions when they are actually executing. This helps save significant cost over paying for an entire VM or App Service Plan. If you have an Azure Function that’s only executed a few times per week, as example, this could be extremely cheap.

What does paying for when the Function is executing really mean? The cost of Azure Functions are calculated in relation to the memory usage and total execution time. This relation of memory and execution time is measured in terms of Gigabyte-Seconds (GB-s).

This is an ideal option for hosting Functions that are short running and only intermittently run. With the emphasis on short running there is a maximum timeout threshold to how long Azure Functions can execute. This timeout threshold is set to 5 minutes. If the Azure Function completes within this timeout, then you’ll be able to use the Consumption Plan pricing without issue. However, if the Azure Functions take longer than 5 minutes to complete execution, then it will timeout and the process will be terminated.

Due to the timeout threshold of Azure Functions there are certain architecture and code design practices that will need to be followed in order to get longer running processes to run successfully within an Azure Functions Consumption Plan. The main practice would be to break up the Function into smaller separate functions. These separate functions would then be implemented using one or more message queues to communicate.

App Service Plan

The Azure Functions App Service Plan pricing utilizes an App Service Plan (just as Web Apps, API Apps, or Mobile Apps) to host Azure Functions. This is a more costly option than Consumption Plan.. With App Service Plan pricing you don’t pay for only when the Function is executing, but rather for the reserved resources of the underlying VM.

The reasons to use the App Service Plan pricing may not seem obvious, but there are 2 very good reasons that can make it a very useful option:

  1. Share resources with a Web App, API App, or Mobile App by running within the same App Service Plan.
  2. Reserve dedicated resources for Azure Functions that are either longer running, executed more frequently, or both.

By using an App Service Plan to share resources between Azure Functions and another App Service app (Web App, API App, or Mobile App) then the Azure Functions an utilize a possibly under-utilized App Service instance. This also has the benefit of the Azure Functions essentially being Free to run since the App Service Plan is already paying for the server resources.

Longer running Azure Functions (over 5 minutes) won’t run well with the Consumption Plan due to it’s timeout threshold. When using an App Service Plan to host and execute Azure Functions, the timeout threshold does not exist. Azure Functions are subject to all the same features as Web Jobs when hosted in an App Service Plan. This means Azure Functions in an Azure Service Plan do not need to be architected or designed differently to be broken up into smaller executable pieces.

Consumption or App Service Plan?

As you can see above there are some valid reasons for choosing to use either Azure Web Jobs or Azure Functions. While Azure Functions are built on top of Web Jobs, there still are some differences. However, the largest difference with Azure Functions is the pricing plans. While Consumption pricing only has you paying for when Azure Functions are actually executed, it does have a fairly big limitation, under certain circumstances, which is the timeout threshold. The App Service Plan pricing may be more expensive in certain circumstances, but it also allows you to have longer running Azure Functions, along with the ability to share the unused resources / capacity of an App Service Plan.

Azure Functions are the newer edition of Platform as a Service and the Serverless wave of hosting background processing within Microsoft Azure. Although, Web Jobs are still viable, it’s likely better to use Azure Functions if you can moving forward. However, the choice between Consumption Plan and App Service Plan may be a slightly difficult one depending on the needs of the application.


Subscribe to the Build Azure Weekly newsletter to receive similar updates about Microsoft Azure and related topics!

We respect your privacy and take protecting it seriously. We do not sell our email list, and you can unsubscribe at any time.

Azure Functions Visual Studio Tools Preview for VS'2015 12

Azure Functions Visual Studio Tools Preview for VS’2015

functions_colorThe serverless computing realm of cloud computing has been growing in interest and functionality lately. Recently, Azure Functions reached General Availability and an eagerly anticipated v1.0 release. Microsoft has not stopped there, in fact they just recently released a Preview of the new Visual Studio Tools for Azure Functions. These tools bring Azure Functions support into the Visual Studio IDE!

Visual Studio Tools for Azure Functions Preview

The new Visual Studio Tools for Azure Functions is currently in a Preview release state. As a result, the tools aren’t fully complete yet, and as with any Preview release it can be expected that things may / will change a bit before the final release. All preview releases can be expected to have some rough spots, bugs, and limitations. That being stated…

The requirements to install the Visual Studio Tools for Azure Functions are:

  • You must be running Visual Studio 2015 Update 3 with the “Microsoft Web Developer Tools” extension installed.
  • You must have Azure 2.9.6 .NET SDK installed.

Once you have the following prerequisites installed, you can go ahead to download and install the Visual Studio Tools for Azure Functions Preview.vsazurefunctionstoolspreviewinstaller01

Create New Azure Functions Project

Once the Visual Studio Tools for Azure Functions Preview is installed, you can easily create a new Azure Functions project within Visual Studio 2015 from the New Project dialog. It is located under the Cloud section under Visual C#.


Even though the Azure Function (Preview) project template is located underneath the Visual C# -> Cloud section, you are able to create / author Azure Functions in non-C# languages within the project after creation.

vsazurefunctionspreview_addfunctionmenuTo add a New Azure Function to the project, just following these steps:

  1. Right-click on the Project within the Solution Explorer window.
  2. Click on Add, then New Azure Function…
  3. Within the New Azure Function dialog, select the Azure Function template in your choice language from the list.

The list of languages supported for authoring Azure Functions within the Visual Studio Tools for Azure Functions is inclusive of all the languages supported by Azure Functions. This makes the tool much more flexible than if it were to only support C# and JavaScript as the current editor UI does within the Azure Portal.

vsazurefunctionspreview_addfunctionlanguagedropdownThe Azure Functions languages supported include:

  • Bash
  • Batch
  • C#
  • F#
  • JavaScript
  • PHP
  • PowerShell
  • Python

In addition to choosing the language template for the Azure Function to add to the project, there are also many different templates to choose from including different types of Triggers that will be setup for the Azure Function. Not all the languages support all the different Trigger types and Function templates from the New Azure Functions dialog, but there is a fairly long list currently available; especially for C# and Javascript.


Here’s a list of the different types of Azure Functions currently available within the Preview release. Remember, the options do vary depending on the programming language selected.

  • Empty
  • BlobTrigger
  • HttpTrigger
  • QueueTrigger
  • EventHubTrigger
  • FaceLocator
  • Generic WebHook
  • GitHub Commenter
  • GitHub WebHook
  • Http GET (CRUD)
  • Http POST (CRUD)
  • Http PUT (CRUD)
  • Image Resizer
  • ManualTrigger
  • SAS Token Generator
  • ServiceBusQueueTrigger
  • ServiceBusTopicTrigger
  • TimerTrigger

Once you choose the Azure Functions template to start from for a new Function, there are some Bindings fields that need to be filled in. These Bindings fields will vary depending on the Azure Functions template chosen to create a new Function from.

Azure Functions Project Files

vsazurefunctionspreview_solutionexplorerThe layout of the files created for a new Azure Functions project is similar to how the files of an Azure Function created through the Azure Portal are laid out.

At the root of the project are the appsettings.json and host.json files. These are files that can be used to describe some things for the projects, but at initial creation they are pretty much empty.

The appsettings.json file can be used to configure any necessary App Settings values that are needed by the Azure Functions within the project.

Then there is a folder created for each Function that gets created within the Azure Function. in this screenshot is an example of a new Azure Function that was created using the Manual Trigger C# template.

The functions.json file contains configuration data for the Function. This is the JSON file that is used to specify / configure the Function Bindings for Inputs and Outputs of the Function.

"bindings": [
"type": "httpTrigger",
"direction": "in",
"route": "orders",
"authLevel": "anonymous"
"type": "http",
"direction": "out"

The project.json for a C# Azure Function is where any NuGet dependencies for the Function get defined. It’s useful to know that in addition to using the project.json file, Azure Functions to automatically have access to some standard namespace imports that just be referenced with a using keyword. There is also a shorthand syntax for adding references to external assemblies from within the C# script file.

Here’s a sample of a project.json file that adds a NuGet reference:

"frameworks": {
"dependencies": {
"Microsoft.ProjectOxford.Face": "1.1.0"

Local Debugging

Azure Functions projects can be run on the local development machine. Currently, in the Visual Studio Tools for Azure Functions Preview release only supports remote debugging with C#, but that is expected to be expanded out in the future.


One prerequisite for running and debugging Azure Functions locally is that the Azure Functions CLI needs to be installed. The first time an Azure Functions project is run locally, it will prompt to download and install the Azure Functions CLI, so this is an easy requirement to manage / obtain.


Publishing to Azure

Azure Functions project can be published to Azure In the same manner as publishing Web Apps into an Azure Subscription. An Azure Web App is created within an Azure Subscription, then the credentials and other information for the Web App is configured within the Publish dialog for the project. Then the Azure Functions project can easily be published into Azure directly from within Visual Studio.

In line with other functionality of Azure Web Apps, the Azure Functions project can also be Debugged Remotely from the local development machine while running in Azure. Currently, this is only supported with C# based Azure Functions.


Known Limitations

The Visual Studio Tools for Azure Functions Preview announcement post lists a few known limitations for this new Preview release. The are as follows:

  • IntelliSense support is limited, and available only for C# and JavaScript by default. F#, Python and PowerShell IntelliSense support is available with the installation of additional components.
  • Adding New files is not available using “Add New Item”.
  • There is currently a bug that causes Functions published from Visual Studio to be improperly registered in Azure.
  • The C# Image Resizer function template incorrectly generates the function Bindings. These need to be manually edited to fix.

Product Feedback

The Azure Functions team is eager to get feedback from anyone using the new Visual Studio Tools for Azure Functions Preview release. Any issues can be reported using the GitHub repository (please include “Visual Studio” in the issue title), plus additional comments and questions are welcome on their Twitter accounts as well.

What is Serverless Architecture? 13

What is Serverless Architecture?

One of the latest moves by cloud service providers (like Microsoft Azure and Amazon AWS) is the shift to offering “serverless” services. These are Platform as a Service (PaaS) services that take the “fully managed” aspects of the service to the max. Serverless service offerings (such as Microsoft Azure Functions) allow for individual code functions to be deployed and managed without the need to deploy and manage the underlying Virtual Machine (VM), including even the applications that hosts the functions too! Additionally, the billing of Serverless architecture only charges you when your code is running, instead of paying to keep the underlying server resources reserved and available. This article will dig into Serverless Architecture,  and help clear up many of the common questions surrounding this “Platform as a Service to the MAX” technology.

Serverless Architecture

Serverless architecture isn’t really to host applications without servers. Of course there still needs to be CPU, RAM, Networking and other components of a computer server in order to host any software. Rather, Serverless really is about taking Platform as a Service (PaaS) to the max!

Serverless is about taking PaaS and turning it up to 11!

Modularity & Flexibility

Platform as a Service (PaaS) abstracts away the underlying hardware and infrastructure so that application code can more easily be hosted, deployed, and managed with much less overhead than traditional hosting. Serverless architecture takes PaaS to the most extreme, by fully abstracting away the server in such a way that a single function of code can be hosted, deployed, run, and managed without even having to maintain a full application.

Each function of code for a back-end systems Web API or Background Processes can be managed individually with Serverless architecture. This helps make systems much more modular, as well as increasing the overall system flexibility. This enabled modularity is ideal for Micro-Services based systems as well.

With the modularity of hosting individual Functions of code comes with it added flexibility. Not flexibility in the Function, but rather flexibility in writing, maintaining, and deploying code. Each Function can be maintained, updated, and deployed individually. This mean that each Function can be updated and deployed in isolation without the risk of taking down other Functions in order to do so.

Functions in Serverless architecture can almost be thought of as “mini-programs” that are maintained by themselves.

Event Driven

Just as a Function of code within an application, in Serverless architecture there needs to be something to trigger the code to run and subsequently return a result. The entry points to execute Functions of code hosted in a Serverless architecture are built around events. This Event Driven (or Event-based) design of Serverless architecture is ideal since Functions of code are hosted as individual items.

Functions of code hosted in Serverless architecture are bound to specific events that fire them off and execute them when necessary. Here’s a few examples of events that can be used to trigger the execution of Functions of code in Serverless architecture:

  • HTTP / HTTPS Request
  • Message Queue Trigger
  • File / Storage Trigger
  • Timer / Schedule

An HTTP / HTTPS Request trigger can be used to expose a Function of code as a Web Service / API of some kind. For example, it could be used to expose a REST API endpoint that performs an action and returns a JSON response. This type of usage would allow for a Serverless implementation of a Web API without the need to build a larger application / infrastructure to host it.


Functions of code hosted in Serverless architecture are bound to specific events that fire them off and execute them when necessary.


The possibilities of pricing Serverless architecture differently is possible due to it being based around an Event Driven model. Other more traditional Platform as a Service (PaaS) allow for reductions in hosting and ownership costs by abstracting away many manual tasks necessary for general server maintenance and deployment. In a way traditional PaaS is “serverless”, but not completely.

Full Serverless architecture hosting services allow for an even greater abstraction of the underlying hardware, Virtual Machine (VM), and infrastructure than traditional PaaS offerings. Since these things are abstracted away as much as possible with Serverless architecture, it enables the Functions of code to be hosted in a way that can better utilize the underlying CPU/RAM hardware with multi-tenancy. Due to this, the cost of Serverless services provide even greater cost savings over traditional PaaS services.

Multiple clients Functions of code can be hosted on the same hardware and/or Virtual Machine (VM) with the ability to host Serverless architecture services in a multi-tenant manner. This allows Cloud Service Providers, like Microsoft Azure, to even further utilize their CPU/RAM and other server hardware to their capacity. This is done by pooling Functions of code / applications from multiple clients (tenants) on the same hardware.

Since Serverless architecture is best hosted in a multi-tenant manner (as described above) the majority of service providers bill Serverless services out on a “Pay-per-Use” basis. Without a full VM, CPU/RAM allocation being billed and paid for to be reserved / available, it doesn’t make sense to bill clients for a full VM instance. Instead, Serverless cloud services (like Azure Functions) are billed by keeping track of the total CPU and other resources used solely during Function code Execution.

Pay-per-Use serverless architecture billing is simplified that charges are only incurred if and when the Functions code is actually executing. When an event triggers the Function to execute, the resources consumed by the Function of code are tracked and billed. When the Function of code is NOT executing, then no costs are incurred.

The billing of Serverless architecture only charges you when your code is running, instead of paying to keep the underlying server resources reserved and available.


With the multi-tenant nature of Serverless architecture, it’s possible for the underlying platform to host and run each Function of code for a particular client on completely disparate hardware and Virtual Machines (VMs) completely unbeknownsed to the client. This method of hosting makes if ideal for automatic scalability.

Serverless architecture services are able to utilize their “Platform as a Service (PaaS) to the MAX” nature to better optimize scalability than traditional PaaS services. In addition to potentially hosting each Function of code on different underlying servers, there could also be multiple instances of each Function of code hosted across multiple underlying servers as well. This allows a Serverless platform (like Azure Functions) to automatically scale out to the maximum degree.

Serverless architecture services are able to utilize their “Platform as a Service (PaaS) to the MAX” nature to better optimize scalability than traditional PaaS services.

Serverless in Microsoft Azure

The service offering in the Microsoft Azure cloud platform is the Azure Functions service. Azure Functions allow for Serverless architecture to be built out on the Microsoft Azure platform. It also supports many different platforms and frameworks, like .NET, Java, Python, and Node.js. Azure Functions are extremely flexible where Functions can easily be authored in .NET or Node.js directly within a web browser. Azure Functions can even be built as a console applications or entirely as shell scripts.

The next wave of Platform as a Service (PaaS) is here, and it’s Serverless Architecture!