Hacker News Reader

Comment by arjvik | Hacker News Reader

Now that you can run containers on Lambda, why are individual releases like this still important? Couldn't you just deploy your own runtime in Docker?

View on HN

Using Docker images as deployment packages for AWS Lambda has two notable disadvantages from my point of view:

- You're suddenly responsible for managing the whole operating system again, neglecting one of the major benefits of AWS Lambda.

- You need to store the Docker images in AWS Elastic Container Registry (ECR) which adds additional complexity to the setup.

Doesn't a lambda based on a docker container incur container startup time, whereas if you use one of their language-specific SDKs you don't?

AWS Lambda doesn't run a container like one might expect, but it treats the files in the Docker image basically the same as if it's be a regular AWS Lambda runtime rootfs + your application code. So if there are differences in cold start time, reasons for that could be that a docker image is fetched from ECR instead of S3 for regular Lambda packages and that a docker image is likely larger than the usual Lambda package.

You can package a lambda as a container image, but lambda doesn’t itself run the container like it would in dockerd or kube etc, it’s just a packaging mechanism I believe.

The biggest difference is that you have to use a lambda compatible entrypoint that basically communicates with AWS receiving the input and returning the output.

Can't you code one yourself?

For sure. I have a couple of non-standard OpenJDK containers for Lambda. But it isn't like you just use a random container. It has to be custom setup for AWS Lambda for it to work.

Interesting... That seems to defeat the entire purpose of a container if it's just a fancy tar.gz

Reply on news.ycombinator.com