Azure Container Instances vs. AWS Fargate

Last week, during their re:Invent 2017 extravaganza, AWS announced their new container service Fargate. Fargate is AWS’s clusterless/serverless way of running containers. Fargate’s announcement was joined by the announcement for AWS managed Kubernetes clusters, dubbed AWS EKS and available only through sign up somewhere in 2018.

In a rare occurrence, it seems like AWS is playing catch-up with Microsoft’s Azure. Azure has had Azure Container Instances (ACI) in preview for the last months and has already rolled out managed Kubernetes (and DC/OS) as part of the Azure Container Services…ehm…service.

Fargate is brand new and currently only available in the us-east-1 region, but it’s still fun to compare it to Azure Container Instances as they seem to both target the same audience and provide the same value. But looks can be deceiving, as it turns out they are quite different beast! Shock, horror!

Getting Started

Let’s first see how easy it is to get from zero — where zero means you have an AWS and/or Azure account with appropriate rights — to a running container exposing a simple web page to the internet on both services.

Azure Container Instances up and running

ACI has no real visual setup wizard or GUI. Luckily the Azure CLI is pretty nice and getting a container running is really dead simple: two bash one-liners.

• Create a resource group
• Create a container instance

After this, a quick az container show informs me my service is available on address 52.191.116.216:3000. And yes, it also actually worked:

simple service running on Azure Container Instances

Fargate up and running

Let’s start with a minor niggle: according to AWS, Fargate “allows you to run containers without having to manage servers or clusters”. However, the first step in running a Fargate container is…creating a cluster! Ok, it is very quick and you don’t have to manage it, but still.

In general though, setting up a first running container on Fargate is a lot more involved than ACI. Using the AWS GUI, you go through the following steps, where each step can have a ton of options, drop downs and input fields.

• Create a cluster
• Create a task definition
• Create a container definition
• Create a service in your cluster: choose the Fargate type
• Choose VPC, subnets, security groups etc: make sure to select “Auto assign public IP”
• Choose one of four load balancing options: none, application, classic or network load balancer.
• Choose autoscaling, can be skipped

What is immediately clear is that Fargate is completed embedded in the current Amazon Elastic Container (ECS) service. You literally need to select it as a “launch type”, in contrast to the EC2 version.

ECS Fargate launch type

This means Fargate comes with all the configuration and setup flexibility/bagage attached. Not an issue an sich but to me at least AWS ECS was always cumbersome to set up and configure.

After finishing this setup procedure, the dashboard informs us the container is running. But where can we reach it? This had me stumped for a while: there was nothing in the UI and where using the applicable describe call in the AWS CLI there was nothing in the resulting JSON. Turns out out you have to navigate to the ENI (Elastic Network Interface) of the task in the service. This takes you to the standard EC2 console which lists the public IPv4 address!

An initial try didn’t result in a response. This was solved by adding port 3000 to the Security Group attached to the ENI.

simple service running on AWS Fargate

Note: this complete setup can be done using the AWS CLI, see AWS’s own write up here.

In Use

Now the containers are up and running, what can we do with them?

Azure Container Instances

ACI has no GUI really, only a read only screen showing the running containers, called “container groups” for some reason. This means you’ll be interacting with ACI using the Azure CLI, which is mercifully short on what you can actually do with an ACI container:

az container [-h] {show,logs,list,delete,create}

No stopping, no suspending, no scaling, no metrics, no updating, no volumes/disk mounting, no nothing. You can tail the logs and that is about it. This is immutable infrastructure brought to its logical conclusion! The fact that there is no scaling, as in starting multiple load-balanced versions of the same container is a big miss though, even in this MVP form of the service.

As such, ACI seems like an island in the normally pretty well integrated Azure landscape and I bet Microsoft is working on integrating their load balancing solutions and things like volume mounting.

