Azure Container Apps is the Microsoft solution for PaaS Kubernetes, abstracting away the Kubernetes layer to allow the user to focus on delivering their container-based applications. It’s a relatively new service, released last year, and has a few missing features or areas where things could be added. Over the last couple of months, there have been several announcements and updates for ACA that fix some of these, culminating in last week’s Build conference where we saw quite a few announcements.
Azure App Service has supported running containers for a while now, both in standard App Service and in Azure Functions. Setting this up through the UI is pretty straightforward, however, creating the same setup using Infrastructure as code can be a bit tricky. There are several different configuration settings that need to be added that are not always obvious. In this article, we will cover them what these are and when to use them and put them all together in one place.
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.
Azure Container Apps were recently announced at Microsoft Ignite, let’s take a look at what they are, how they work and why you might, or might not, want to use them.
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.
