What kind of Container Services are available on Azure?

Containers came to revolutionize how we ship software, and with the hype that Kubernetes has created, almost all technology companies are looking forward to starting their modernization journey with containers.

Several companies are already there, others have already given up, and a few of them have workloads where containers aren’t a great fit.

If you’re just starting, I’d recommend you use managed services. You’ll already have enough complexity trying to modernize or migrate your workloads to containers. The problem is that in public clouds like Azure, there are a lot of options to run or use containers. When you want to create a new resource and click on the “Containers” option, you’ll see at least four options, but there are a few more.

In this post, I’ll describe all available container service options at the moment, how to use them, and when I’d recommend you use them.

Let’s get into it!

Take part in our latest Microsoft Azure Salary Survey here!

Azure Container Registry

One of the first services you have in Azure is the Container Registry. Although this service isn’t for running containers, it’s a service for storing your container images privately and artifacts like helm charts. Moreover, this service has features such as replication for storage redundancy.

You can build and test your images as well, but more importantly, you can configure the registry to integrate it with AD, sign images, and scan images to find vulnerabilities (in preview). Regarding pricing, there are three tiers with a baseline of storage and container build minutes. If you need more storage or minutes, you only pay extra for what you use.

When you create a new registry, you need to take note that you have to use a unique name across Azure. You’ll get a DNS name under azurecr.io, and that’s the domain Azure uses for all its customers. You then define the resource group, location, tier, subscription, and whether you need an admin user or not. After a few minutes, you’ll see something like the following screen:

Notice that you can integrate third-party services like Aqua Security and Twistlock, or configure tasks to build container images after developers push Dockerfile changes into a Git repository.

I’d recommend you use this service if you want to have a private container image repository, and want to integrate it with your AD. It’s also an excellent service to be part of the continuous integration phase while you’re preparing the application artifacts, before the deployment to any environment.

Azure Web Apps

Azure WebApps was one of the first services in Azure. You don’t have to worry about managing servers, but the problem is that the options for running applications are quite limited.

That’s why Azure decided to allow you to continue using WebApps features like scaling, deployment slots, or backups. You’re the one that defines the platform and dependencies of your applications with a Dockerfile.

If you’re new to Docker, this service is an excellent fit because you only have to worry about your Dockerfile. You can integrate it with your private registry or the public one from Docker.

In case you need to use more than one container, you can configure the service to run with multiple containers. Similar to Docker compose, it means you can have the same experience in a local environment. Also, you can configure a CI/CD pipeline to deploy application changes automatically after every push in a Git repository.

I’d recommend you use this service if the application is small, simple, and you’re starting with containers.

Azure Kubernetes Service (AKS)

Next in the list is Kubernetes. Having many components in Kubernetes’ architecture makes installing, configuring, and operating a cluster a complicated and sometimes unnecessary task for IT pros. Kubernetes Azure Service or AKS will take care of that.

You don’t have to worry about the control plane, as Azure will take that responsibility for you. Azure will even take care of tasks like patching for the nodes, the data plane. You’d be interacting with the cluster using the existing Kubernetes API.

Regarding pricing, you only pay for the nodes you provision, and the control plane is free. So, depending on the node types you use, that’s how much you’ll end up paying. Moreover, VM reservation applies to Kubernetes nodes as well.

AKS supports enterprise features like monitoring, autoscaling with scale sets, and having multi-node pools for workloads that need different types of resources. You can separate workloads at the node level, either for application or OS type. This means that AKS has support for Windows nodes. Additionally, you can even integrate AD with Kubernetes.

If you want more, and to help developers with their inner-loop or for troubleshooting purposes, you have Azure Dev Spaces. Developers can connect to a cluster in Azure and debug a microservice locally using Visual Studio or Code. You can also configure CI/CD pipelines with Azure Pipelines and include stages for testing or security purposes.

I’d recommend you use AKS for more complex applications that have multiple components. For instance, distributed systems architecture like microservices.

Creating a cluster takes a few minutes, and scaling out could take some time as well. For that reason, AKS now integrates with container instances, which is the next option in this post.

Azure Container Instances (ACI)

Container Instances might be one of the most interesting ways to run containers in Azure, and here’s why. When you use Container Instances, you genuinely forget about servers.

