Azure Container Instances: All you need to know

Docker CEO Ben Golub was asked in a recent interview how his company can make money off of an open source product. A good answer would have been, “If there’s no money in it, why are Microsoft and Oracle interested?” According to one recent survey, over 30 percent of respondents claimed to be spending more than half a million dollars on container licenses and usage. And not coincidentally, Microsoft recently announced Azure Container Instances, which are supposed to make deploying containers a lot easier.

As anyone who goes down the container and microservices architecture road must soon find out, everything is not open source and customized solutions always cost money. One way of looking at it is like airline tickets where the basic community editions and open source versions are your economy tickets and the first-class seats is where all the paid stuff is at. It can obviously get a lot more complicated than first-class and economy seats, especially since a lot of the time with new technology you don’t even know which airline you’re or where you’re supposed to get off at, for that matter.

Microsoft gets on the money train

Azure Container Instances

Everyone agrees containers are great, and everyone wants to be deploying their apps in containers to be cool and hip and highly productive. Microsoft is spending $370,000 a year to be part of the cool-kids club and hang out with all the open source people. As mentioned earlier, if there was no money in it, Microsoft would not be interested. Microsoft has been all over it for a while now and is doing everything to stay on it. Those efforts include declaring love for Linux, becoming a platinum member of the CNCF, which is where that cool $370,000 annual price tag comes into the picture, and not to forget the recent Deis acquisition.

So what’s the big idea about Azure Container Instances? After all, Azure Container Service already exists. The idea is to make deployment even simpler by abstracting away the infrastructure and providing users with a sort of “serverless” deployment of containers. Azure’s product manager for containers described ACI as “the invisible infrastructure and micro billing of serverless without forcing the event-driven programming model.” ACI also uses the Azure command line and comes with an easily scriptable set of commands by which containerized applications can be rapidly created and launched right from the command line.


Azure Container Services (ACS) works by building VMs around your containers, which comes with quite a big resource footprint and effectively eliminates one of the main advantages of containers in the fact that they’re extremely lightweight, fast, and go easy on resources. The funny thing here is that your Azure Container Instances will still run on VMs, except they’re running in the background and not something that you need to look at anymore. There is some speculation that this could indicate Azure Container Instances is using Hyper-V containers, which is funny again because we’re now effectively running Linux images on a feature of Windows Server running on Linux, because it’s supposed to be more secure than running them on Linux itself.

Although this sort of falls into the “VMs for Containers-as-a-Service” and not “Containers-as-a-Service” like a lot of people were probably expecting, startup time is supposed to be quicker than regular VM based containers. In fact, one of the plusses of Azure Container Instances is the speed at which containers start up — Microsoft says ACI containers start within seconds. There’s also another service that lets you deploy containers as Azure Web Apps, and Azure Container Instances is the fastest way to deploy containers on Azure out of all three. That, and the fact that it comes with container management commands and works with Kubernetes, makes it an interesting choice indeed.

The reason that deploying a container from an existing repository happens within seconds in spite of the fact that it’s still running in a VM is because instead of building an underlying host VM, ACI just assigns an existing VM to your container. The beauty of this new offering from Microsoft, apart from the fact that it’s billed per usage, is really that while ACI currently only supports Linux containers, Windows container support is expected in the next couple of weeks.

Pay-as-you-go containers

Can you believe Microsoft releasing something that supports Linux before it does Windows? Times are changing, indeed. With regards to billing per usage, ACI comes with a billing model that’s based on per-second usage, which translates into a lot of savings with regards to paying for the upkeep and maintenance of servers. The billing is bifurcated into memory and cores used per second, so if you’re scaling up it would be a good idea to keep an eye on the meter while it’s running. Additionally, the request used to deploy a container can also include a definition for the number of cores and memory it needs.

A lot Microsoft’s initial documentation for ACI assumes that it’s going to be used as a host for scalable web services and applications, which is probably what it’s going to be used for a lot. It’s also probably going to be used with Kubernetes to burst-scale applications and services.

Azure Container Instances and Kubernetes

Azure Container Instances

You can’t have a container party and not invite Kubernetes, and there’s an ACI connector for Kubernetes that lets you have both ACI and ACS in the same cluster, a sort of hybrid container setup within Azure. This ACI connector for Kubernetes is an open source project hosted on GitHub and lets Kubernetes deploy straight to ACI, where ACI functions like a kubelet gets registered as an unlimited-capacity-node.

Since it’s an open source project, future support for Mesos, Swarm, and others is also expected. The best part about the ACI connector is you don’t even need to be running Kubernetes to run it. Once running, you can use Kubernetes commands from your ACI account to create and destroy containers at will. Microsoft has been all about support for Kubernetes for a while now, and ACI looks like it will be a great tool once production ready.

Promise of PowerShell

Additionally, Microsoft has promised PowerShell will be added to Cloud Shell and the Azure CLI. PowerShell is a task automation and configuration management framework from Microsoft, consisting of a command-line shell and associated scripting language built on the .NET Framework and .NET Core. There’s a lot of scope for automation here, mainly because PowerShell ensures you’ll have access to the most common automation tools for managing Azure resources from virtually anywhere, and secondly because the Azure CLI is based on Bash, which is extremely well suited for coding.

All in all a great effort from Microsoft to take container technology, which is still intimidating to a lot of folks, and turn it into something user friendly, but with some depth at the same time. With the way things are going, we’re probably going to be seeing a lot of new container-based services from Microsoft built around this one. Who knows, one day they might just do away with the VMs altogether.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top