What Is “Serverless”? An Alternative Take

(Or: a few counter points to the “serverless” hype.)

Hassy Veldstra

Before I say anything, I’d like to emphasize that I think AWS Lambda is great. It’s an awesome solution for scripting all sorts of things in your AWS environment and all sorts of one-off short-lived tasks. It can work really well for some SPA (single-page application) backends and it can make a lot of sense to power some APIs (in conjunction with API Gateway). However, contrary to all the “serverless” hype, it is not the end-all and be-all of platforms — and very far from it.

I should also mention my AWS Lambda bona fides upfront to field any objections of having no experience. I have built two experimental open-source projects on Lambda (Dino and Llama) as well as a small backend for a small SPA and a full-fledged RESTful API (utilizing and piecing together 7 AWS services in total).

Finally, what do I mean by “serverless”? Or rather what I don’t mean — I am not talking about the Serverless Framework specifically, but about this revolutionary new approach to building applications on AWS Lambda as a whole.

“Serverless” Is Basically CGI In Containers

I know CGI but until I sat down to write this I had no idea it had an official spec and a logo

If you’re old enough to remember CGI, you’ll recognize serverless straightaway. A request comes in, we spin up a process to handle it (yes, a whole new process!), pass it some information in environment variables, and send back whatever is printed to stdout.

Let someone else run your process, let them put the process in a shiny Docker container, swap environment variables and stdout for a JSON object and a callback, and boom, you have AWS Lambda. Shiny but ultimately just as wasteful. Container reuse? Yeah, FastCGI is a thing too. (Sadly, it doesn’t seem to have a logo.)

Serverless Is Massive Lock-In

90s kids will know

To do anything useful in your Lambda function you will very likely need external services. Since you’re too lazy to even spin up an EC2 instance, chances are you won’t be running your own database, message queue, storage system &c &c, you will use the easiest option available, i.e. another AWS service. Good luck migrating off of those should you ever need to.

Severless Is Not New

No, I am not going to talk about CGI again. You want to write code and not have to think about infrastructure and servers? Use Heroku! Save yourself the time, the developer experience is 100x that of “serverless”. You’d like a different vendor and a bit more lock-in than Heroku? Google App Engine is a thing too. There are no servers with either, just units of computing power.

Having “lambda” in the name is a stroke of marketing genius, suggesting function-level scalability, whereas the actual reality is that you get a whole new process whose job is to run the one function you’ve provided.

Serverless Is Opaque

Leave advanced debugging at home

Any non-trivial application will have bugs and issues that only manifest themselves in production. You will want ssh access at some point but of course you cannot ssh into your Lambda. You cannot inspect your program as it’s running. Forget debugging techniques that we’ve accumulated over the years, they don’t apply in this post-Kansas serverless world. Forget dtrace, forget perf, forget flamegraphs. Your debugging arsenal is limited to good old printf debugging. No, scratch that, I should’ve said “good old CloudWatch” debugging, which is a few notches below printf-debugging, because it lags. Hooray!

Serverless Is Not Really “Massive Scale”

I’ve no idea what this is supposed to be

Many articles espousing the benefits of serverless will mention both the massive scalability your app gets for free and the per-pay-use pricing model where you pay per invocation of your function. This just does not make sense — if EC2 or Heroku is too expensive for you, you probably don’t need to worry about any kind of scale, and if you do run an application at large scale, you will get a lot more mileage out of a few decent EC2 boxes tuned for performance than all the lambdas you can spin up. You’re spawning a whole bleedin’ process for every request! yeah that’s scale.

And anyway, “scale massively out-of-the-box”? [1] AWS Lambda limits you to 100 concurrent executions across all of your functions, and your functions cannot run for longer than 300s (so forget any kind of a persistent connection). Doesn’t sound like scale to me.


Writing a web app but don’t want to manage servers? Use Heroku or GCE, or another real PaaS. Save yourself the time and the trouble. Don’t believe the hype, AWS Lambda is not it.


  1. Source: Serverless Framework docs. There was a lot more talk about massive scale when the framework originally launched, which has since been toned down quite a bit.

Hassy Veldstra

Written by

Working on https://artillery.io⚡️ Node.js-powered load testing. Node.js and DevOps consultant in London.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade