Azure Container Hosting Demystified

If you’re just getting started with containers and want to run them on Azure the number of options available can be overwhelming, especially with all the not so intuitive acronyms. There are many different options for hosting containers in Azure and all of them fill a specific need. Choosing the appropriate tool will all come down to understanding the benefits and use cases for each. In this post, we are going to take a look at the uses for each of the container hosting options in Azure.

Standalone Container Hosting

If you’re looking for somewhere to host a container (or containers) and don’t need the services provided by an orchestrator, then the following Azure offerings may come in useful.

Azure Container Instances

https://azure.microsoft.com/en-gb/services/container-instances/

Azure Container Instances (ACI) has recently gone GA. This service offers containers as a first class instance in Azure. With ACI you use the portal or CLI to create a container, no need to worry about provisioning VMs to host the container or installing software. ACI instances can be created with a single line CLI or PowerShell command and will be up and running in minutes. Where you need multiple containers talking to each other ACI supports container groups, which allows you to run numerous containers together on the same host and local network. ACI containers can be configured with CPU and RAM to meet your requirements and support Linux and Windows containers.

ACI is a relatively new service and does still have some limitations, primary of this is that it is not yet possible to attach them to an Azure virtual network. Note that running an ACI instance 24/7 will be slightly more expensive than running a VM of the same size, you’re paying a bit extra for ease of use. This means that ACI is excellent for bursty load types or tasks that run on a set schedule. We’ll talk a bit more about some of it’s bursting capabilities when we discuss orchestrators.

Azure Web App

https://azure.microsoft.com/en-gb/services/app-service/containers/

It’s now possible to host a container within an Azure Web app. Containers for Web Apps is designed for hosting web server based containers, and it is currently limited to running in Web Apps for Linux (and so only supports Linux containers), so your look at containers running things like Apache, NodeJS, Nginx etc. Setting this up is a simple as creating a new web app and then configuring it to point to a container registry. With containers for web apps, you pay the standard price for the size of web applications you select; there is no additional cost for using containers.

As this is Linux containers only your limited to languages supported on this OS, in particular, if you want to use .net then it needs to be .net core.

Azure Functions

https://blogs.msdn.microsoft.com/appserviceteam/2017/11/15/functions-on-linux-preview/

With the release of Azure functions 2.0 and Azure functions on Linux we now have the option to use containers for our function application. Again, this is Linux only containers, and you need to use the microsoft/azure-functions-runtime as the base for your container image. This image contains the Azure Functions runtime that is required to allow this to work with the Azure Functions infrastructure.

Once you have deployed your image, you have access to all the functionality of Azure Functions for your event or schedule driven workloads. You also have the same limitations such as the 10 minutes maximum execution time for consumption based functions.

Azure Batch

https://docs.microsoft.com/en-us/azure/batch/batch-docker-container-workloads

Azure Batch is Microsoft’s solution for large-scale parallel batch processing. Classically this involves spinning up virtual machines either from a gallery image and loading applications or a custom image. With containers for batch, we can now encapsulate all our application files inside of a container image rather than having to deploy them onto the gallery image or manage a full-blown VM image.

With container workloads for batch, you are still deploying the batch VM’s, but these are running an OS version with container support enabled, onto which your container image is then loaded. Your container has access to the full resources of the VM it is running on (one container per VM). Containers for batch also supports the ability to pre-fetch your container image for your batch pool to reduce deployment time.

Standalone VM

https://docs.microsoft.com/en-us/azure/virtual-machines/linux/dockerextension

There is nothing to stop you creating an Azure VM, installing docker and running your containers from there, and for Dev and Test workloads this may well be a good option. This approach, however, does mean you are on the hook for managing the underlying VM, updates, security, DR etc. The Azure Docker Extension can be used to install docker on the VM at deployment time.

Orchestrators

When you move beyond running a couple of containers and need to be able to control multiple containers, running in production with resilience and high availability, then you need to start looking at using an Orchestrator. Again, there are numerous options for hosting orchestration tools in Azure.

