Serverless offerings like AWS Lambda haven’t hit the big time, but Kubernetes can help

Commentary: Serverless has failed to hit its potential, Corey Quinn argues. Containers may help to change that.

Serverless isn’t serving its purpose. Thus stated Corey Quinn, noted man about Twitter and chief cloud 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 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

Must-read developer content

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…

Access the original article

Subscribe
Don't miss the best news ! Subscribe to our free newsletter :