There is no reason that Fargate can not be a replacement for lambda.
There are three use cases for lambda:
1. Event based triggers where something happens externally that you want to process. You can do the same thing with Fargate by either having a continuously running process that reads from a queue or responds to an API request (AWS Event -> SNS -> API).
Fargate can do anything that lambda can do without the limitations - request and response payload size, a 10GB temporary storage drive instead of a half megabyte, and no 15 minute runtime limit. Of course no cold start times since you can have a minimum number of instances always running without Ping hacks.
Fargate is slow to spin up and can only run 50 simultaneous instances. But they can run "forever" and have much higher memory constraints.
Lambdas relatively fast to spin up and thousands instances can be run at once. But they are time limited running for at most 5 minutes and using 3GB of RAM.
You can do most of the same things with either (after all, they just execute code), but you cannot ignore their very different limitations and that they are conducive to different workloads.
The limit of 50 is a soft limit - you can send a support request to get it raised and they usually respond within a half an hour. Lambda also has a default soft limit of 2000.
But, also you can have up to 4 vCPUs with Fargate as opposed to one with lambda.
And bare-metal servers can do everything Fargate can without limitations.
The point of both is to sacrifice some capabilities in order to remove operational complexity. Lambda just goes farther along that spectrum than Fargate does.
How so? With lambda you give AWS a zip file with your code in it and with Fargate you give AWS a Docker Container. The only difference is that AWS doesn’t support the event triggers with Fargate out of the box.
It’s not any more “operationally complex”. The fact that Docker containers include the OS doesn’t make it more complex to run.
My Docker file that I used to convert my Node/Express API that was running in lambda consisted of...
- setting environment variables (I had to do the same thing in my CF template for lambda)
- retrieving the Node Docker image (one line of code - I had to specify one line of code in my CF template with lambda to specify that is was using the Node runtime)
- copying the files from the directory to the container (as opposed to specifying the locsl path of the source code in the CF Template)
- Specifying the Docker Run command (as opposed to specifying the lambda handler).
- running “Docker build” as opposed to “CloudFormation package”.
How it does it is an implementation detail.
In fact, if you use lambda layers, it’s almost equivalent to building Docker images.
