Seven years ago at AWS re:Invent 2014, AWS announced AWS Lambda, an event-driven compute service for dynamic applications that requires zero provisioning of infrastructure. Instead of mucking about with infrastructure, developers could focus on writing business logic, saving money in the process (as the function would trigger just enough compute/etc. to process the triggered event, and no more taking care of all that “undifferentiated heavy lifting” in ways that cloud had long promised but hadn’t yet fully delivered).
It was a glorious promise. Yet here we are in 2021 and, absent some astounding update from AWS at re:Invent (or something similar from Google or Microsoft at their respective 2022 events), serverless will spend another year “fail[ing] to live up to its promise and [not] prov[ing] to be particularly lucrative for anybody,” said Quinn. What went wrong?
SEE: Hiring Kit: Cloud Engineer (TechRepublic Premium)
Lock-in, one function at a time
For those concerned about vendor lock-in, it would be hard to find something more tuned to mitigate portability than serverless. After all, by its very definition serverless requires you to hardwire your business logic to a particular cloud. As I’ve written, there are ways to minimize this impact and arguably the upsides of increased productivity outweigh the downsides of being shackled to a particular platform.
Yet it’s that “increased productivity” argument that Quinn calls into question.
As Quinn wrote, “The bulk of your time building serverless applications will not be spent writing the application logic or focusing on the parts of your code that are in fact the differentiated thing that you’re being paid to work on. It just flat out won’t.” Oh, really? Yes, really. “Instead you’ll spend most of your time figuring out how to mate these functions with other services from that cloud provider. What format is it expecting? Do you have the endpoints correct? Is the security scoping accurate?” This, in turn, becomes worse when something goes awry (and it will–this is, after all, enterprise software): “Time to embark on a microservices distributed systems murder mystery where the victim is another tiny piece of your soul, because getting coherent logs out of a CloudFront –> API Gateway –> Lambda configuration is CRAP.”
In short, while developers save some time, they also can expect to expend a fair amount of energy on trying to figure out how to deepen their dependence on a particular cloud’s services. Worse, as Quinn continued, there are relatively few people who understand serverless, so even if you figure out how to make serverless hum, your company could be one bus crash away from not being able to upgrade the application you built (Quinn: “It turns out that while it’s super easy to find folks who know [products like] WordPress, you’re in trouble if both of the freelance developers who understand serverless are out sick that day—not to mention that they cost roughly as much as an anesthesiologist”).
Sad face emojis all around.
SEE: Multicloud: A cheat sheet (free PDF) (TechRepublic)
How containers help
Or not. Serverless Inc.’s Jeremy Daly rebutted Quinn’s arguments, but the tl;dr is “The pain was necessary as an intermediate step. Now it’s time to party.” He may be right, but I like how Lacework’s distinguished cloud strategist Mark Nunnikhoven translated the tension between Quinn’s and Daly’s arguments: In the absence of clear, easy ways to get the most from cloud (using serverless, for example), developers have reverted to the world they knew pre-cloud, but made easier through containers.
This is why containers have skyrocketed in popularity. Especially compared to serverless designs over the past three years. I see a lot of container-based solutions that would be better as serverless designs. Better in that they would be more efficient, less costly, and scale easier. Why do these container-based solutions keep popping up? Containers hit the sweet spot. They are familiar enough but push the envelope in interesting ways. They allow builders to be more productive using modern development methods. At the same time, they don’t require a new mental model.
In other words, both Quinn and Daly can be right (and wrong), but in the meantime…containers (and Kubernetes) are filling the gap. As Nunnikhoven wrote, “The majority of the IT community is pushing towards a container driven landscape….Over time that will become too complex and burdensome. Then the mental model of serverless will become the dominant model.” So sit tight: Serverless will have its day–ironically, containers will help that to happen.
Disclosure: I work for MongoDB, but the views expressed herein are mine.