That was sent just after the announcement of AWS Lambda at re:Invent in 2014, followed by the below blog post after noodling on it for a bit. Some of the details have gone stale but the gist of it still holds.
Lambda is a logical conclusion to Amazon’s focus on developers. The only place to go from here is to build vertically specific services (e.g. AWS IOT), while filling out the breadth of composable infrastructure / middleware services.
At the time, there was nothing like it. Now we have Google Cloud Functions, Iron.io’s Project Kratos and likely many others being built, as well as an ecosystem growing around Lambda with things like Kappa from @garnaat.
At re:Invent 2014, Ben Golub was up on stage singing the praises of Docker. The masterminds at AWS had arranged for a solid 20–30min of Docker love-in before making the day 2 technical announcements. Ben said that [one of] Docker’s goals was to free developers from having to worry about production and delivery (or something like that, see his keynote). Then Werner comes on stage, describes Lambda, and more or less says that while others [ed: like Docker] are trying to free developers — Lambda actually does that. Pretty amusing.
Lambda will drive some usage away from other AWS services. I’ve already seen experimentation and real usage start amongst high end AWS users (not just Netflix). You could view it as cannibalization, but it’s much smarter. Presumably AWS has figured out how to price Lambda in an accurate way such that the cost of all the underlying and adjacent services consumed is priced in.
Lambda might be a “true” PaaS in the sense of being a pure runtime where you don’t have to understand the underlying mechanics or implementation of compute, storage, database, etc., at all. There are no buildpacks, runtime plugins, etc., like you have in most PaaSes.
“You don’t have to configure, launch, or monitor EC2 instances. You don’t have to install any operating systems or language environments. You don’t need to think about scale or fault tolerance and you don’t need to request or reserve capacity. A freshly created function is ready and able to handle tens of thousands of requests per hour with absolutely no incremental effort on your part, and on a very cost-effective basis.”
— Jeff Bar
Although it has constraints, like only being Node [ed: they’ve since added Python and Java] and only allowing up to 1GB of memory consumption per function [ed: 1.5G now], etc — it’s a completely abstracted runtime environment. You give it code and a few variables. It does the rest.
It completely removes Ops. Why DevOps when you can just Dev? It’s more like Google App Engine than anything else out there. But GAE won’t let you have long running functions (more than a few secs, last I checked), so in its limited way Lambda is already a step ahead.
Where a Docker container gives you theoretical portability because your entire app is packaged in a way that’s independent of what it’s running on (but not really). Lambda locks you in because you have no idea how your code is running or what it takes to run your code. The only thing you could conceivably move to is GAE, but you’d have to rewrite bits and metadata in order to do it. Oh, except that GAE doesn’t do Node. So nevermind.
You have no idea how your code is running or what it takes to run your code.
It’s also dangerous. If you never learn how the thing below what you are doing — what you are downstream of and rely on — works, then you become intrinsically dependent on the provider of that service. Great when that service is an actual commoditized utility with multiple providers in a competitive marketplace. Miserable when it’s a monopoly. Creating that dependence is good gameplay on AWS’s part. Not providing equivalent alternatives that conform to the same interfaces is bad gameplay on everyone else’s. Becoming hooked is a poor decision on our part, unless we do it with eyes wide open and willingness to do the work of unhooking ourselves in the future.