Azure Container Service (ACS)

https://azure.microsoft.com/en-gb/services/container-service/

ACS was the original container orchestration service in Azure. ACS allows you to create a container orchestration cluster running one of Docker Sware, Kubernetes or Mesos. ACS is an interesting solution in that it is deployed like a PaaS service, but what gets implemented is a set of IaaS infrastructure (vNet, NSG’s, virtual machines etc.) which has been pre-configured to run your selected orchestrator. While the platform will set it all up for you because it is IaaS you are still responsible for managing the VM’s, updates etc.

ACS is being replaced by AKS and will be removed around 12 months from the GA announcement of AKS. As such I do not recommend making use of ACS for new workloads. Instead, use AKS or ACS engine (see below).

Azure Kubernets Service (AKS)

https://azure.microsoft.com/en-gb/services/container-service/

AKS is Microsoft’s semi-managed Kubernetes service and is the replacement for ACS. Where ACS supported three orchestrators, in AKS Microsoft, have made the (somewhat safe) bet on Kubernetes and this is the only orchestrator available. Where ACS deployed all IaaS infrastructure, AKS does offer part of the service as a managed PaaS offering. When you use an AKS cluster the Kuberntes master nodes are hidden from you and are operated by Microsoft, the only VM resources you see are the worker nodes, which are still IaaS and need to be managed and updated as usual. In AKS you are only paying for the worker nodes, the managed part is free.

AKS is relatively new and is still in preview (with GA expected shortly), because of this it does not yet support all the features of ACS. In particular, Windows container support is missing. If you need Windows support, you would need to look at ACS engine.

Azure Container Service Engine (ACS Engine)

https://github.com/Azure/acs-engine

ACS Engine is a toolset that both ACS and AKS are built on top of, and which has been open sourced for anyone to use. With ACS engine you can use JSON files to detail the configuration of your orchestrator, then run ACS Engine to have it generate ARM templates which you can then deploy to Azure. The result of ACS engine is a container orchestrator running on IaaS infrastructure that is all customer managed (no PaaS service here). The benefit of ACS engine is that you can use it to create clusters that aren’t currently supported in AKS, things like Windows containers, or mixed Windows and Linux clusters, later or beta versions of Orchestrators, support for Orchestrators other than Kubernetes etc. If you need to use any of these options that are not supported in AKS or you want more control over the orchestrator cluster that gets created then ACS engine would be the choice for you.

Service Fabric

https://azure.microsoft.com/en-gb/services/service-fabric/

Service Fabric is Microsoft’s Microservice platform, but it now also supports running and orchestrating containers. If you’re purely looking at .net applications, and you want to take advantage of some of the programming paradigms like reliable actors, then this is the platform to use.

Other Services

Whilst not running containers, there are also products which provide service that will be useful to you when deploying containers into Azure.

Azure Container Registry (ACR)

https://azure.microsoft.com/en-gb/services/container-registry/

ACR is Microsoft’s solution for private container registries. Using ACR you can create a registry and then have your AKS cluster connect to it using Azure Role Based Authentication. ACR also supports geo-replication, so if you are running multiple global clusters for DR or performance, then this provides an easy way to distribute your images.

Azure Files and Managed Disks

https://docs.microsoft.com/en-us/azure/aks/azure-disks-dynamic-pv

Azure Files and Managed Disks have been around for some time and are used heavily outside the container world, but for containers, they provide useful tools for persisting data. ACI can make use of Azure file shares for persisting data, whereas AKS and ACS can make use of both Azure Files and managed Disks, giving options for increased performance for container storage with premium disks, if required.

Summary

There are a good deal of options for deploying containers in Azure, and I suspect more will be coming in the future. It can seem a little overwhelming trying to decide which to use, but each does have its own niche, and with an understanding of this you can determine which is best for your use case. I’ve summarised below the tools to use for each type of use case.