Understanding Azure's Container PaaS Capabilities

If you've been using Azure over the past twelve months, you can't but have the feeling that it's become a bit like this...

.. and you'd be right.

To be fair, though, Containers have been one of the hot topics in computing in general and certainly one that's been getting the most interest in my recent Azure Open Source Roadshows.

One thing that has struck me though is that people are not clear on the purpose of all the services in Azure that have 'Containers' listed as a capability, so in this post I am going to try and review the Azure Platform-as-a-Service offerings that have Container capabilities and cover what the services can be used for.

First, before we begin, let's quickly get some fundamentals under our belts.

What is a Container?

Containers provide encapsulation and isolation for workloads and remove the need for a complete Operating System image to be deployed in order to manage resource allocation.

They have proven popular because they typically have smaller footprints than Virtual Machines, boot much faster as a result and have a modern build process based on composition that gels well with software development.

A Container still needs to "run" somewhere - this "somewhere" is what I will call a "Container Host" through the rest of this post.

So where does Docker fit into all of this? Docker provides tooling for the creation, running and management of Containers and is by far the best known tech in this space. Microsoft has worked with Docker to ensure the Docker tooling supports Windows and Windows Containers.

Our most basic Container workload setup then would be: one Container Host running one Container.

What is a Container Orchestrator?

A big part of running Containers at scale is their management which is where technologies like Kubernetes (k8s), Docker Swarm and DC/OS come into play. These technologies allow you to manage multiple Containers and their workloads, performing orchestration of deployments and controlling connectivity between Container instances running on Container Hosts.

An Orchestrator typically runs more than one node to ensure availability, but nothing stops us from running a simple single node setup like Minikube to start to learn about them.

Right, now we have some fundamentals in place, let's take a look at what Azure offers.

Azure's Container Offerings

Note that we are going to focus on PaaS services - you can of course still run Containers on Virtual Machines, or deploy something like OpenShift in Azure if you wish.

Please note: any service listed as 'Preview' should not be used for Production deployments!

Azure Container Registry (ACR)

What is it? ACR is an Azure-hosted Container Registry based on the open-source Docker Registry v2 spec. This is a turnkey part of Azure's Container story.

Why use it? When you build a Container Image you need a place to store it. Docker Hub is the Registry where you pull all your public Images from and which is run by Docker. ACR provides you with a private Docker-compatible Registry that you can push Images to and use as a deployment source.

Benefits:

Private Registry you configure that is not published on a well-known endpoint that is a source for public Images
Provides a unique *.azurecr.io Registry endpoint which can be used to store Images that can be deployed *anywhere* (not just Azure)
Webhook support that can be used for Continuous Deployment, particularly with Azure's Web Apps for Containers (see below)
Control access to the Registry using Azure Active Directory Credentials
ACR provides seamless authentication (i.e. no configuration) with other Azure services like Azure Container Instances, Azure Container Services, App Service and Batch.
Geo-replication is the hotness! (requires Premium level) * Preview

Restrictions:

Cooler features (like geo-replication) are at higher price point only
I'm struggling here for others! :)

> ACR Documentation.

Azure Container Instances (ACI) * Preview

What is it? An Individual Container Host that can run one or more Container. No need for you to manage the Host.

Why use it? These are probably the easiest way to get going running Container-based workloads in Azure. If you have a simple workload that needs a public IP and which can talk to various Azure PaaS services then consider ACI over Web Apps for Containers or Azure Container Service.

Benefits:

No need for you to manage the Container Host - tell it which Containers to run and that's it!
Pay per-second for use with customisable CPU Core and memory options
Supports multiple Containers in single ACI Host
"Whole of Azure" scale: deploy ACI workloads in any Azure Region (where ACI is available).

Restrictions:

No production Orchestrator support: there is an experimental Kubernetes Connector, but apart from this you cannot bolt an ACI Host into an Orchestrated environment
No VNet support: you can't connect an ACI Host to Azure VNets.

> ACI Documentation.

Web Apps for Containers (App Service on Linux)

What is it? A Container Host that runs on a Linux-based variant of Azure's App Service that is aimed at web-centric workloads (hence the name). Like ACI, you still don't need to manage the Host.

Why use it? If you have a website or HTTP API workload you traditionally host on Linux and that you can (or have) containerised, then this is a good spot to start as it limits your workloads exposure to HTTP (80) and HTTPS (443) ports.

Additionally, even if you haven't containerised your solution, you can still use this service to host it. When you select a framework to use to host your solution (like Java or PHP) the framework is deployed to Web Apps for Containers as a Docker Image!

Benefits:

