After building my first custom Lambda runtime, it's safe to say AWS hit a home run, the Lambda Runtime API is a game changer.

Given the combination of the Lambda Runtime API and Lambda Layers I no longer believe adding support for containers would add any additional benefit to Lambda.

The Lambda Runtime API provides a major benefit over containers for Serverless workloads: a well defined and opinionated runtime API for getting work done.

So who’s gonna build something like this for multi-cloud and hybrid-cloud? Maybe something on top of knative or a k8s-based FaaS?

I’d love to see OpenWhisk’s evolution after this. I haven’t used it so I don’t know how usable it is atm, but an open solution play could benefit the ecosystem. k8s helped google AND openness. Lambda helps developers, but captures ecosystem for Amazon to the exclusion of others.

For starters, there is a good example from @triggermesh on using @KnativeProject buildtemplate to run AWS Lambda custom runtime functions. From there it’s all open and portable to any @kubernetesio certified provider (EKS, AKS, GKE, on-perm...)

We’re glad you like them and would love any feedback!

I agree for Lambda in particular, given Amazon's interest in keeping their platform proprietary. Containers do have a useful ecosystem around them for analysis (BlackDuck) and build. Interested to see if Amazon opens the platform or tries to build in parallel.

There's already WIP tools to translate Lambda Runtime to containers for #Knative, thanks to @sebgoa:

the C++ example runs well, we are debugging the RUST example as we speak. Will blog about it hopefully tomorrow...

What about system dependencies? Suppose I want to run FFmpeg in a Lambda? I don't see how the Runtime API helps there.

Aware that I’m not exactly answering your question but that’s when Layers come in handy:

Oh interesting! I didn't realize you could include arbitrary binaries; I had assumed it was limited to what could previously be in the Lambda contents. Thanks!

That’s the power of layers! They are a game changer.

Reading more, it is arbitrary binaries (which is great!), but some workloads need a custom Linux image. That's where a Docker container is strictly more powerful.

So, if Fargate supported Lambda event sources, that would be the best of both worlds.

It should one day surely!

Sure. But I think the layers pattern is more maintainable. If they are a docket container perhaps they can be refactored to fit (maybe not in all cases)

The Layers API will help there – someone can create an FFmpeg layer, put the libs at the right place (in `lib/` in their layer) and it'll Just Work ™ 🤞. To be fair, it's definitely not as much control as in Docker – and layers could potentially clash.

They added the good parts of containers while constraining the scope for a function execution

The Lambda Sandbox consists of cgroups, namespaces, & seccomp (in addition to iptables) ... same isolation of a container, just without the Docker API (so no Dockerfile)...

It’s also interesting if Firecracker negates some use of containers, get speed & efficiency with more isolation.

When you say containers do you mean running supporting arbitrary containers or do you mean running in containers as a general practice?

Except maybe developer experience, adaptation, ease of use, familiarity, CI/CD tooling, compatibility, etc.... I can understand the business reason to harden the lock-in, but is that the reason for not adding support for otherwise standard tools (containers)?

that's awesome. i had a few friends using that platform some years ago who used javascript to load in a ruby environment. they spent months on trying to efficientize that

I've been thinking it might be possible to take a Docker file and convert Docker image layers into Lambda layers for many if not all containers. The main difference is the base OS layer obviously, but good container apps stay minimal and don't really depend on a full OS anyway

docker save will generate a tar.gz of the rootfs. From that point, should be easy to port.

Best containers are built from scratch, and it means zero dependencies to base OS. So, your approach sounds thus plausible!

This will not be practical unless everyone adopts the specific Amazon Linux Docker image as their base for linking to shared libraries and building native modules.

FROM scratch may work for a simple static Golang binary, but base images exist for a reason. Even the difference between Alpine and Debian is enough to cause project maintainers a headache.

Try building some native npm modules or pip modules (completely valid use-case for serverless) with an Alpine Linux base and musl-dev then put it into the Lambda runtime container. Very unlikely to be compatible.

The Lambda custom runtime opens an interesting although arbitrary interface for runtime compatibility which I think could be interesting for OSD FaaS -

Given enough tooling investment perhaps you could get to something for Lambda that looks like a layered Docker build, but are layers the only advantage of containers? Much of that value is the convenience, ubiquity and user- experience

Also: "A function can use up to 5 layers at a time. The total unzipped size of the function and all layers can't exceed the unzipped deployment package size limit of 250 MB" - I guess this can be changed, but it's another hurdle for scientific workloads.

Yeah I agree with this point for sure. I think multi stage builds in Docker are a very important piece of the puzzle. And that doesn’t quite map to what the Lambda team is doing with layers yet

Startup idea migrate legacy containerized apps to lambda #Serverless

Which runtime did you build?

It’s was gold at the re:Invent keynote when the guy from the national Australian Bank said the paces the way for Cobol Lambdas.

"this paces the way". typos.

Third time's the charm?

I wonder why they didn't do it a few years back when they started to add support for more and more programming languages. This would have made it much easier for everyone. Build a platform and let others do the per language work.

This looks amazing! Do you know if Google has any plans to implement this functionality as well any time soon? I can’t see why not 😇😇😍

I'm not sure why people haven't discussed this more

Thanks for sharing! Must say I personally like the idea of using Docker containers, and it fits into my current flow really well 😍

I agree. This is really a great move by Amazon.

Forgive my ignorance, but does this mean we can essentially write serverless functions on Lambda in any programming language now?

Yes

Awesome. Thank you!

I *want* to love Google Functions, but it still needs a lot to be on par with AWS Lambda.

Can you elaborate?

I’d say it’s all about event sources and rest mapping, gcf has a very limited of events that are ga (http, pub sub, gcs) the value chain is unlocked by tying into more events src and having a nice rest/api mapping to gcf.. plus scheduled exec.

Lambda, Google functions, and Azure equivalents must have basic portability. Otherwise serverless is this decade’s stored procedures. I know that savvy companies aren’t using CSP specific features to preserve portability and maintain the power of the purse.

Serverless as implemented with Lambda is a huge anti-pattern.

beyond cool!

Interested to see how serverless architecture treats you as your infrastructure grows.