With Docker Containers, you can run them locally on your development machine but when you are ready to deploy the containers to the cloud, you are going to need a server for them to run on and Azure offers several different options for hosting the containers.
- You could create a Virtual Machine in Azure and install Docker on it. Then, when you want to run a container, you can simply run Docker commands to that VM and ask it to create an instance of your container image. And you could also run multiple containers on a single VM, but there is a backlash to it. You do not have a Virtual Machine that you need to maintain and keep paying for even if it’s running any containers or not.
- The second option is to use a container orchestrator. Here, you have a cluster of virtual machines usually called nodes, each of which is able to run containers, and then you have an orchestrator that decides which of your nodes in your cluster should actually run the containers. By doing that, you can tell it which containers form your application, and often for the purposes of resilience and scale, you can ask it to run multiple instances of some of your containers and also spread them out across the cluster. The most famous orchestrators which all of you must have heard is Kubernetes and Azure makes this very easy to use with the Azure Kubernetes Service. AKS gives you a managed instance of Kubernetes that you don’t need to install on your own. With this service, you have to pay for all of the nodes in your cluster and you need to pay whether they are actually running any containers or not.
- You can also host your containers in Azure App Services if you want to host your web apps as containers.
- Azure Batch to host containers is used if you need to work through a queue of batch jobs.
- Azure Service Fabric is there to help you build highly distributed and scalable applications. In fact, Azure Service Fabric is an orchestrator that is designed by Microsoft itself.
So, these are five different ways that you can get your containers running in Azure. Then how do the Azure Container Instances come into the picture?
One thing that all the above five mentioned options have in common is that they assume that you have already deployed the container hosting infrastructure to Azure even before you actually run your containers. For instance, I have some containers that I want to get running in Azure. Suppose I don’t a VM running Docker or a Kubernetes cluster then I will have to create one of those first and then I will have to deploy my container and that is going to take some time before I am ready to run my container.
Just in case I already have a Docker VM or a Kubernetes cluster, there are chances that it has already something running on it, some that it was originally created for. So, I would not want to re-use my existing Docker VM. Imagine having a serverless way to run your containers in Azure. You can just go and tell Azure that here is my container image, run it. Then Azure would go and spin up a new container instance on a VM that it (Azure itself) controls. This is exactly what Azure Container Instances allow you to do. You really don’t have to manage Docker servers or Kubernetes clusters. You just need to specify the container which you want to run and Azure will provide the compute that actually runs it, all behind the curtains.
And yes, one of the greatest benefits of using this is that you only pay while your container is running. Azure Container Instances have a per-second billing model. Suppose you only need some container running for 7 minutes, you create it, let it run for 7 minutes and then stop it. That is all you have to pay for. You also don’t have to worry about shutting down the virtual machine that was running the container when you are finished with it.