Serverless offerings like AWS Lambda haven’t had much success yet, but Kubernetes can help





Commentary: Serverless hasn’t reached its potential, says Corey Quinn. Containers can change that.

serverless-computing.jpg

Image: Grindi/Shutterstock

Serverless does not serve its purpose. Says Corey Quinn, a well-known man on Twitter and chief economist at The Duckbill Group, and he’s got a point.

Seven years ago at AWS re:Invent 2014, AWS announced AWS Lambda, an event-driven compute service for dynamic applications that requires no infrastructure. Instead of messing around with infrastructure, developers could focus on writing business logic, saving money in the process (because the function would fire up just enough compute/etc to handle the triggered event, and no longer worry about all that “undifferentiated heavy lifting”” in ways the cloud had long promised, but hadn’t yet fully delivered).

It was a glorious promise. But here we are in 2021 and, without an amazing update from AWS at re:Invent (or something similar from Google or Microsoft at their respective 2022 events), serverless will “fail” for another year[ing] to keep his promise and [not] proof[ing] to be extremely lucrative for everyone,” Quinn said. What went wrong?

SEE: Hiring Kit: Cloud Engineer (Tech Republic Premium)

Lock-in, one function at a time

Must-read content for developers

For those concerned about vendor lock-in, it would be hard to find anything more geared towards reducing portability than serverless. After all, serverless requires you to hardwire your business logic to a particular cloud. As I’ve written, there are ways to minimize this impact, and the benefits of increased productivity likely outweigh the drawbacks of being locked into a particular platform.

Yet it’s that “increased productivity” argument that Quinn questions.

As Quinn wrote, “Most of your time building serverless applications won’t be spent writing the application logic or focusing on the parts of your code that are basically the differentiated thing you’re being paid to work on.” work. It’s just downright not.” Really and truly? Yes really. “Instead, you spend most of your time figuring out how to connect these features to other services from that cloud provider. What format does it expect? Do you have the endpoints correct? Is the security scoping right?” This, in turn, gets worse when things go wrong (and it probably will – this is business software, after all): “Time to embark on a murder mystery involving distributed systems on microservices where the victim is another little piece of your soul, because it getting coherent logout of a CloudFront -> API Gateway -> Lambda configuration is CRAP.”

In short, while developers save some time, they can also expect to spend a fair amount of energy trying to figure out how to increase their reliance on a particular cloud’s services. Worse, as Quinn went on to say, 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’ve built (Quinn : “It turns out that while it’s super easy to find people who know [products like] WordPress, you’re in trouble if both freelance developers who understand serverless are sick that day – not to mention costing about as much as an anesthesiologist”).

Sad face emojis all around.

SEE: Multicloud: A Cheat Sheet (Free PDF) (TechRepublic)

How containers help

Or not. Jeremy Daly of Serverless Inc. refuted 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 leading cloud strategist Mark Nunnikhoven translated the tension between Quinn and Daly’s arguments: in the absence of clear, easy ways to get the most out of the cloud (e.g., by going serverless), developers have fallen back on the world they knew pre-cloud, but made easier by containers.

This is why containers have soared in popularity. Especially when compared to serverless designs of the past three years. I see a lot of container based solutions that would be better as serverless designs. Better because they would be more efficient, cheaper and more easily scalable. Why do these container-based solutions keep popping up? Containers hit the right spot. They are well known enough, but push the envelope in interesting ways. They enable builders to be more productive using modern development methods. At the same time, they do not need a new mental model.

In other words, both Quinn and Daly could 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 for a container-driven landscape… Over time, that will become too complex and cumbersome. Then the serverless mental model will become the dominant model.” So take it easy: Serverless will have its day – ironically, containers will help with that.

Disclosure: I work for MongoDB, but the views expressed herein are mine.

Also see




Leave a Comment

x