Forget AWS Lambda, Kubernetes AND Fargate - what we need is beyond all three

In 2018 I wrote Forget AWS Lambda, so long Kubernetes, this is the future of serverless here on diginomica. My point in that article being that the future of computation was not going to be neither Functions-as-a-Service (FaaS) offerings, such as AWS Lambda, nor the management of fleets of servers to operate containers, as is necessary for Kubernetes. The long-term destiny for computation was, in my opinion, operating containers on a serverless infrastructure. What I wanted was AWS Lambda for Containers. What I wanted was true Containers-as-a-Service (CaaS).

True Containers-as-a-Service

What I am asking for is not only a serverless container infrastructure but a container orchestration-less infrastructure. What I want is the ability to say, “Here’s a container, run it for me please,” and let the infrastructure do the rest:

• The infrastructure should launch and destroy containers.
• The infrastructure should determine how many instances are needed to run your application.
• The infrastructure should manage the load on your container in an automatic manner.

The infrastructure should manage containers, just like AWS Lambda manages functions…

I should not have to care how many instances of my container are running, the system should do that for me. I should not have to worry about availability issues related to capacity shortages, the system should do that for me. I should not have to worry about excess wasted capacity, the system should handle that for me.

Along comes Fargate

My 2018 article predicted true Containers-as-a-Service, and at the time I believed a new offering from AWS was going to provide it — that offering was Fargate.

AWS Fargate is a way to remove the need to manage the individual servers that comprise a container cluster. With AWS Fargate, you specify how many containers you want to run and the size of those containers and Fargate will launch sufficient server capacity to manage that set of servers for you. Finally, we would have true Containers-as-a-Service.

Well, not quite.

What Fargate is missing

Fargate was a great start, and I said that in my original article, but it isn’t sufficient. Fargate is a step in the direction of true Containers-as-a-Service, but it isn’t a complete step.

You see, in Fargate, you still have to do capacity management. You have to determine how many instances of your container you want to run. Once you determine the number of containers, Fargate will determine the necessary server fleet needed.

But you still have to specify the desired number of containers. Fargate doesn’t remove the need to perform capacity management. It just moves the capacity management function from determining the required server capacity to determining required container capacity. This is the exact same problem, it’s just at a different scope.

Fargate did not remove the capacity management problem. Fargate did not remove orchestration as a topic of concern for your infrastructure team. Fargate does help this problem, but it doesn’t help enough.

Waiting …

In 2018, when Fargate first came out, I said that I thought the future of computation was Fargate. This is because I fully expected Fargate to improve over time to address its capacity management shortcomings.

So I waited…

And I waited…

And I waited…

But nothing came. Two years later, it looks like Fargate isn’t going to be the solution to the future of serverless computation after all. Fargate isn’t going to solve the capacity management problem.

Something different will have to be.

What we need

In a true Container-as-a-Service model, you simply provide the image of the container to the service, and the rest is handled by the service. No server management. No orchestration. Nothing. If more instances of your container are needed to handle the current application load, more instances are spun up. When some instances of your container are no longer needed, they are spun down. The goal is that the right amount of container capacity would always be available.

And rather than paying for the number of containers you have running, you would pay for the amount of load the containers are handling.

In other words, rather than paying for some form of allocated capacity, you would pay for the amount of resources actually consumed to handle your application needs.

This is something you can’t do with Fargate today, and you can’t do with any of the other orchestration systems, or container management services, that are available today.

A true Container-as-a-Service model, such as I describe here, is what we really need to change how application computation is managed in the future in cloud-based infrastructures.