This article is contributed. See the original author and article here.



There are many excellent resources available that explain the motivation for going to the cloud and/ or Application modernisation. Assumption is that Azure is the Cloud provider and there is a NEW application that needs to be hosted.  The application can be written in any of the popular languages. For existing workloads have a look at this for guidance; please be aware that the flow is a start but not as binary as it would suggest.


Hosting the application on a VM is also an option but is not being considered as taking maximum advantage of the available cloud benefits. VM hosting is not within the scope.




With (full) PAAS offerings like Azure Webapps and Azure Functions you make optimal use of the Cloud Benefits. Although you have a Pay as You go model there is a price tag for all the functionality you get out of the box. Although the PAAS offerings try to have a non opinionated technology stack the implementation is done according to the best practices of Microsoft and will never be as open and flexible like the open source solutions.


Hosting on a (semi-paas) container solution like AKS, can be considerably cheaper initially. However  customer responsibility and operational costs are higher than solutions based on Webapps and Functions. Container solutions give a higher flexibility but do not come with standard solutions like Application authentication out of the box. In general more skills are required from the Developers and Operators maintaining the Containerised solution(s) on the other hand you have a very flexible platform that is based on the latest open source standards.


There is no right or wrong here, only what is suitable to you. When making a decision try to make it an educated one, the decision matrix below could be a start for your journey.


Hosting options


To have a better understanding of the products a short description of the product and its features is given. Intention is to give a quick overview, more information can be found in the links provided.


Azure Web apps


WebApps gives you a platform to host your applications based on an underlying runtime stack, for eg: Tomcat on linux for nodejs and python based workloads.

This platform is linked to an App Service Plan which gives you a set of features and capabilities.

There are 3 major SKU types for WebApps:

  • Dev/ Test; ideal for hosting small solution, has the least capabilities but is also the cheapest
  • Prod; Has all the features you probably need, hosted on a shared platform
  • Isolated; Has all the features you need. Also referred as Application Service Environment or ASE, this is the enterprise ready solution where you have dedicated hardware on a dedicated network and tenant.

Within one of the SKU types you can select a tier which has impact on the specifications and specs:





With Azure Webapps you do not have to worry about setting up and maintaining an infrastructure for your applications. 


Short summary of operational concerns:

  • Scalability; depending on SKU and tier, your APP can scale as desired
  • (High) Availability; depending on SKU and tier, WebApps will make sure that your service is available
  • Security; built in features like integration with AAD and using Azure Services via Service endpoints (Prod SKU and up). Your Webapp is also by default protected against known vulnerabilities like Denial of Service Attacks.
  • Monitoring and Alerting; Alerts can be easily configured and integration with Azure Monitoring  and App insights provides valuable insights.

Other important features are the KUDU toolkit for version management and integration with CI/CD tooling and Deployment slots for deploying new releases in a blue/green scenarios.


Azure Webapps provides the functionality of hosting containers as well, but (my opinion) that makes no sense as Azure Webapps is not designed to be a container orchestrator or scheduler.


The AWS alternative to Azure Webapps is Elastic Beanstalk.  For more information, please have a look at the documentation


Azure Functions


Considered by many as the holy grail of modern application hosting. Azure Functions is also referred  as Serverless technology, the idea is to abstract the Server (infra) away and put the main focus on the function(s) of your app. 


Azure functions shines in scenarios where you need event driven architectures. It is (in general) not used for hosting long running (stateful) applications.

Azure functions is often used in conjunction with an (process) orchestrator like Azure Logic Apps. Below are some well known scenario’s for Azure Functions: 




Two concepts are essential in the usage of Azure Functions: Trigger and Bindings.


A Trigger is an event that is responsible for the start of a the execution of a Function; example of triggers are:

  • EventHub Trigger
  • Blob Storage Trigger
  • Http Webhook
  • Timer Trigger

Bindings are links to the data used within the function.

There are Input Bindings and Output Bindings, an example of an InputBinding could be a message on a queue and the output could be a transformed message that will be persisted in a database using an output binding.


Short summary of operational concerns:

  • Scalability; depending on SKU and tier, your Azure Function can scale as desired
  • (High) Availability; depending on SKU and tier, Azure Functions will make sure that your service is available
  • Security; built in features like integration with AAD, integrations with other Azure products are very easy as well, for eg APIm 
  • Monitoring and Alerting; Alerts can be easily configured and integration with Azure Monitoring  and App insights provides valuable insights.

