Understanding serverless architecture capabilities available on Azure

For a developer who’s really occupied in building great applications to cater diverse business scenarios, the added responsibility of managing infrastructure or continuous anxiety about the network setup, OS/framework patches could be a distraction — or rather an irritation. That’s the primary reason which had driven all those platform improvements we have seen over the last decade or so — to free up developers’ time to focus on building applications.

First, we started with ‘on premise’ infrastructure — which means you’ll be managing from nuts and bolts to application code. Then came the cloud revolution. And a whole burst of platform an application service improvements had followed on. We’ve seen the arrival of concepts like IaaS and PaaS, which had cut down more of those added responsibilities and let the developer to focus more on the important stuff — that is, writing code to bring things in to life.

From ‘on premise’ to ‘serverless’ (Image courtesy: https://stackify.com/function-as-a-service-serverless-architecture/)

Latest milestone on this path of improvements is, the serverless’ application architecture. Now, to start off without any confusion, serverless doesn’t mean there are no servers. It has all those servers and other infrastructure concerns hidden underneath. But the complexity of managing them and responsibility of doing so is taken off from the hands of developers.

What is serverless computing?
Serverless computing allows you to build and run applications and services without thinking about servers. Serverless applications don’t require you to provision, scale, and manage any servers. You can build them for nearly any type of application or backend service, and everything required to run and scale your application with high availability is handled for you. (source)

As it might be already evident by now, serverless is basically an abstraction of servers. But there’s more; it’s also an event driven architecture. Which means when we deploy our code in Azure we (or rather some other component in the larger application) will need to tell when to run it. Code will only get triggered from an outside event. And one of the other major advantage is, you’ll only get charged for your exact usage (as resources are provisioned only for the required duration and there’re no continuously running resources) — which is known as ‘micro billing’.

Almost all major cloud service providers has their own adaptation of serverless architecture concepts. In this article, we’ll have a look at what are the facilities available in Azure to support serverless applications.

Serverless Offerings on Azure

Azure provides a wide range of services to support serverless application development. Some of them are direct implementations of serverless architecture concepts, some are BaaS functionalities and some others are just supportive tools for the serverless eco-system.

But, in the purview of this article, I’ll be detailing out only three of the major offerings that are available. Those are; Azure Functions, Logic Apps and Event Grid.

However, if you are interested in exploring other available services, following table provides a pretty much comprehensive view of Azure services that supports building serverless applications.

Azure options for serverless applications

Azure Functions

‘Azure Functions’ are in a nutshell is small discrete pieces of software that’s stored and executed in cloud. Basically, it’s the FaaS (Function as a Service) implementation on the Azure. FaaS enable developers to execute their code in response to myriad range of application/platform events without having to build or maintain a complex infrastructure.

In Azure Function apps, code written by developers will be deployed (stored) in the cloud. They have the option to select their language of choice out of C#, JavaScript, Java, F#, PHP, Python and some scripting languages like PowerShell or bash (see full list of supported languages). Azure functions supports NuGet and NPM, which means you can still use all required dependencies. Furthermore, we have the option to select our preferred environment; be it Windows, Linux or Mac.

These code pieces (functions) will start within milliseconds in order to handle an incoming request that’s been triggered by an event. It’s important to note that this particular function instance handles only that specific individual request and terminates after completing the required work. What’s even better, you’ll only get billed for that time span when the function was up and performing.

A function can be triggered on various types of events, such as; HTTP requests, timer events, generic webhook, CosmosDB events, Blob events, Queue items…etc.

Also, functions can integrate in to number of other azure services. For example; through Azure functions you can directly access/connect to other services like Cosmos DB, Event Hubs, Notification Hubs, GitHub, Twilio…etc.

Azure Logic Apps

When the application logic is scattered across number of micro-services, third party services or serverless functions, it’s necessary to find a mechanism to stitch them all together. Azure Logic apps are built around this purpose of providing that central orchestration mechanism and management platform to handle all those event driven services.

Azure Logic Apps simplifies how you build automated scalable workflows that integrate apps and data across cloud services and on-premises systems. — source

Basically, the core concept of Logic apps is to collaborate different events, triggers and logic in to more complex workflows. These events, triggers or logic needn’t to be only custom build functions or applications. Azure itself provides more than 200 out of the box connectors to different services and components; which provides built-in functionalities and, on their own publish events.

The ability to connect to other services and fire events means Logic apps can be effectively used for connecting on-premises, hybrid and cloud applications across boundaries. Therefore, it’s an ideal candidate for handling mission-critical, complex integration scenarios.

In similar to Azure functions, Logic apps also activates on a trigger and the required resources will only be provisioned automatically by Azure for the time it’s required.

Azure Event Grid

Event Grid, a single service for managing routing of all events from any source to any destination. Designed for high availability, consistent performance, and dynamic scale, Event Grid lets you focus on your app logic rather than infrastructure — source

Event Grid is basically designed to be used for connecting event sources and event handlers in serverless computing. Primarily, Event Grid supports handling events coming from Azure services. You can programmatically respond (by developing an azure function for example) to an incident of an azure service like Service Bus, IoT Hub, Media Services, Storage Blob or Resource Groups…etc.

Event Grid provides the options to utilize a fully managed event routing service. Which will eventually allow developers to connect their serverless business logic to events that are raised by either Azure services themselves or from our own custom applications (via custom topics).

Following image shows the available event sources and handlers in Azure environment.

Event Grid: Event sources and handlers (Image courtesy: https://docs.microsoft.com/en-us/azure/event-grid/overview)

In a real world sample scenario, we can utilize event grid to notify Azure Automation when a blob storage is created or deleted. Or, notify relevant functions or services when there are active messages in a Queue and no receivers are listening..etc.


Azure has a number of services or components to support serverless computing. As you might have noticed, each of them are designed for a specific (and quite distinct) purpose. But all of them can integrate well and complement each other to form very complex integration scenarios. Only common behavior among those service offerings is — all of them make you less worried about server infrastructure and cost you only for the actual operations of your code.