Recent Posts



Azure Function v.s. Web App aka. Serverless v.s. PaaS

There are several efficiencies to be gained by leveraging cloud services such as resilience, efficient cost management and on demand computing (to name a few). As such IT practitioners need to ensure we appropriately utilize combination of serverless (Azure Functions) and PaaS (Web Apps) across our solutions and apply sensible / practical guidelines for selecting either option to host and execute business logic.

This article will talk to some thoughts around governance / assessing the best hosting service for our applications on Azure, however these principles can be applied to most cloud services providers.

In our solution designs we often find the need to execute different types of workloads which can be categorized as follows:

  1. End user systems which execute business processes and transactions i.e. websites used by customers and business partners

  2. Processing of events generated by users and system components needing real time or scheduled data processing i.e. billing and invoicing calculations, product dispatching schedules etc.

  3. Containerization and surfacing of business logic which will be invoked by applications to execute business processes or calculations i.e. web services which allow websites to execute business processes or are used to execute rules in calculating prices, shopping cart totals etc.

Depending on various factors we may need to leverage the benefits of Serverless Compute functions or Web Applications to fulfill our workload requirements. It is important to note that assessing the appropriate hosting method needs rigor and analysis of the value of each offering which I will try to detail in this document.

Firstly, lets define what an Azure Function (Serverless) and Web App (PaaS) is:

What is an Azure Function (Serverless)

An Azure Function is a serverless compute on demand PaaS offering that allows organizations to deploy applications into a cloud environment without the overheads of infrastructure management or ownership. Unlike App Services, Functions do not have a maximum compute limitation and therefore can scale as much as required in an elastic manner when compute demand increases.

The details are as follows:

  1. Pay for allocated memory but on demand compute time i.e. pay a small baseline for memory allocation but compute is charged by the minute. When no compute is occurring, the base charge for memory allocation is incurred only

  2. Subscription levels determine the memory and network abilities of Functions i.e. the more memory you need, the higher the on-demand price

  3. Premium Function plans allow hot scaling leading to instant scale up and down capabilities to ensure seamless load management

  4. The premium tier is in preview right now and the on-demand compute cost is likely to increase slightly once the service is in general availability. Indicative pricing from Microsoft is that Premium Function service plans will be 60% the cost of Premium App Service plans, however as mentioned previously, functions are pay for use so the overall savings still deliver efficiency

What is an Azure Web App (PaaS)

An Azure App Service is a PaaS offering that allows hosting of web applications on an instance of compute and memory power paid for by an organization. This allows organizations to deploy code to a cloud environment without worry about the maintenance / overheads / ownership of the underlying infrastructure or hardware. This PaaS offering however has inbuilt limits which restricts the maximum compute and memory capacity of a web applications based on what a user subscribes to.

The details are as follows:

  1. Pay for allocated CPU and memory for an application on an hourly basis i.e. regardless of usage, you pay for every hour the application is hosted

  2. Subscription levels determine the CPU, memory and networking abilities of App Services i.e. the more you pay, the more you get

  3. App Services allow organisations to manage code but not infrastructure

  4. App Services can scale based on thresholds but the scale isn’t instant, there is a warmup period for new instances of applications once scaled

Guidelines for selecting a hosting option

The questions listed below can be used as high-level guidelines for choosing the appropriate hosting option:

* Is the web application designed to directly interact with users i.e. contains GUIs ?

Use Azure Web Apps: If the application is a website which requires user interaction it is a better candidate for being hosted as an Azure Web App. This is due to the nature of Azure Functions targeting middle ware functionality and MVC applications being better serviced from a code architecture and design patterns perspective by Azure Web Applications.

* Is the web application an API constantly servicing high volumes of traffic executing long running transactions (more than 5 seconds) ?

Use Azure Web Apps: if the API requires long running transactions which will encounter high volumes of traffic that will not exceed foreseeable loads. Azure functions service plans charge based on transaction volumes multiplied by execution times. High volume long running transactions which can be forecasted can benefit from static charge models.

Use Azure Functions: if the API has variable workloads where transaction volumes and durations can fluctuate from situations where APIs are mostly idle but encounter spikes in traffic and workload processing durations. The ability for Azure Functions (premium tier) to scale up instantly in an elastic manner provides a resilient and efficient mechanism for handling on demand compute. Functions are an appropriate mechanism for handling workload spikes where we cannot forecast demand on services but still require instant systems elasticity to handle increases and decreases.

* Does the web application execute for short durations of time for pre-determined number of executions i.e. scheduled tasks, batch processing or eventing ?

Use Azure Functions: if the workloads don’t require constant processing. Functions can be triggered by events or schedules. The native cloud services interoperability in functions allow software to be architected and developed in an efficient manner and so reduce the lines of code and maintenance overheads.

The ability to scale up automatically based on workload requirements also allows for handling of volume so as not to introduce delays based on pre-configured constraints. Also economic benefits of consumption based charges being applied to functions allows us to leverage efficiencies of cloud computing.

* Does the web application require instant elastic scaling?

Use Azure Functions: if we need to instantly scale web applications (middle ware) to seamlessly handle unexpected volumes. Azure web applications can scale out when certain thresholds are met however there is usually a five-minute lag in the scale out and we need to script scale in. This can lead to lost traffic, delays in processing and additional IT overheads in scripting automatic scale in. Functions have a warm instance on standby to allow for automatic instant scale and automatic scale in (as they are elastic).

* Does the web application require high availability ?

Use Azure Web Apps: for systems hosted across multiple cloud data centres / regions factoring in the considerations above.

Use Azure Functions: for middle ware systems hosted across multiple cloud data centres / regions factoring in the considerations above.

Both solutions will require traffic management i.e. load balancing and API gateways. Consider the costs and maintenance overheads of a dual deployments i.e. will running two instances of a premium tier web app result in higher monthly charges compared to two instance of functions priced on a consumption tier, pipeline management and configuration, application management and telemetry.

Also, consideration to the overall solution these components are used in can lead to good design choices i.e. if a system being interacted with has multiple subscription options (geo redundant v.s. geo locked) then we can architect and host applications to leverage availability with reduced effort.

* Will the web application require re-hosting onto another cloud platform without re-writing code ?

Use Azure Web Apps: if there is a definite need to move hosting to another cloud provider with minimized effort. Ensure that new providers can support the .NET / .NET Core runtime. Typically, there is a minimal code change requirement when redeploying web apps, however we need to consider how the web apps are packaged and deployed as shared libraries and packaging of the deployment pipelines will need re-configuring.

Use Azure Functions: if there is acceptance of minor code change requirements. The access methods for functions (at a code level) will require changes when being re-hosted on another cloud provider as we will need to repackage them as web apps. Similar considerations to packaging and deployment pipelines apply to functions as they do to web apps.


When deciding on functions v.s. web apps in this context it is important to factor in the considerations noted in this document as benefits to resilience, maintenance and efficiencies can outweigh the effort required to re-write functions. This is due to the effort of changing a function to web app being minimal when the software is correctly architected and written.

A summary of the considerations above can be found in the table below. The table shows a simplified view of requirements and suggested cloud option, however careful assessment of use cases should be applied to the suggestions below: