On Cloud Runtimes

So. You are in a hurry and want to compromise your users’ data publish an app in a hurry.

Your head’s on straight: you don’t want to worry about the hard parts; you definitely don’t want to worry about scale/best-practices until you feel a pulse. You’re a beginner–either to software engineering in general or to standing something up _from scratch_(1) (1)That second demographic is huge (personal projects + first-time startup founders + disposition:kleenex line-of-business apps for simple things): given the number and size of huge software orgs, most people doing development have passed through one at some point in their lives. Like excrement. Anyway. . You don’t want to go back to heroku, you don’t want to go deep, and you don’t want to go wide.

So you stand up a lambda(2) (2)It might be a CloudFlare worker or a severless deployment or Azure function or whatever. But Lambda got there first, so all others are victims of genericide (what a lovely word). .

You’re up and running pretty soon thereafter, but you’re hitting problems soon after that. Logs aren’t reliable/always present. Crashes (because you’re writing hokey code) are hard to debug. Your users, god help them, file mysterious bug reports that you can’t correlate with anything because look ma, no computer! So you add logging. You add a metrics stack. Pipe those to fully managed platforms, grit your teeth at the cost (and break them if someone high-volume and/or evil finds your lambda and maxes out the concurrency limit; the multiplier on your cost O(N) goes up the more ancillary cloud-native services you plug into each invocation).

The trigger for having to go through all that hassle isn’t the lambda platform itself, it’s the fact that your code has bugs. It has more bugs because it’s new–because it’s exactly the kind of code you want to shotgun out quickly. And it’s not too debuggable on lambda–not without buying into all the rest of that stack.

This is a very clever tar-pit set up by cloud providers you’ve just fallen into. Lambda-style things are marketed to:

• Low-skill people (e.g. new grads).
• Low cloud-architecture-expertise people (e.g. corporate refugees).
• People in a hurry (e.g. startup founders).

The only way to make the lambda platforms fulfill their promises of “don’t make me think” deployability is to layer on even more per-cloud-provider proprietary tech. This increases provider revenue and increases lock-in, and still doesn’t get you too far beyond “really high latency printf-debugging with a million moving parts”.

Print-debugging is well and good (and should be the first tool in your box regardless), but the times you need more than that are probably the times where you need more than that right away: phone ringing, hangover beginning to set in, account cancellations spiking, people dragging you on twitter, the works. That’s a bad time to discover that for some “how do I observe/interact with my software as it runs?"-type questions, the answer in lambda-land is “you just don’t.”

FaaS platforms get as much traction as they do because some very shrewd people at cloud providers erected an iron triangle of incentives:

1. They perform aggressive marketing that both saturates discursive spaces with lambda advocacy and simultaneously de-emphasizes better runtimes as too complicated/not needed at small scale.
2. They direct that marketing (which at this point isn’t even entirely marketing, past a point of grass-roots support due to hype cycles and resume-driven development) at people who are very likely to get the short/long term cost point(3) (3)On a timeline between “first release” and “retire”, this is the distance between “this FaaS stuff is really easy to deploy” and “this FaaS stuff is causing seriously inconvenient costs/debugging/stability issues and keeping me from delivering maximum value” wrong while making architectural choices, because they’re low-skill/low-expertise/in a hurry.
3. Provide tools to “easily” mitigate the (technical) costs of the FaaS runtime by sending additional dollars to Reston, VA for incineration, and getting further locked into a given cloud provider.

Serverless and friends shave off some of those rough edges, but … that’s another set of tools to learn for a demographic who only came in the store because they want to avoid doing that. Who knows, someone clever might someday figure out a way to zap a remote XDebug or [sdl]trace probe into a running FaaS–and cloud providers might even support that hypothetical tool before the oceans swallow us all.

But I’m not holding my breath.