Skip to content
Swizec Teller - a geek with a hatswizec.com

How do you know if serverless fits your project?

The hallmark of a true expert is understanding about the pros and cons of your technical decisions.

You get an ambiguous problem. How do you solve it?

System design is the interview question that "senior" engineers struggle with the most. There's no right answer and they fall apart.

It's kinda fun to watch 😈

The trick to owning a decision is to understand:

  1. Many approaches solve the problem
  2. There are tradeoffs
  3. Best choice depends on context

That's why my new book, Serverless Handbook, focuses on giving you the tools to make your own decisions.

Serverless Handbook

Learn everything you need to dive into modern backend. Understand any backend

these chapters gave me knowledge which is sufficient to build real products and the hand-drawn diagrams and high-leveled descriptions gave me the feeling that i don't have any critical "knowledge gaps"

Launching soon, be the first to know.

Join over 10,000 engineers just like you already improving their careers with my letters, workshops, courses, and talks. ✌️

Like Chapter 2 on the pros & cons of serverless that concludes with a heuristic I like to use 👇

Serverless Pros & Cons – when should you go serverless?

tDNBrFpng6ghei7

Okay you've heard of serverless, tried it out, and you think it's neat. But should you really go serverless for your next project?

Yes!

Most of the time ...

Serverless is a great option for most projects most of the time. You save configuration and maintenance time, gain flexibility, and in extreme cases spend more \$\$ per request than building your own servers.

Large apps can reach the cost curve limits of serverless. Bank of America, for example, announced \$2B in savings from building their own data centers.

You won't hit those issues. And if you do, I hope there's a business model to back it up and you can afford DevOps professionals. 😛

Large orgs tend to provide a cloud or serverless-like environment internally. If you have access to that, use it.

Serverless is an ecosystem

When I say serverless, I don't mean just throwing up code on a function-as-a-service platform like AWS Lambda. I'm talking about the whole ecosystem.

The core idea is this:

  1. Backend does as little as possible
  2. Clients tie everything together
  3. Static files come from fast content delivery networks
  4. Database handles data consistency
  5. As much work as possible happens at compile and deploy time

Users' and developers' machines do the hard work.

Is part of your app the same for every user? Package it up at deploy time. No need to bother the server or the client with that work.

Is part of your app specific to individual users? Let the client handle it. Every phone is a powerful computer these days.

Got dynamic data that needs to synchronize across multiple sessions or users? Background processes that aren't tied to a specific session? Perfect fit for your server and database.

We go in depth about this architecture in the chapter on Serverless Architecture Principles.

Serverless pros

The main benefit of serverless is that you don't deal with servers. They're somebody else's problem.

You save time

You focus on application code. No more tedious maintenance tasks that aren't specific to your problem.

Bye bye yak shaving. 👋

"I need an API. That means I have to run a server. Which means I need Apache or Nginx to map HTTP requests to my app server. I need a computer to run all that. Which means I have to set up a whole operating system. Then I have to make sure everything runs at boot. And if a process goes down, it needs to restart. And ..."

After all that work you get to build your application.

With serverless you save time otherwise spent managing servers. Whether that's you personally or a DevOps team in your organization.

Programming productivity

You write backend code more productively.

Smaller, more self-contained code, ideally a single function, brings clarity and focus. Do one thing and do it well

With increased focus, you get:

  • easier testing
  • quicker understanding
  • shorter development cycles

Often cheaper

Serverless can be cheaper to run.

You save opportunity and employee cost and you're not paying for servers you aren't using.

As mentioned in the Getting Started chapter: before serverless, you'd have to (over)provision a bunch of machines in case there's a traffic spike. That means you're paying for servers you aren't using.

With serverless, you pay per execution and run time. Like pay-as-you-go pricing: Run code, pay for that run.

When there's no traffic, there's no cost. 👌

Scalability

Google likes to call serverless architectures ‌from prototype to production to planet-scale. You don't want to use serverless at planet scale though.

But Google is right: Serverless scales. A lot.

The details on why serverless is scalable are tricky to get into. It has to do with how much work you can pack into a single physical machine ... but there is a machine somewhere and you might run out of those with truly planet-scale work 🤔

