You’ve likely heard the Serverless buzzword. Powerful but loaded. Are there really no servers? You may have heard of Fargate: AWS’s new container management product. With Fargate AWS manages your underlying container hosts & cluster for you… just drop your container in and forget it. No server to manage. Sounds “serverless”, doesn’t it? Manyhavepicked up on that: You’re starting to see the words “Serverless” and “Fargate” in the same sentence.
So is Fargate really “serverless”?
Debating buzzwords is not our favorite pasttime at Trek10, we’d prefer to just build. And serverless is a concept that can mean whatever you want it to mean. But there is a useful discussion underlying this debate: How do the benefits of Fargate compare to the benefits of a Lambda-based architecture? What characteristics from these services can have a meaningful impact on your business?
First let me be clear: Fargate is a really compelling addition to the AWS ecosystem. There are many cases where AWS Lambda just is not an option: legacy application migration, unsupported languages, long-running-processes. In these situations Docker is the best path to immutable and fully automated infrastructure. Historically, however, the added complexity of Docker host and cluster management had been a huge downside. Fargate takes that complexity away; now you can manage your container as a single layer of abstraction. Other things being equal, less infrastructure is an unequivocal good!
But calling Fargate “serverless” glosses over some very meaningful differences that keep Fargate significantly short of the promise (and years of reality, in Trek10’s experience) of Lambda-based “serverless”. Let’s go through a few of the key selling points of Lambda-based serverless architectures and how Fargate stacks up.
Fargate v Lambda
Some promises of Lambda-based Serverless, and how that promise plays out in Fargate:
Pay per request
Imagine your application gets 10,000 requests one minute, then 1,000 the next minute, then back to 10,000 the third minute, and on and on. With Fargate you are not going to configure auto-scaling that granularly, so you are going to scale your service to handle 10,000 requests per minute and keep it there. This means you will be 90% over-provisioned for 50% of the time, or 45% over-provisioned in aggregate. In this scenario with Lambda, you are still perfectly provisioned: 0% waste. Pay-per-request matters.
Forget about availability & fault tolerance
With Fargate your underlying hosts are managed, but if you only launch one Fargate container you are not highly available: no redundancy and only one Availability Zone. You have to make sure to set up subnets in multiple AZs, launch multiple containers, and configure Fargate to use those subnets.
Virtually unlimited scalability with almost zero effort
With Fargate your underlying Docker hosts auto-scale so you don’t have to worry about cluster scaling, but you do still have to worry about scaling the number of containers in your load balancer. Also known as service auto-scaling, this involves deciding on your scaling thresholds (i.e. if 60% CPU over the past 5 minutes, then add 2 containers) and making sure your health check parameters are appropriate so new containers come and go from the load balancer smoothly. In our experience this scaling configuration always comes with a fair bit of tweaking in production to get it right.
No patching
With Fargate you do not have to patch the underlying hosts, but you still have to worry about updating your container. And while it is lighter-weight, at the end of the day it is the same old story: watch for critical vulnerabilities, run your updates and test, plan your release. Don’t be too slow! Scramble when the big vulnerability is announced! And do you want to wait for the base image maintainer to release their update so you can update your tags? Or are you going to do your package updates in your pipeline? If so take care with how you install your updates so your image doesn’t grow too large! (All things you never think about in Lambda-based Serverless.)
No concurrency or contention
Functions are not isolated in Fargate. While scaling hopefully alleviates the challenge, you still have concurrent processes contending for shared resources in your container: how many threads can your container handle? Is one process stealing disk IO from the others? With Lambda-based Serverless, true isolation of execution functions makes this problem go away. The far simpler focus is making a single execution scale.
Revolutionary economics
Fargate pricing is based on CPU & RAM provisioned and billing is in second increments. Pretty nice, but still nowhere near Lambda. For one vCPU and 2GB of RAM, the Fargate cost is $0.076 per hour: a little more costly than EC2. When you take into account TCO it is certainly a good incremental savings, but only incremental. For the same $0.076 with Lambda, you could run about 145,000 executions of a function that takes 300 ms to run, with each function execution getting 1GB of RAM. That’s 40 requests per second, every second, for that whole hour. In our mind, those are revolutionary economics.
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.
So in summary, no Fargate-hatin’ here. It’s a great new service and the new default way to run containers in AWS. And there are plenty of cases where containers make senses, most notably legacy apps, languages unsupported by Lambda, and long-running processes. But don’t let the word “serverless” confuse you: Fargate is fundamentally just less infrastructure; Lambda-based “serverless” confers benefits to your business on a scale that Fargate simply can’t touch.