You only have to define where your container image is, how many resources you’ll need, which ports you need, and which environment variables (if any) you need. Azure will take care of provisioning the servers. More importantly, you only pay for the time the container runs. In other words, Container Instances are the serverless option to run containers in Azure.

But that’s not all. Azure started an open-source project to have a virtual kubelet in Kubernetes.

Azure is using this project to scale more rapidly in AKS. When you enable the “virtual nodes” option like the image below, and when AKS nodes don’t have more resources available for pods, AKS will create as much Container Instances it needs to fulfill the scaling need. This is an excellent integration and feature for spiky workloads, where you need to scale out as quickly as possible.

Microsoft, in conjunction with RedHat, created the Kubernetes-based event-driven autoscaling (KEDA) project. KEDA is a way to bring Azure Functions – event-driven applications – to Kubernetes. For instance, you can configure that after receiving a message in an Azure Storage Queue to run an Azure Function in Kubernetes.

It’s hard to recommend this service for only one use case. You can use Container Instances for the same reasons you’d use WebApps, with the difference being that you don’t have to worry about configuring scaling policies. Where this service shines is when you use it for scaling out an AKS cluster.

Azure Batch

Another option you have to run containers in Azure is Batch. Let’s say you need to process large data sets, and you have created a process that can handle small chunks of data. You can pack this process into a container image, and depending on the data you have, create as many instances you need to process data concurrently.

With Azure Batch, you only have to say: “Hey, create 100 jobs with these parameters,” and that’s it.

Batch will take care of provisioning the infrastructure needed. The benefit of using containers is that you don’t have to worry about creating a VM with all the dependencies the job will require. All application dependencies will be described in a Dockerfile.

Another option you have to run container-based batch jobs is to use Batch Shipyard. You don’t need to have experience with the Azure Batch SDK, as this tool works with configuration files to run batch jobs.

Moreover, Shipyard supports other container engines, such as Singularity or Kata Containers. If you need some examples of how to use Shipyard, there are several recipes in their GitHub repository.

You can use any of the services I’ve mentioned previously in this post, but the problem is that you’d need a tool to manage jobs like Flink. You can replicate the same functionality when using AKS and KEDA, but maybe you’re not even considering to use Kubernetes at all, so it all depends on your use case as well as your plans with containers.

Azure Service Fabric

A common question I am regularly asked is about where Azure Service Fabric stands now that we have Kubernetes. Well, Service Fabric is how Azure built most of its cloud services.

It’s a way to lift-and-shift legacy systems or a way to modernize systems to containers, especially in Windows environments. Containers in Windows are still maturing, and Microsoft has been investing a lot of resources for several years now to support Docker in Windows natively.

Windows nodes in Kubernetes are also available, and you can integrate AD with Kubernetes. So there’s progress, but it is not as mature as with Service Fabric – at least not yet.

The folks from the Kubernetes podcast recently aired an interview with Patrick Lang from Microsoft, who spoke about Windows containers. If you want a deep dive into this topic, have a listen to that episode as it’s very informative.

Microsoft is still working on adding features like the Service Fabric Mesh. In spite of these advances, I don’t foresee a future where folks consider Service Fabric as the first option to run containers. Kubernetes has won the orchestration battle – just look at how the number of attendees is increasing at every Kubecon.

So if you’re currently using Service Fabric and it’s working for you, I wouldn’t recommend you to switch to any other orchestrator if you don’t need to.

Which Container Service Option Should You Use?

At this point, you might be wondering which container service option best suits you? Well, it all depends on what stage of container adoption your team and your company are at.

Not everyone needs Kubernetes, and it’s okay to start simple and change as you need to. Avoid feeling the pressure of the industry saying that certain tools or practices will become the defacto standard.

I’m a firm believer that every technological decision you make needs to be backed by data. Every now and then new services will be available, but if you have a continuous improvement mindset, you’ll adopt new technologies at some point in time anyway.

To summarize all the service options you have, here’s a table that condenses all the information in this post:

Each of these services have additional features that I didn’t include, and a few of them are pretty similar and can provide a solution to the same problem but with different approaches depending on the service you use.

Always keep an eye on what Azure is doing, as they continue adding more services and features to existing services.