update 9–12–2017: In the comments the ACI PM Sean jumped in and mentioned volume mounting DOES exist: https://docs.microsoft.com/en-us/azure/container-instances/container-instances-mounting-azure-files-volume These CLI parameters are however not listed in the CLI version I’m using.

Fargate

As noticed earlier, the setup is a lot more complex than ACI. But after jumping through all the hoops you do have a pretty flexible and well supported container platform with basically all ECS functions:

• Stopping, starting, scaling, autoscaling, scheduling etc.
• Load balancing
• Security Groups, IAM, roles etc.
• VPC’s, subnets, ENI, public IP’s, Volumes etc.
• Integrated CPU and Mem usage metrics.

As you probably have noticed by now, Fargate is not really a separate AWS service, although AWS does kind of present it as such: Fargate is a different container runtime for ECS. In your day-to-day usage, you use ECS not Fargate.

Performance

BIG CAVEAT: This is an anecdotal “performance test” at best. It is actually mostly a network throughput test…Still, I was curious if there where any obvious and huge differences in simple performance between both services.

My test service is a Node.JS Hapi application serving a simple page. Running an Apache Bench benchmark with 1000 requests and a concurrency of 5 over 10 runs gave the following results:

                               **ACI      Fargate**Requests per second (#/sec):     43.34      45.54  

Time per request (ms): 118.083 109.79799% (ms): 371 276

The results are really, really close. What was noticeable though was that Fargate/ECS seems to have less peaky behaviour, e.g. the 99 percentile was generally lower.

Pricing

Both services use a fairly similar pricing model where the main cost is a function of:

duration * containers * memory * CPU

ACI adds a “create request” cost of $0.0025 per created container. This sort of muddles the pay-per-use model based on resources, but probably not a big issue for most. Fargate containers are charged at a 1 minute minimum.

Here’s an example: you create 5 container instances with a 1 core, 2 GB configuration once daily during a month (30 days). The duration of each instance is 10 minutes (600 seconds). Fargate does not offer the combination of 1 vCPU / 1GB. The minimum is 2GB for a 1 vCPU container.

The cost in $ / month works out as follows:Azure Container Instances: $3.75AWS Fargate: $1.90

You can see the calculation for the above example in the Google Sheet I whipped for this post. Feel free to use it to do a price comparison for your own use case.

Azure Container Instances & AWS Fargate cost comparison_Sheet1 Example You create 5 container instance with a 1 core, 2 GB configuration once daily during a month( 30 days)…_docs.google.com

Note: This calculation looks only at the pricing for the given services and treats Azure cores the same as AWS vCPU’s. Also, AWS will prompt you to add other, paid-for, services like a load balancers to “complete the package”.

Conclusion

Diving into this comparison, I expected both services to be extremely similar. They are not. In their current incarnations both offerings have vastly different use cases.

Azure Container Instances almost felt as a service like Requestbin or JsFiddle. A quick and simple sandbox for running containers with almost Heroku-like behaviour: one bash command and your container is online. And I actually liked that a lot: I’ve never, ever launched a container to the internet in such a quick way. Probably even quicker than a local Docker instance with a service such as Ngrok. I can see myself using this during prototyping, when working remotely with clients or when I need to show a quick demo at a meetup or conference.

As AWS describes it, Fargate is a technology within ECS and later EKS. This means it sits in the DC/OS and Kubernetes space and comes with that feature set. As mentioned earlier, you don’t use Fargate day-to-day. It is there in the background taking care of managing your ECS cluster.

Azure Container Instances summary

• Seemingly stand-alone solution in the Azure eco system.
• 10 seconds, non-existent setup.
• Like a super light version of Heroku or JsFiddle for containers.

AWS Fargate summary

• Integrates into the existing AWS and ECS eco system almost everywhere.
• Confusing and cumbersome to get going.
• Would totally support huge, real word deployments.

Tim is a product advocate for https://vamp.io, the smart & stress free application releasing for modern cloud platforms.