It comes down to this: You're running a hyper-elastic server that adapts to changes in workload at millisecond precision. In theory this gives you perfect utilization.

Serverless cons

As much as I think serverless is the next big thing in web development, it's not all fun and games out there. There are disadvantages to using serverless.

Higher latency for low workloads

Performance comes in two flavors:

  1. Latency
  2. Speed or bandwidth

Latency talks about how long it takes from making a request to getting a response. Speed talks about how long it takes to do work.

Each execution is fast because the code is small and servers are fast. A few milliseconds and you're done.

But latency can be high. You're hitting the server cold every time. That means each request waits for the computer to wake up.

That's why providers keep servers live between requests. But only if requests come often enough.

For low traffic applications with low latency demands, you might need a constantly provisioned server.

Sometimes costly

As Bank of America found out pay-as-you-go pricing gets expensive when used a lot.

Serverless providers charge based on number of requests and resources used. You pay for every request and every millisecond of computation. Known as "compute".

If you have a lot of requests or long runtimes, you can rack up the costs beyond what you'd pay with your own servers.

For example: You wouldn't want to train a machine learning model on a serverless architecture. Learned that painful lesson with my first startup in 2010 and GoogleAppEngine. Flicked the On switch and the credit card melted 🔥

Another bad case for serverless are high traffic applications. At millions of requests per second, you're better off on your own.

Serverless becomes expensive at high loads. Where the balance tips depends on what you're doing, how much time you're saving, and how much it costs to do yourself.

Vendor lock-in

This one's simple: You're building on somebody else's infrastructure.

If that infrastructure changes, you're screwed. If they crank up the price, you're screwed. If you want to move, you're screwed. If you want to deploy your own, you're screwed.

You can do all those things, but it's a tedious and difficult task that might break your app. You're not building features or working on your business while you migrate.

Startups rarely live long enough to have this problem. Enterprises take defensive measures like multi-year contracts with strict service level agreements.

Avoid building architecture agnostic code. It's hard and you're not likely to need it.

Systems complexity

You're paying for the simplicity of your application code with system complexity. Individual functions are simpler and easier to test. Complexity comes from how they interact.

We'll talk more about that in the Robust Backend Design chapter.

The verdict?

It depends. You will have to think about this yourself :)

Ping me on twitter, if you'd like some help.

I like to use a series of questions:

  • "Will this require a lot of computation? if the answer is yes, I consider building my own servers.
  • "Will this have ridiculously high traffic? if the answer is yes, I'd choose serverless because I hate doing DevOps. High traffic hopefully means I can afford a professional :)
  • "Is this a small side project idea?" serverless all the way
  • "Does every request need to be served under 10ms?" you're gonna have to roll your own

What do you think, is serverless right for you?

Cheers,
~Swizec

PS: I'll be raffling 5 signed copies when Serverless Handbook publishes on Mar 31st

Did you enjoy this article?

Published on March 25th, 2021 in Mindset, Serverless

Serverless Handbook launching soon

Leave your email and be among the first to know when Serverless Handbook launches.

The perfect resource that shows you how to jump into modern backend and understand any backend. A why and how book.

Serverless Handbook

Learn everything you need to dive into modern backend. Understand any backend

these chapters gave me knowledge which is sufficient to build real products and the hand-drawn diagrams and high-leveled descriptions gave me the feeling that i don't have any critical "knowledge gaps"

Launching soon, be the first to know.

Join over 10,000 engineers just like you already improving their careers with my letters, workshops, courses, and talks. ✌️

Have a burning question that you think I can answer? I don't have all of the answers, but I have some! Hit me up on twitter or book a 30min ama for in-depth help.

Ready to Stop copy pasting D3 examples and create data visualizations of your own?  Learn how to build scalable dataviz components your whole team can understand with React for Data Visualization

Curious about Serverless and the modern backend? Check out Serverless Handbook, modern backend for the frontend engineer.

Ready to learn how it all fits together and build a modern webapp from scratch? Learn how to launch a webapp and make your first 💰 on the side with ServerlessReact.Dev

Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com

By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️