Serverless Containers with Azure Container Instances

Regular readers of my blog will know that I'm very interested in the ideas of serverless architectures and containers. Azure offers many services that enable both both. For serverless we have Azure Functions, while for containers there's the Azure Container (Kubernetes) Service which looks very promising. And there are multiple other Azure services enabling both serverless and containerized approaches.

Serverless + Containers = ACI

But I suspect like many people, I've been hoping that something would come along that combines both the ideas of "serverless" and "containers", and Azure Container Instances is exactly that. With Azure Container Instances you can run containers without needing to manage, or even to pre-provision any servers. Just ask for your container to run, and let Azure worry about where it is hosted.

ACI also uses a serverless pricing model. I only want to pay for what I use. Instead of having a bunch of VMs that I have to pay for even if they're sitting idle, with ACI, the billing model is per-second. I pay only for the time my container runs.

ACI Capabilities

Azure Container Instances already support both Windows and Linux containers, and for cases where you need a more powerful server, they let you specify how much RAM and how many CPU cores you want allocated. Your containers can have public IP addresses, and use images from private repositories.

You can mount Azure File Shares as volumes, and several other volume mounting options are available, including cloning a Git repository which opens up some interesting possibilities. Hopefully a way to mount subdirectories within File Shares, or mounting blob storage will follow soon.

There's a concept of "container groups" where you can run a bunch of containers co-located on the same host. I'm not 100% sure exactly what the intended use case for this is, and it currently requires you to deploy with ARM templates which isn't particularly user friendly, but I have successfully deployed Wordpress and MySql in a container group (blog post to follow soon!).

ACI is still in preview and there are a few missing capabilities. At the moment, there doesn't seem to be an easy way to restart a stopped container, or execute a command against an existing container. Virtual Network integration is also not available yet.

Get Started with the Azure CLI

If you want to try Azure Container Instances out, it really is remarkably easy. You just need to know how to use the Azure CLI, and then its literally one command. OK, two if you count creating a resource group to put your container in first!

Here's a very simple demo that I used for my recent talk at the Docker Southampton meetup. It deploys the miniblog.core ASP.NET Core application in a Linux container:

# create a resource group
$location = "westeurope"
$resourceGroup = "miniblogaci"
az group create -l $location -n $resourceGroup

# create the container
$dockerRepo = "markheath/miniblogcore:v1-linux"
$containerName = "miniblogcore"
$dnsName = "dockersoton1"
az container create -n $containerName --image $dockerRepo -g $resourceGroup `
                    --ip-address public --ports 80 --dns-name-label $dnsName

What about if you wanted to run a Windows container instead? That's easy enough - just point at a Windows container image and use the os-type Windows flag:

$dockerRepo = "markheath/miniblogcore:v1"
$containerName="miniblogcorewin"
az container create -n $containerName --image $dockerRepo -g $resourceGroup `
                    --ip-address public --ports 80 --os-type Windows

Here's a quick demo I made of creating this container with the Azure CLI:

What should I use this for?

Is ACI the future of running Docker containers in the cloud? Well no, it's not a great choice for long-running containers (e.g. websites), as it will typically be more cost effective to run those on your own Docker host shared with other containers. Where the cost benefits shine is for short-lived workloads, where most of the time you're not doing anything, but suddenly you need to do some work. Good examples might be CI builds or media transcoding tasks. In these cases, you want a container that runs for a short period of time, but after its finished there's no need to keep paying for compute resource.

ACI is also not intended to replace container orchestration technologies like Kubernetes. But it could be used as a quick way of adding extra capacity to a Kubernetes cluster, enabling it to cope with short-lived spikes in demand. This could give you the best of both worlds - cost effectiveness for hosting long-lived containers, but with the ability to rapidly scale up and pay only for the excess capacity that you actually require to handle peak loads.

ACI and Azure Functions

How does ACI fit with Azure Functions? I remain a big fan of Azure Functions, and it's my go-to platform for serverless workloads in the cloud, but there are occasions when a containerized "function" would be a better fit. For example, the Azure Functions runtime currently limits you to 5 minutes runtime for a function (at least in consumption mode), restricts what you can install on the host server, and doesn't let you mount Azure File Shares. So an ACI container could be used to implement serverless tasks that don't fit so well with the existing functions runtime.

In fact, I think that ACI could play really nicely with the new Durable Functions extension to Azure Functions. I do a lot of work with media processing pipelines and some of the activities in a media processing workflow would be better suited to running in a container than being written as a regular Azure Function. It would be great if Azure Functions offered an easy way to trigger a workflow activity as an ACI container, and could be notified when that container finishes (maybe via an Azure Event Grid notification.

Anyway, it's exciting to see the possibilities that are being opened up by the worlds of containerization and serverless colliding and I look forward to seeing how the likes of ACI, AKS, Durable Functions and Logic Apps evolve to give us a truly productive and cost-effective platform for running all kinds of serverless workloads.