All i had to do was provide a container with a web service that reads a environment variable to listen to a specific port.
You can create a web service in whatever language and framework you want, all you need to do is read a PORT environment variable for incoming messages. The freedom was really awesome, instead of being confined to supported languages and frameworks you get in the functions landscape. Only confinement was that you're pretty much limited to HTTP calls, unless that has changed.
Personally i find the freedom of pick your own language and framework a big positive, and billing is finer on cloud run compared to AWS Fargate(rounded up to next sec) if im not mistaken. I do wish they would make billing even more finer instead of rounding up to the next 100 ms, rounding up to the next 10ms would be nicer when you use non GC or Runtimed languages, like Rust.
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).
2. Timed events. You can do this with Fargate directly (https://aws.amazon.com/about-aws/whats-new/2018/08/aws-farga...)
3. APIs. Fargate supports autoscaling.
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.
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.
But, also you can have up to 4 vCPUs with Fargate as opposed to one with lambda.
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.
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.