Why serverless technologies are the way to go for startups

Looking back at the past two decades, starting a tech business has never been easier. From a technology standpoint, that is. In the beginning of the 2000’s you would’ve had to code so many things yourself, that now, are a given. User sign-up and login, setting up and administrating servers, content-delivery, message queueing and so much more.

Sure, on the flip-side it has become easier for everybody else, too. For every tool or service you’ll find a gazillion alternatives, but that’s an article for another time.

Whether you want to build prototypes or your next startup, there’s one thing you should not skip over: serverless. It saves you money when you’re just starting out, scales very well and still leaves you all the options to grow.

Oh and by the way: when I say “serverless”, I’m talking about the entire ecosystem from functions to databases and all the connective services in between.

Pay only for what you use

With the advent of serverless we’re reaching another degree of freedom and that’s the freedom of not having to burn through our precious cash all too quickly when starting the next business or building a prototype to evaluate a business idea.

What used to be a couple compute and database instances for our various side-projects, MVP’s and prototypes can now be just a bunch of functions and a serverless key-value store. And those functions only cost you money when they’re executed. Why would you want to pay tens to hundreds of dollars for infrastructure that’s just sitting around, waiting to be used by a handful of people, often around the same time of day?

Scaffolding goodness

Building your prototype is really fast too.

You have a couple of options here. If you’re cool with using AWS, you could go with AWS Amplify. It’s a set of libraries, UI components and a command line interface. Getting set up is as easy as answering a couple of questions and boom, you have a little React app that’s hosted on S3 with a CDN in front and a cloud database either accessible via REST API or GraphQL.

An excellent alternative is the Serverless framework (mind the capital S). It’s platform agnostic but you’ll get the best developer experience when using it with AWS. It gives you a bit more control but that comes at no real cost in development speed. Setting up a React or Next.js app, building an API with functions and having all the infrastructure set up as needed is blazingly fast. It’s just a wee bit more in configuration.

My recommendation is this. If you know how to use GraphQL and you want to quickly test a product idea, go with Amplify. If GraphQL is not your thing, go with the Serverless framework, use DynamoDB as your database technology. That leaves you with a stack that’s easily extended once your prototype turns into a product.

I recently built imgregex.com: an API project built on the serverless framework, with a landing page done in Next.js and Tailwind CSS all in an extended weekend. I’m currently in the validation stage, so I didn’t build any user management, dashboard or statistics. Still, all that in 3-4 days of work? Not too bad.

And when more users come? Then it’ll just gracefully handle those and the ones after that without breaking a sweat. Let’s talk about scaling.

Scaling out of the box

Once your prototype or MVP picked up steam you don’t have to do anything extra to keep it snappy. That’s in stark contrast to traditional infrastructure: you’d need another box to handle the uptick in requests because one doesn’t cut it anymore. A load-balancer too. All of a sudden things get a little bit more complicated and the costs are starting to pile up.

Granted, you’re also (hopefully) making more money now, but maybe going from just one to two developers or having to hire a DevOps engineer is still a bit too much for your budget.

For example, my product CaptureKit is being used by a company extensively. They upload thousands of scans a month and process them with a team of data typists. Let’s look at the serverless portion of the operating costs: $2 for DynamoDB, $0 for Lambda because I’m within the free usage tier, $4 for SQS and a few cents for the CDN my web app and assets are being served from.

It’s ridiculous if you think about it. A fairly complex WebApp that takes thousands of PDF files apart, runs its pages through an OCR service, automatically captures machine readable text and powers the web interface for a team of 3-4 data entryists to capture remaining handwritten answers and other irregular input. All that for roughly $5 a month in infrastructure costs? I’d say that’s pretty mindblowing.

Of course, I have other costs: OCR, S3, DNS and a container instance I unfortunately still need to keep around, but those are costs you’d have in any scenario.

Okay, let’s say I add another equally sized customer to the mix. Again, $2 for DynamoDB, maybe I’m running over the threshold this time and add $1 in Lambda costs. SQS costs will stay the same because pricing doesn’t increase by number of messages transmitted but by times a queue is polled throughout the day, so that’s fixed.

With serverless you know perfectly well what a 10X increase in traffic means in terms of costs. Those increase linearly and predictably.

That said, there might come a point where serverless isn’t the best choice for all of your infrastructure.

Hitting the limits of serverless

As I alluded to in a previous article, using serverless functions for continuous high loads is not recommended. Serverless shines when executions are infrequent and unpredictable, but if you find yourself in a situation where traffic to a resource is uniform all throughout the day in high volumes, you might want to think about going back to servers or at least swap your API Gateway out for an Application Load Balancer (ALB).

First of all it’s not a given that your traffic develops that way. Maybe it’s perfectly normal for your business to keep having infrequent access while also being successful and growing. In this case serverless will keep serving you well.

If your business grows and you’re starting to see uniform traffic patterns as I described earlier, you’re now in a position to re-architect your application to fit your new situation. There’s a sensible architecture for every stage of your company’s development. With more clients and more money coming in you’re now in a good position to make that transition.

There’s no telling what your new architecture will look like, but it’s fairly certain that you will keep a good portion of your serverless infrastructure around. DynamoDB for example is still an excellent choice for a database and not all parts of your product or service will see a ton of traffic. It’s best described as an evolution, not a re-write.