Why Serverless?

To understand what Serverless is, we first need to understand what it's trying to fix! In a traditional tech stack, you'll have some sort of frontend (a website), a backend (your API), and probably a database (Postgres, MySQL, etc.). Now while this is nice to have things up and running 24/7, there's some downsides. First, it costs money to either buy servers or rent them out (think AWS) to be running all the time. Second, if you're buying then you need to pay for maintenance or if you're renting them then you're implicitly paying the bulk of the cost of when they'll need to get fixed, replaced, etc. Lastly, with a static server it can be difficult to scale quickly. This can either be a problem over the long-term with more users, or in the short-term with no one using these extra servers when all your users are asleep.

If you're starting to think static servers are a pain, you're not alone! Let's talk about serverless.

What is Serverless?

Quick rant: While I love ~serverless~ technology, I rarely enjoy buzzwords or jargon as they just confuse everyone and higher the barrier to entry. The word is everywhere and as such a blatant misnomer it confuses pretty much everyone (or maybe it was just me?) so don't worry.

So what is serverless? Serverless isn't a product (although there is one by the name) but rather a cloud computing execution model. Or in layman's terms, a way to run code. I like to justify the name as thinking about it like my application is serverless (as it doesn't live on a dedicated server) but at execution it is given a server to run on. Once the operation is over, the server is given away to someone else and again we are in serverless land. Now you might be thinking how this helps any of the issues above.

First, by not having a dedicated server, you only pay for execution time. Second, because you don't take up the bulk of the use of a server, you don't implicitly pay for the bulk of the maintenance. That cost is spread across more users, therefore further driving down your costs. Lastly, this means that your server capacity can effortlessly scale as usage scales up and down over time. This will allow for instant scaling to new demand, without the increased costs when there's use downtime.

How to Serverless?

Now this all sounds swell! But I know you're wondering how to build it. For that there's a world of solutions as everyone is trying to make it in this space but I personally like Google's offerings the best. I think they have a great mix of easy-to-use while customizable on both the command line and in their console. Their three main serverless offerings are Cloud Run, Cloud Functions and Firestore. Let's dive into those separately.

Cloud Run

Cloud Run is google's offering for serverless containers and it's typically used with Docker containers (as Run uses Kubernetes for scaling / orchestration). Simply create a chunk of code, wrap it in a container, and you're on your way to an infinitely scalable application!

I've used Cloud Run with FastAPI, to deploy a fully serverless, scalable, and cost-efficient backend. Let's check out how.

Create a FastAPI app

Create a Dockerfile

Deploy to Cloud Run

gcloud run deploy

It's that easy to launch a serverless API! For more information, checkout their official how-to

Cloud Functions

Cloud Functions is the equivalent of AWS's Lambda. For functions, there's no container needed, only some code and a specified entry point so google knows what to execute. Additionally, Functions has the capability to either be scheduled, triggered over HTTP, or triggered by an event which includes saving a document, writing to storage, and much more!

Although I've seen people create an entire backend using functions, I prefer to use Cloud Run for that. I typically use Functions for micro-services and various data pipelines that are needed over time. Let's take a look!

Create a simple function

Deploy to Cloud Functions

gcloud functions deploy hello-http --entry-point hello_http --runtime python38 --trigger-http --allow-unauthenticated]

Easy as ever! For more info, checkout their official how-to

(Functions just release a 2nd-gen version which is game-changing, I'll be writing an article about it soon)

Firestore

Firestore is different from the other two as it doesn't execute user code but rather is a NoSQL database. While there are new products for serverless SQL (like CockroachDB), most serverless databases have been NoSQL. Firestore is essentially a folder of JSON's which are filterable, searchable, and sortable while still performant. It's a good solution for simple applications with minimal need for the relational part of SQL. Additionally, like everything else serverless, it's incredibly cheap and infinitely scalable!

Let's look at a simple solution to write and read data.

Note this only shows the simplest use case, for more info checkout their official docs

Summary

Thanks for reading! I hope this helps on your serverless journey and feel free to post any insights or questions in the comments!