I have a love/hate relationship with Windows containers. On the one hand, it is great that we have an option for containerising legacy applications that are dependant on things like the full .net framework or other Windows-only features. On the other hand, Windows containers have some many limitations and issues compared to Linux containers, that working with them becomes painful. These limitations include what options you have for hosting these contains when you want to run them in Azure.
If you are working with Azure then ARM templates are a great way to define your resource and deploy them declaratively. However, if you find you need to do anything other than creating Azure resources as part of your deployment, then you are a bit stuck, as ARM templates don't offer any way to call external resources or run scripts. An example that we will use for this rest of this article is something I needed to do recently.
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.
Microsoft today released a public preview of a new service, Azure Container Instances. This may seem confusing initially, Azure already has a container service called Azure Container Services (ACS), but this is a somewhat different offering. ACS is a full container hosting solution, including orchestrators, deployed on top of multiple IaaS based Azure Virtual machines. Azure Container Instances (ACI) is not an orchestrator, it is a platform for deploying containers quickly and simply.