Back in the mists of time (otherwise known as 2018), I wrote a post called Azure Container Hosting Demystified which looked at the different container hosting options in Azure, what they are and why you might use them. Four years have passed since I wrote that article. Things have moved on a lot, so it’s time for an updated version.
If you have container workloads you want to host in Azure, then there are many different options for doing that, and it can be pretty confusing trying to pick out which one is right for your project.
This week we saw the announcement of the public preview of Windows Server Containers on Azure Kubernetes Service (AKS). Windows support in AKS has been something we’ve been waiting for, for a while now and is excellent news for those trying to lift and shift Windows applications into containers. As we’ve discussed previously, if you can, using Linux containers is always going to give you the fastest start-up time and fewer complications, however not everyone can re-write their apps in .
If your application is running on a Kubernetes cluster in Azure (AKS, ACS or ACS Engine), then it is likely that you will need to access other Azure resources from your pods that are secured with Azure AD. These operations could include retrieving secrets from Key Vault, files from Blob storage or just interacting with other applications or API’s that use Azure AD as their identity provider. To be able to do this your application needs to be able to provide an identity to access these resources securely.
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.