When I tell people I am the founding PM on Lambda, the question I often get is how the idea for #AWS Lambda/#Serverless came about in the first place. The truth is, its way too hard to point to one person/event as the defining moment.
It took 100s of customer conversations notes from multiple AWS folks where they told us 1/all the things they wanted to minimize/ not do at all while building applications; 2/architectural patterns they were repeating and wanted a way to build into their development flow.
It took some serious leaps of faith and acceptance of risk from the people involved, and a constant iteration on what we wanted the final product to look like. This is where I first saw the AMZN "Working backwards" process in action and its brilliance in driving the right focus.
What I do remember very distinctly is one of my first whiteboards on what became Lambda with @timallenwagner where he stressed "Its all about the code, the app, the functions". In someways, that became one of the core tenants for how the product evolved.
There be some fun stories in that journey (ask me about Lambda pricing sometime over alcohol) and terrifying ones (like when a big enterprise told us we were building a toy). As with all things, we get some right, we get some wrong, so keep us (AWS) honest with your feedback :)
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Interesting to see FaaS and Serverless compute start to diverge.
Strongly believe the latter needs to eliminate all routing, placement, scaling, management, packing, and patching responsibilities from your domain while meeting your availability, latency, and scale needs. Doing any of that yourself is work you shouldn’t do.
FaaS is one of (and IMHO, the best suited) programming model to best realize the Serverless model, as a way to put together serviceful architectures. But by itself, it won’t give you the cost and agility benefits you have come to associate with Serverless stuff.