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...)
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.
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.
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)?
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
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.
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.
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.
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.