Slowly, scalability has snowballed to become an all encompassing behemoth set to eat the software development industry.
Gone are the days where you setup a small Rasberry Pi, open up public access and host your website from your basement — it isn’t scalable enough! No longer can we create simple HTML & CSS pages — if we were to increase the team, simple HTML & CSS gets sloppy. In the wind are the time we choose to use whatever database we feel like —SQLite has a single connection pool, and therefore bottlenecks down the whole system.
2021 will be the year of serverless — the year that the software development industry gets turned on its head. Lambdas, REST databases, micro services have taken over. Servers have become something that application engineers take for granted, because of all the tools of the new development age — all because of a single question: “what if I need to scale?”.
Hopefully, after reading this article, your question becomes a much more manageable and realistic “Will I need to scale in the next 3 years?” (I choose 3 years because a lot of developers look 20 years in the future and say, “Yeah I’ll need to scale in the next 20 years!” 20 years is plenty of time to scale. 3 is much more reasonable.)
So how do we get from “What If” to “Will I”? Start by asking yourself the following questions.
What is the purpose of me building this?
This is mostly for solo hackers or small teams. If you’re building just to learn how to build serverless, than that’s great — go for it! Add the tool to your toolbelt. But if you’re attempting to build serverless because your product is going to make you millions, I recommend you slow down — have you validated your idea? What’s the point of building a scalable application that no one will ever use? I recommend you send out some simple surveys — try to get a rough mockup of your app before you build the whole thing.
Then, if your growth is explosive, you can consider going serverless.
How many people is this app going to realistically service?
If you’re building an internal application, I highly recommend you optimize for development speed rather than scalability. It doesn’t make sense to build for 1M+ people if your company has 5 employees working out their garage.
If you’re building a user facing product, figure out your SAM — serviceable addressable market. Plan to scale to that SAM first, and then worry about the TAM (Total …). If your estimations were much lower than the amount of customers you ended up having, that’s fine! You now have traction and the ability and funds to scale further.
Do I need to scale right now?
Managing a small betalist of users is much easier than managing a large, roaring mob. Some startups choose not to scale initially intentionally, so that when they release to larger groups, they can already have general metrics to plan off of — take Clubhouse, the newest Unicorn that has a small beta list program, even if millions of users are clawing at the door, trying to get in.
What most developers get wrong is when they need to start thinking of scaling. SQLite persists some of the biggest websites on the web today — a database that many developers “graduate” from using because they feel single connection access is too slow. There are stories of developers who hit viral levels of visits on their websites, which are hosted on $5 digital ocean droplets a month and continued forward with little to no serverside hiccups.
What’s my scalability tradeoff?
In some cases, it’s much harder to build a scalable app. Something that requires state, for instance, is actually a lot more difficult with serverless, as there’s nowhere to store your temporarily required state. Or maybe you have 0 experience with Lambdas or serverless databases — expect to work 0.5x speed until you get the hang of it. If you’re trying to validate an idea, 0.5x speed can be crushing, enough to lose valuable momentum in validating core features.
On the other hand, scalable blogging with next.js is incredibly easy, especially with their built in deploy platform. With next.js, you get insane scalability from a simple React app, and thus it’s a no-brainer (if you’re coding your own blog — which might be a “why” in itself) and a nearly zero cost gain.
If the previous answers all point to “don’t scale yet”, maybe a $5 digital ocean droplet is good enough for now. Maybe sqlite is good enough for the forseeable future, and maybe you don’t really need a frontend framework for your landing page. Obviously, as in everything, there are nuances and reasons to completely flip the script, but these questions serve as starting points — because time is money, and a little bit of upfront planning can save you a lot of time in the long run.
Remember: premature optimization is the root of all evil. If you’re costing your team resources and time by trying to get them to build everything scalable, you might be a determent to your teams productivity.
Good engineers plan everything from the start, and try to minimize risk.
Good engineers follow YAGNI — You ain’t gonna need it… and a lot of the time, you ain’t gonna need to service infinity. Next time you build an app, ask yourself… will I need to service infinity?
Note: I’m a huge fan of serverless, and enjoy building serverless. I do ask myself if scalability is something that I want at every stage, and often times my answer is no. There are many cases where I do feel like building serverless, even though I probably am not going to need it — these cases are all for personal projects. I find lambda fun and interesting. I wouldn’t push my coworkers to consider serverless unless a project has viral capabilities, and we’d need to scale really fast, really fast.
If you’re looking for the right architecture for your next app, here’s a list of my favorite tech from every part of the stack, to create applications with less effort.