Swizec Teller - a geek with a hatswizec.com

Senior Mindset Book

Get promoted, earn a bigger salary, work for top companies

Senior Engineer Mindset cover
Learn more

    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.

    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

    Published on March 25th, 2021 in Mindset, Serverless

    Did you enjoy this article?

    👎👍

    Continue reading about How do you know if serverless fits your project?

    Semantically similar articles hand-picked by GPT-4

    Senior Engineer Mindset cover

    Senior Mindset Book

    Get promoted, earn a bigger salary, work for top companies

    Learn more

    Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.

    Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.

    Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help 👉 swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.

    Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers 👉 ServerlessHandbook.dev

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

    Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections

    Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog

    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 ❤️

    Created by Swizec with ❤️