AWS introduced a couple of container-related technologies at re:Invent 2017. The first was Amazon Elastic Container Services (ECS) for Kubernetes, or EKS for short. The other announcement was AWS Fargate — a new product designed with the promise to deploy and manage containers without having to manage any of the underlying instances.
With AWS Fargate, all you need to do is build your container image, specify the CPU and memory requirements, define your networking and IAM policies, and launch.
My tweet from re:Invent about EKS and Fargate seemed to resonate with others in the community who were following the latest AWS announcements:
First and foremost, I want to emphasize that an existing container-based application does not become serverless just by using Fargate.
Secondly, I was a little wrong in my initial assessment about Fargate. It’s not a service. It doesn’t have an API. AWS calls it a “technology”. It’s only usable through ECS — and eventually, EKS.
So for ECS, you’re still using clusters, tasks, etc. You’re still defining your application-level architecture using ECS the same way — but you’re not running or managing EC2 instances as part of your usage of ECS.
This is in contrast to Azure Container Instances which is more in line with what I thought Fargate was going to look like — an API similar to EC2, but operating on containers rather than instances. There’s a good twitter thread here wherein smart people Jessie Frazelle and Joe Beda discuss lots of
Fargate is still a big deal!
The container technology means a bunch less infrastructure management and lower operations burden. In fact, the need for orchestration (container or otherwise) in a server-based system means that Azure Container Instances probably aren’t the right primitive to use in a large-scale application — which is why Azure has AKS.
With Fargate, your application can have zero EC2 instances. Doesn’t that mean it’s serverless? You can probably guess the answer.
This brings me to another tweet that struck a chord:
Containers are orthogonal to serverless-ness. They are, from a high-level application architecture perspective, VMs — just extremely lightweight VMs.
Their ability to be started and stopped, created and thrown away is one of the things that enables many implementations of serverless platforms. But if you start one up and run a Node process that listens for requests, handles multiple requests simultaneously in the same process, and sits idle if no requests are made — that’s a server.
Part of the problem is that people are conflating the application notion of a server which is about software — with the infrastructure notion of a server which is about instances and/or heavyweight proper VMs.
Serverless is about having neither. Not having VMs in EC2 is not sufficient to be serverless. Azure Container Instances demonstrate this well — containers are really not that different from instances.
So what should we call Fargate?
Not having VMs is about managed infrastructure — not having application-level servers is about managed code. If you have neither, you’re serverless.
But what if you’re running application-level servers on completely managed infrastructure? I’m not sure we need a term other than “managed infrastructure” — especially because we don’t want people to stop there.
Future article: the danger of people getting complacent running FaaS software on managed Kubernetes thinking they are serverless.
While I used fairly black-and-white language in this article, the edge cases are always messy — and that’s why serverless is a spectrum.
The Serverless Spectrum
Like so many things in life, serverless is a spectrum with multiple dimensions along which the degree of each can vary
What’s your thoughts on AWS Fargate, and the difference between managed code and managed infrastructure, and the spectrum of serverless? Drop a comment below or connect with me on twitter!