Azure AppService vs Azure Kubernetes Service

If you are using Azure and about to select an orchestration service in which to host your applications, you are probably struggling with the following decision: Should I host my application in Azure Kubernetes Service or in Azure AppService?

While this decision ultimately depends on the requirements at hand, there are long-term implications for your choice.

If you are looking for a quick hosting solution for your app in Azure, Azure AppService is definitely the easiest & quickest way to be up and running. It supports different deployment types:

From source code
From docker image
From docker-compose.yml file

Deploying AppService from Source Code

Azure AppService, also called Azure Web Apps, supports most of the popular languages and versions, such as .NET, ASP.net, Java, PHP, Node, Python, Ruby, etc)

Azure Service Deployment Screen — From Code

To deploy an Azure AppService from source code is very simple.

You can create the AppService directly in Azure and publish source code directly from VisualStudio or via CI/CD using for instance Azure Pipelines or even Github Actions.

One of the drawbacks of deploying directly, the source code to Azure AppService is that your code is likely to gain a dependency on Azure, and require significant changes to run in another cloud. If you are looking for a cloud-agnostic way to deploy to AppServices then you can use Docker!

Deploying AppService from Docker Image

One of the most popular options when deploying to Azure AppService is to deploy a service from a docker image. This is a more cloud-agnostic solution, as we are controlling how our service is packaged and run since we have complete control over what goes inside the docker image via the Dockerfile.

We can publish the docker image to the Azure Container Registry(ACR) via, for instance, a Github Action.

Deploying AppService with Docker Compose

Another new deployment option for Azure AppService is to deploy via a docker-compose.yml file. However, it is important to understand that the docker containers are inside a single AppService, rather than multiple AppService’s as one might expect.

In cases where we want to deploy more than one container at the same time via docker-compose, it is also possible now.

Azure Kubernetes Service

The other option available, to deploy an application in Azure, is to choose the increasingly popular Kubernetes.
Azure provides a fully managed Kubernetes solution, called Azure Kubernetes Service. It works pretty well, and you can get up and running quickly, assuming of course you already know how to use Kubernetes.

Kubernetes is an industry-standard right now, open-source, for automatic deployment, scaling and management of containerized applications.
It has wide adoption and has all the functionalities required to build a highly scalable and resilient website.

Now let’s do a quick comparison of the two solutions, taking into account key requirements.

High Availability

High availability is a key requirement for resilient applications.

Both in AppService and AKS, high availability is supported natively in a single region. A single region contains at least 3 availability zones. If multi-region availability is needed, then that can also be achieved with a bespoke solution using Azure Traffic Manager.

DNS

AppService: Each AppService is allocated a unique domain name based on the app service name under *.azurewebsites.net

AKS: A service exposed via a public load balancer can be assigned a fully qualified public domain hosted under *.<location>.cloudapp.azure.com.
If a non-azure DNS is required, it is also possible via DNS configuration.

Scalability

AKS

Automatically: can scale the number of replicas of pods automatically, using the horizontal pod autoscaler or scale the number of nodes of the cluster using the cluster autoscaler. Kubernetes can also adjust resources up or down per pod by analyzing CPU and memory consumption by pods using the vertical pod autoscaler. Unfortunately, this feature is not yet supported in AKS.

Manually: Scale Up by increasing CPU/Memory usage of nodes.

AppService

Automatically scale the number of VM instances running inside AppService Plan. (Scale-Out)

Manually: Scale Up by choosing a higher App Service Plan tier.

Resource Control

AKS: Can control CPU, memory for each container inside a pod

AppService: There is no way to limit the consumption of memory and CPU services in AppService.

Environments

AppService: The only way to create more than one environment in AppService is by having multiple AppServicePlan. Each AppServicePlan runs in separate hardware, so it is not possible to share computing resources across the environments.

AKS: We can have separate environments by having separate clusters or by creating separate namespaces inside the same Kubernetes cluster. It is also easy to create new environments as a namespace can be created very easily in Kubernetes. Furthermore, it is possible to isolate workloads by using separate node pools.

Cloud Vendor Lock-in

AppService: It is only available in Azure. Even though it leverages docker containers, working with Azure AppService requires Azure training.

AKS: Kubernetes is available in most of the cloud providers. If ever needed, it is possible to move workloads running in Azure Kubernetes Service to other Kubernetes providers like Google Kubernetes Engine(GKE) or Amazon EKS.

Availability of tools

Kubernetes is the most popular. There are a lot of tools and community support available for Kubernetes.

Running Background Jobs

AKS

In AKS you can create a Job to run periodically or one that can be triggered on demand.

There are a huge number of options on how you can run a background job. For instance you can create a job that can run a number of Pods in parallel until a fixed number of completions. Or you can create a Job that only runs until one successful completion by a Pod. There are also a lot of configuration options to deal with failure. For instance we can define a restart policy which decides to restart the Job if it fails, until a maximum number of attempts, etc.

A really great benefit of Kubernetes is that you can configure your Jobs to run on a separate node pool, especially if it is the kind of job that requires a lot of CPU/Memory. You can also impose CPU/Memory limits on a Job so that it doesn’t cause other pods in the cluster to be evicted.

AppService

In AppService you can create two types of WebJob:

Continuous WebJob
Triggered WebJob

A Continuous WebJob runs forever in all instances of an AppService Plan. This can be changed by restricting the WebJob to run on a single instance.
On the other hand a Triggered WebJob only is only executed when either triggered or depending on a schedule or event.

There are two types of triggers for WebJobs: a schedule-driven trigger or a event-driven trigger.

Unlike Kubernetes Jobs, it is not possible to impose limits on WebJobs or to separate WebJobs from regular workloads.

Pricing of Azure Kubernetes Service vs Azure AppService

In terms of Pricing, AKS is the winner with a 30% average cost saving vs Azure AppService. If you want to dig in to more details on why Azure Kubernetes Service is cheaper, then consider reading the following article:Azure Kubernetes vs. App Services — A Simple Cost Comparison
The table below contrasts the costs of App Service Plan tiers with Azure Kubernetes Service (AKS) and Virtual Machines…medium.com

Tooling & Access to Talent

Another really important point to consider when choosing between Azure AppService and Azure Kubernetes Service, is access to tools.
Kubernetes has a thriving community with lots of great tools that make it extra powerful. Kubernetes has ArgoCD for CI/CD with GitOps, or Helm which makes it much easier to manage and deploy Kubernetes applications. And also consider that most major frameworks like Elastic Search, Grafana, Nginx, MongoDB, etc have helm charts which make it really easy to deploy applications to them.