One thing I've learned from the Serverless debates. Avoid the use of the word containers.
Containers have technical merits: OS isolation, and more recently, software packaging and distributing. But containers also carry the baggage that all infrastructure components do. Containers are too low level.
Containerization is already in use by the majority of Serverless platforms as a hidden component, as it should be, but we are missing a very important part of modern containerization: the ability to package, distribute, and share applications.
Functions as a Service (FaaS) is by far the most popular form of Serverless, and possibly the best definition of what it means to be Serverless.
In the case of FaaS the container image is too much overhead and complexity for the desired workflow. Just write some code and upload it. Done.
What about dependencies? This is the first point of friction in the FaaS desired workflow. If one of your dependencies is something like the imagemagick cli tool, then you have more work to do.
How does one go about expressing an external dependency for a function? Today it's simple. You include all your dependencies in a .zip file and upload that instead.
Given what we know about managing dependencies we are going to eventually run into problems around versioning and conflicts. Upgrading one dependency can break everything.
Maybe FaaS platforms have solved the challenges of dependency management and it just works. If so, can someone point me in the right direction.
Dependency management aside the biggest barrier to entry is language runtime support. Most FaaS platforms only support a handful of language runtimes. AWS Lambda and Azure Functions being the exceptions as both platforms support most popular language runtimes.
Ideally I should be patient and wait until my language runtime of choice is officially supported across all FaaS platforms. The other option is to push support for custom runtimes.
Without getting into implementation details, it would be awesome if I could upload an application that implements a custom runtime that respects the target FaaS platform's packaging and runtime semantics: event driven, pay-per-use, etc.
