Alternatives to Azure Kubernetes Service (AKS): Azure App Services

app-service-icon You can run your web applications in Azure App Service in a fully managed service using either Windows and Linux-based containers. You may not need the overhead of a Kubernetes deployment. App Services provides security, load balancing, autoscaling, and automated management.

In addition, App Services has DevOps capabilities, such as continuous deployment from Azure DevOps, GitHub, Docker Hub, and other sources, package management, staging environments, custom domain, and TLS/SSL certificates.

By fully-managed, we mean App Service automatically patches and maintains the OS and language frameworks for you. Spend time writing great apps and let Azure worry about the platform.

With App Services Environment, deploy your application within a virtual network you define where you can have fine-grained control over inbound and outbound application network traffic.

App Service Plans

One or more of your applications run inside an App Service Plan. An App Service plan defines a set of compute resources for a web app to run. You can think of the App Services compute resources as a server farm. One or more apps can be configured to run on the same computing resources (or in the same App Service plan).

When you create a App Service plan, you define:

Region (West US, East US, etc.)
Number of VM instances
Size of VM instances (Small, Medium, Large)
Pricing tier (Free, Shared, Basic, Standard, Premium, PremiumV2, PremiumV3, Isolated)

Pricing tiers define the features and the number of web applications that can be hosted within the plan. Apps deployed in the Free and Shared tiers run in worker processes on shared virtual machines, while apps deployed in the Standard and Premium tiers run on virtual machine(s) dedicated specifically for the apps associated with a single customer. The Isolated tier allow you to run apps in your dedicated virtual networks with even better scale and performance through an intuitive user experience.

When the app runs, it runs on all the VM instances configured in the App Service plan. If multiple apps are in the same App Service plan, they all share the same VM instances.

If the plan is configured to run five VM instances, then all apps in the plan run on all five instances. If the plan is configured for autoscaling, then all apps in the plan are scaled out together based on the autoscale settings.

Application architecture using Azure App Services

The following diagram (from Microsoft reference architecture) shows a sample reference architecture, which shows proven practices for improving scalability and performance in an Azure App Service web application.

Containers in App Services

Although App Services does not require that you use containers, you can run either Windows or Linux containers on App Services. Azure App Service uses the Docker container technology to host both built-in images and custom images.

And you can run a built-in container image or build and deploy your customer container. Let’s start with the built in container image.

Built-in container image

App Service on Linux supports a number of language specific built-in images. Just deploy your code. Supported languages include: Node.js, Java (JRE 8 & JRE 11), PHP, Python, .NET Core and Ruby. Run az webapp list-runtimes --linux to view the latest languages and supported versions.

When deployed to built-in images, your code and content are allocated a storage volume for web content, backed by Azure Storage. The disk latency of this volume is higher and more variable than the latency of the container filesystem. Apps that require heavy read-only access to content files may benefit from the custom container option, which places files in the container filesystem instead of on the content volume.

Custom container

If the runtime your application requirement are not supported in the built-in images, you can deploy it with a custom container. Once you have tested your code locally, you can deploy a custom container image, using these steps:

For more information, see Migrate custom software to Azure App Service using a custom container.

You can deploy multiple containers as a single app using Docker compose. See Tutorial: Create a multi-container (preview) app in Web App for Containers.

Other considerations for your App Services architecture

There are other considerations when you are choosing how to run your container in Azure App Services. This section highlights:

Staging environments
Virtual network integration
Global scale with high availability
Security and compliance
Integration with other Azure services

Staging environment

If you are using the Standard, Premium, or Isolated App Service plan tier, you can test your web application in a staging slot instead of the default production slot. Deployment slots are live apps with their own host names. App content and configurations elements can be swapped between two deployment slots, including the production slot.

During testing, you can deploy into a staging slot, conduct tests in a live environment, then swap into production. But if there are issues, you can swap back.

Or you can route a portion of the traffic to another slot. This feature is useful if you need user feedback for a new update, but you’re not ready to release it to production.

The following diagram from Microsoft, shows continuously deploy containers using slots.

For more information, see App Services Deployment Best Practices.

Virtual network integration

In many cases, you will want to define your own virtual network for your web applications and user virtual networks to control access.

There are two primary deployment types for the Azure App Service. There is the multi-tenant public service, which hosts App Service plans in the Free, Shared, Basic, Standard, Premium, Premiumv2, and Premiumv3 pricing SKUs. Then there is the single tenant App Service Environment(ASE), which hosts Isolated SKU App Service plans directly in your Azure Virtual Network (VNet).

Multi-tenant App Service networking

By default, App Service hosted apps are directly internet accessible and can only reach internet hosted endpoints. Many customer applications however need to control the inbound and outbound network traffic.

App Services provides several features to consider:

Inbound features: App assigned addresses, access restrictions, service endpoints
Outbound features: Hybrid connections, gateway required virtual network integration, virtual network integration

For more information, see App Services networking Use case and features.

Azure Service Environments

In the Isolated tier, you get a fully isolated and dedicated environment for securely running App Service apps at high scale, called App Service Environments (ASE).

ASEs host applications from only one customer and do so in one of your virtual networks. You have fine-grained control over inbound and outbound application network traffic. Applications can establish high-speed secure connections over VPNs to on-premises corporate resources.

The ASE enables use cases such as:

Access resources in your VNet
Access resources across ExpressRoute
Expose your apps with a private address in your VNet
Access resources across service endpoints

Integration as a Private Endpoint

You can now restrict access to your web app to virtual network using Private Endpoints, eliminating exposure to the public internet. Available in Premium v2, Premium v3 and Functions Elastic Premium, this feature is now fully supported with a 99.95 SLA. For more information, see Using Private Endpoints for Azure Web App.

Global scale with high availability

Scale up or out manually or automatically. Host your apps anywhere in Microsoft’s global datacenter infrastructure, and the App Service SLA promises high availability.