What's Serverless?

Serverless is a catch-all term for apps and products that don’t require you to manage your own servers.

People mean a million different things when they talk about serverless, so we’ll explore it from a few different angles. The important thing is that it’s getting wildly popular, and may be how everyone ships apps in the future. The future.

If you’re a developer building your app, how do you deploy your backend today?

Remember, most apps you use have two major components:

A good example is Substack, the lovely folks who help me send out these emails and posts. Substack has a frontend and a backend:

The frontend and backend work together to give you what you see when you load a page in your favorite app. The backend is usually the part of the app that’s the most complex to build and deploy, because it undergoes the most “stress” and needs to scale appropriately. If 1,000 people are using your app at the same time, your database is going to need to be able to handle 1,000 queries every few seconds – so you can see how it quickly gets out of hand.

When you’re trying to make sure your database and APIs can keep up with your app’s traffic, you have a few options:

Scaling vertically is really easy (you just tell AWS to suck out more of your money), but not fully sustainable or cost efficient; scaling horizontally, though, is notoriously difficult.

And if that devil’s bargain wasn’t enough, scaling isn’t the only problem you’ll face when running your backend. Making sure your servers are performant is highly stack dependent, but will likely involve:

These are just a few of the things that engineers deal with (especially if you have a DevOps focused team) when managing their own servers.

So if the above is working with servers, serverless – in theory – should just mean anything that doesn’t require you to use servers. But that’s kind of a stupid definition, because a lot of things don’t require you to interact with servers. If you’re paying GitHub to manage your code repositories, is that serverless? Is Gmail serverless?

I feel like we need to raise the bar for what's "serverless". IMO any of these things disqualifies: - You have to maintain the compute nodes - Anything that includes the notion of a "cluster" - Pre-provisioning capacity - Paying for idle capacity

To navigate through such murky waters, I’m going to propose 3 definitions of serverless below. The 3rd and final one is the most important, because it’s what developers generally mean when they talk about it.

When you (i.e. developers) outsource any piece of the software stack to a third party via SaaS, that’s technically serverless. A few examples:

While it is useful to appreciate that all of these SaaS solutions obviate the need for developers to build and maintain their own infrastructure, it’s not usually what we mean when we say serverless. I call this the MBA definition – i.e. it’s useless.

Moving further down into the infrastructure layer, outsourcing parts of your infrastructure to managed services from our favorite neighborhood cloud providers can be referred to as serverless. A few examples:

This is where terms like “serverless database” or “serverless frontend” apply.

Finally, the most specific definition of serverless is what developers are talking about most of the time: it’s a method of deploying your app via functions instead of monolithic apps and endpoints. Each major cloud provider has their own product for it:

So in other words, you don’t just not manage servers – you deploy your app as a series of separate functions, which is quite different than how it’s normally done. In that sense, serverless is an architecture decision as much as it is a product.

So basically to sum up here, when you see the word “serverless” it’s all about context. People also try and co-opt the term to sound more sophisticated – but as we’ve seen, plenty of “serverless” products don’t necessarily replace what you would have used a server for. So be skeptical 🙂

Platforms like Lambda are what developers usually mean when they say serverless. So what does Lambda (and the other equivalent offerings from cloud homies) do?

You might have a single function in your app that inserts a new user into the database. Instead of running this, along with all of your other functions, on a central server, you can upload them all separately to Lambda, and trigger them from your frontend. Literally, the Lambda UI lets you just paste code in there as a function:

Once you trigger that Lambda function, AWS takes care of spinning up a server or allocating it to an existing one. Hence, serverless.

But it’s deeply ironic that this is what we’ve come to define serverless as, because Lambda is barely actually serverless. That’s because:

This is why in practice, most uses of Lambda and its siblings tend to be for non-core parts of the app. Most of the customer case studies on the site talk about things like image pipelines, analytics, or general machine learning. High growth startups are usually not running their core app logic on Lambda (until I’m proven wrong, at least).

This is a problem with function-driven architectures these days – the developer experience isn’t quite there, especially as it relates to developing functions locally and then uploading them to the cloud. Personally, I was working on a project using GCP Cloud Functions, and it was infuriating – I needed to test passing a specific data type, and there’s basically no tooling to mock or run that on my laptop. That’s why we’re seeing frameworks like SST (Serverless Stack) try to improve DevEx for platforms like Lambda.

Meanwhile, we’re seeing a lot more interesting stuff in the database space. Fauna purports to be serverless, and charges you exclusively for usage (not based on server size or anything like that). BigQuery, a popular data warehouse, is definitely serverless. Consensus is that we’re still on the cusp here, but it’s definitely something to keep an eye out for.