Cost efficiency is a major factor for using Azure Functions. 

While with other platforms you are paying for the usage of the underlying hosting platform, with Azure functions you do not.  Azure Functions provides the concept of Micro Billing, with micro billing you only pay for the actual usage of the function.  


The AWS alternative to Azure Functions is Lambda. For more information, please have a look at the documentation


Azure Kubernetes Service


Container technology has made a tremendous growth in usage and adaption the last 5 years. With  Kubernetes on the forefront of hosting container workloads it has an enormous following and the fanbase is growing. Azure provides hosting of container workloads through several services but Azure Kubernetes Service (AKS) is by far the fastest growing service at the moment.

An alternative with most of the functionalities is Azure Redhat Openshift (ARO), this is considered an opinionated version of managed Kubernetes. It is implemented according to the best practices of Redhat. ARO uses Red Hat Enterprise Linux CoreOS in stead of Ubuntu (debian based), which is used by AKS . ARO is a collaboration between Microsoft and Redhat.


AKS is a semi PAAS offering; Simply put Kubernetes consists of 2 components: 

  • Management component; responsible for managing your workloads
  • Worker nodes; the worker bees that are responsible for hosting your application

The managed component is a PAAS offering which is free of use; depending if you choose to have a SLA. The worker nodes are the compute power and is considered the IAAS solution for this offering.

However this is not fully true as the maintenance of the Operating System is executed by Microsoft, the customer is responsible for the reboot actions that might be needed.

Upgrading the Kubernetes version itself is very easy but must initiated by the customer, there are tools available that can assist in this (for eg KURED).

Microsoft has put all effort in to make maintenance of this shared responsibility platform as easy as possible.




Once this platform is UP and running it provides an enormous flexible platform that can host almost all open source based solutions like: Apache Flink and ElasticSearch. AKS even supports hosting Windows containers.


Short summary of operational concerns:

  • Scalability; AKS uses a POD autoscaler for Pod distribution across existing nodes and a Cluster Autoscaler that utilises the underlying VM scale-sets.
  • (High) Availability; Kubernetes is designed for HA scenarios, in most regions Availability zones bring an extra layer of availability insurance
  • Security; Application security does not come out of the box, however API security for managing AKS is an option that is easily configured to work with AAD integration and Kubernetes RBAC
  • Monitoring and Alerting; AKS comes with the option to automatically integrate with Azure Monitor, by enabling this option an extra deployment on your kubernetes cluster is running which is responsible for logging the AKS/ app events.

Kubernetes and thus AKS is also suitable to host event driven solutions. With KEDA you can host Azure Functions on your AKS cluster, it does provide all the functionality using triggers and bindings but does not have the micro billing feature like Azure Functions does.


The AWS alternative to Azure Kubernetes Service is Elastic Kubernetes Service. For more information, please have a look at the documentation

Decision Matrix

Features Costs Features
fm.png = Fully Managed

$ = Affordable

+ = Limited

pm.png = Partially Managed

$$ = Mid Priced

++ = OK

sm.png = Self Managed  $$$ = Premium +++ = Excellent



  WebApps Functions AKS


Scalability fm.png fm.png fm.png  
Availability fm.png fm.png fm.png  
Security fm.png fm.png pm.png AKS does not support out of the box application security
Monitoring fm.png fm.png fm.png Integration with Azure monitor
CI/CD support  pm.png pm.png pm.png  
Maintenance: Patches/ Updates fm.png fm.png fm.pngpm.pngsm.png OS updates/upgrades are managed, reboots are not. K8 updates/upgrades are initiated by customer, supported tooling makes it easy.
Support for different apps ++ + +++ Functions only for certain scenario’s. Webapps supports more hosting scenarios, AKS supports almost everything
Deployment strategies ++ ++ +++ Though not out of the box, but K8 can supports all types of deployment strategies: Recreate/ Canary/ Blue Green/ Shadow etc etc
Integration with other Azure PAAS services +++ +++ +++ AKS uses the Open Service operator to integrate with other Azure Paas services
Unit Costs $-$$$ $-$$$ $ Webapps, Premium is ASE or high prod SKU. AKS you pay only for the required nodes. see calculator
Operational costs $ $ $$ Initially ramping up and educating will be more effort for AKS. Also more operational work is required










Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.

%d bloggers like this: