Four stages of lambda enlightenment for the working DevOps practitioner

First comes ignorance. Ignorance isn't so bad, in the sense that we collectively put together a lot of great computing before Amazon's 2014 release of Lambda.

Next is rose-tinted awareness of Lambda: it scales! Pricing is truly on-demand! We've left DevOps behind for NoOps! This is heady stuff ...

... before the realization that most "department"-level applications--those with up to a few thousand simultaneous users--actually fit adequately on a mediocre server or three. CapEx (capital expenditure) doesn't go much lower than when using equipment that's already fully depreciated. Moreover, writing for Amazon's IaaS (Infrastructure as a Service) is a step toward proprietary lock-in, and coding for it simply is not the same as the JavaScript or Python you learned in class. This is not such a good deal after all.

Lambda answers some questions, not all

Apparently we all have to work through these steps before reaching a clear understanding of how Lambda fits in. Yes, Lambda is perfect for Silicon Valley's scale-at-all-costs sorts of projects Randall Munroe occasionally mocks .

Yes, Lambda is deeply pointless for lots of modest projects that happily run on equipment already on premises through conventional codings.

There are also many interesting opportunities in the middle where we don't yet have a consensus about whether Lambda is a terrible or brilliant idea. The two aspects of Lambda that interest me most are its fit in event-oriented work, and its security profile.

Events--everything from registration for your suburb's Little League teams to coverage of a political party's national convention--demands a specific kind of scalability. Events are intrinsically "bursty", and a challenge to size rationally. Lambda is a partial answer to coping with this extreme variability in load.

Lambda also shrinks security exposure down to a minimum for the job at hand. While we don't yet have deep experience with Lambda's security vulnerabilities, it's easy to like the principle of tight fit between capabilities and privileges that Lambda enforces. Moreover, Amazon's role-based security definitions look to me to be a better structure for modern applications than traditional account-based approaches. We'll return to themes of security in DevOps over the coming months. For now, the point is that most Lambda commentators, including Amazon itself, barely mention security; it's worth a second look, though.

The "bottom line" on Lambda? It's time to study what others are doing, practice "Hello, World", and even learn a little about such alternatives as webtask.io, iron.io, and Google Cloud Functions. Tell us in the comments below how you are making the most of IaaS, and what you plan for the future.