Serverless offerings like AWS Lambda have not hit the big time, but Kubernetes can help

Comment: Serverless has failed to hit its potential, Corey Quinn claims. Containers can help to change that.

serverless-computing.jpg

Photo: Grindi / Shutterstock

Serverless does not serve its purpose. So said Corey Quinn, well-known man on Twitter and leading cloud economist at The Duckbill Group, and he has a point.

Seven years ago at AWS re: Invent 2014, AWS announced AWS Lambda, an event-driven computer service for dynamic applications that do not require infrastructure delivery. Instead of touting infrastructure, developers could focus on writing business logic, saving money in the process (as the feature would trigger just enough computer / etc to process the triggered event and no longer take care of all the “undifferentiated heavy lifting”). “in ways that the cloud had long promised, but not yet fully delivered).

It was a glorious promise. But here we are in 2021, and the absence of any astonishing update from AWS on re: Invent (or anything 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 someone, “Quinn said. What went wrong?

SEE: Hiring Kit: Cloud Engineer (TechRepublic Premium)

Lock-in, one function at a time

Must read developer content

For those concerned about vendor lockouts, it would be difficult to find something more tailored to reduce portability than serverless. After all, it requires in itself that you have a firm lead of your business logic to a particular cloud. As I have written, there are ways to minimize this impact, and arguably the benefits of increased productivity outweigh the disadvantages of being chained to a particular platform.

Yet it is the argument for “increased productivity” that Quinn questions.

As Quinn wrote: “Most of your time building serverless applications will not be spent writing the application logic or focusing on those parts of your code that are actually the differentiated things that you are paid to work on. does not.” Really? Yes really. “Instead, you will spend most of your time figuring out how to pair these features with other services from that cloud provider. What format does it expect? Do you have the endpoints correct? Is the scope of security accurate?” This, in turn, gets worse when something goes wrong (and it will – it’s corporate software after all): “Time to embark on a murder mystery with distributed micro-services, where the victim is another tiny part of your soul, because that get contiguous logs out of a CloudFront -> API Gateway -> Lambda configuration is CRAP. ”

In short, while developers save some time, they can also expect to spend a lot of energy trying to figure out how to deepen their dependence on the services of a particular cloud. Worse, as Quinn continued, there are relatively few people who understand serverless, so even if you figure out how to make the serverless hum, your company may be a 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 people who know [products like] WordPress, you’re in trouble if both freelance developers who understand serverless are sick that day – not to mention that they cost roughly as much as an anesthesiologist “).

Sad face emojis all around.

SE: Multicloud: A cheat sheet (free PDF) (TechRepublic)

How containers help

Or not. Serverless Inc.’s Jeremy Daly rejected Quinn’s arguments, but tl; dr is “The pain was needed as an intermediate step. Now it’s time to party.” He may be right, but I like how Lacework’s prominent 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 out of the cloud (by using serverless, for example) , developers have returned to the world they knew from before the cloud, but made it easier through containers.

This is why containers have increased in popularity. Especially compared to serverless designs over the past three years. I see many container-based solutions that would be better as serverless designs. Better because they would be more efficient, cheaper and easier to scale. Why are these container-based solutions popping up all the time? Containers hit the sweet spot. They are familiar enough, but push on the envelope in interesting ways. They allow builders to be more productive using modern development methods. At the same time, they do not require a new mental model.

In other words, both Quinn and Daly may be right (and wrong), but in the meantime … containers (and Kubernetes) fill the gap. As Nunnikhoven wrote, “The majority of the IT community is pushing for a container-driven landscape … Over time, it will become too complex and burdensome. Then the mental model of serverless will become the dominant model.” So get stuck: Serverless wants its day – ironically, containers help make that happen.

Publication: I work for MongoDB, but the views expressed in it are mine.

Also see

Leave a Comment

x