Get access to standard App Service features like Autoscale, Custom Domains, SSL and Continuous Deployment
No need for you to manage the Container Host - tell the Web Apps Instance which Container to run and it will do that
Deploy existing Docker images from Docker Hub, Azure Container Registry or from Azure's pre-built framework images
Troubleshoot containers using SSH from Kudu.

Restrictions:

No Orchestrator support: what you gain through using App Service you give up in not being able to bolt the Container Host into an Orchestrator like Kubernetes
Multi-Container deployments are not supported
Not all Windows-based App Service features are supported (yet)
Not currently supported in App Service Environments.

> Web Apps for Containers Documentation.

Azure Container Services (ACS)

What is it? A service that allows you to run Container Hosts that are managed by an Orchestrator of your choice (Kubernetes, Docker or DC/OS).

Why use it? If you already run Container workloads on VMs (regardless of hosting location) that use an Orchestrator, or you'd like to start using Containers at scale and need an Orchestrator, then this is the service to use.

Benefits:

No need for you to manage the underlying Virtual Machine infrastructure
Orchestrator and Container Host setup is managed for you by the ACS engine (which is open source)
Container Host scalability is supported via use of Virtual Machine Scale Sets (VMSSs)
All hosts (Orchestrator and Container) are vanilla instances - this is not a special "Azure release"
Orchestrators have Azure extensions allowing them to perform actions such as creating Azure Load Balancers when you specify load balanced workloads in your setup.
Integration with Azure Container Registry for Image deployments.

Restrictions:

You pay for both the Container Hosts and Orchestrator Nodes (they are just VMs after all)
You can't increase the number of Orchestrator / Cluster Masters after you have initially created an ACS cluster
You can't upgrade the Orchestrator once you have created an ACS cluster - you need to create a new ACS cluster to gain access to a newer release.

> ACS Documentation: Kubernetes | Docker | DC/OS.

Azure Container Services - Managed Kubernetes (AKS) * Preview

What is it? This service is similar to ACS (above), however in this service (which only supports Kubernetes) the Orchestrator Nodes are managed on your behalf by Microsoft.

Why use it? If you are invested in Kubernetes (or intend to use it as your Orchestrator) and would prefer not to have to manage the Orchestator Nodes then you should select this over standard ACS with "unmanaged" Kubernetes. If you are using the ACS Kubernetes offering already then this is a logical place to migrate to once AKS is Generally Available.

Benefits:

You don't pay for the Orchestrator Nodes running Kubernetes
Orchestrator Node availability, patching and upgrading is managed by Microsoft
No need to create a new ACS cluster to pick up new Kubernetes releases
Will support 100% of the standard Kubernetes API
All other ACS features remain in place!

Restrictions:

Only supports Kubernetes!
During preview does not support all Kubernetes features.

> AKS Documentation.

On a side note: AKS + ACI (with its Kubernetes connector) + ACR will be an amazing PaaS Container story once all these components are all Generally Available! :cool:

Azure Service Fabric

What is it? Service Fabric is both a cluster Orchestrator and a development framework for delivery of highly available, distributed applications. It pre-dates the current Container hype cycle and is used to deliver services in Azure such as CosmosDB.

Why use it? If you want to leverage the Reliable Actor and Service patterns offered by the Service Fabric development framework. Also worth considering if you haven't yet started with an Orchestrator like Kubernetes.

Benefits:

Mature product that underpins key Microsoft cloud-scale services
Runs in Azure or on-premises.

Restrictions:

Container workloads can't benefit from the development framework as they run as 'guest executables' on cluster nodes (this will change in future as you will be able to Containerise Reliable Actors and Services)
Developers using Windows 10 can't deploy Container-based solutions to local Service Fabric clusters.

> Service Fabric Container Documentation.

Azure Batch

What is it? The name says it all really - you can use Azure Batch to run compute workloads that can be broken into lots of concurrent processes. Examples include payroll runs, animation rendering or research modelling. Batch sits well within the High Performance Compute (HPC) landscape.

Why use it? If you have a batch-style workload with processors that can be Containerised then this is a service you should seriously be considering. More-so if you wish to consider a hybrid scenario where you run some of your workload in-house and burst to Azure as required. As you have Containerised workload you can ship dependencies in a single bundle.

Benefits:

You can use Docker Hub as a source for Images (yes, you could pull tensorflow and run it in Azure ;) ), in addition to ACR and any other compatible Registry
Use Singularity in addition to Docker Containers with Batch
Run processes on low-priority VMs to reduce the cost (best for non-time sensitive operations).

Restrictions:

RDMA (high performance networking) support only available for Containers running on Linux.

> Azure Batch Container Documentation.

So there we are - hopefully the Azure Container story now makes much more sense and you can pick between the services to understand those that would be most appropriate to your use case.

Happy days! 😎