Hey Everyone,

Hope you’re all having a fantastic day!

Today’s email will be a tech dive on Serverless Applications.

Tech Dive - Serverless

In case you weren’t aware, the idea of Serverless has been blowing up over the past few years. It’s one of the hottest topics in software architecture.

This will be a tech dive on what serverless is and the benefits/drawbacks.

What is Serverless?

The traditional way of building a website is to have frontend code, written in HTML/CSS/JavaScript and backend code, written in a server-side language (PHP, Python, Ruby, Java, JavaScript, etc.).

You’ll have to build and maintain a web server, most likely using a framework like Django, Express, Flask, Laravel, etc. You’ll implement authentication, storage, message brokers, etc. You’ll also have to handle things like adding load balancers, reverse proxies and redundancy so that your service is highly available and can scale as you grow.

This can get very expensive and is a ton of work! Do you really need to handle all of this stuff yourself?

Not anymore!

With Serverless Applications, you can use a third party service to handle all the tasks you’d traditionally need a webserver for. You use these services through HTTPS APIs that you can access from your front end code. This makes the architecture Event Driven.

To give an example, let’s say you want to create a clone of LeetCode. You’ll build a front end which comprises the dashboard for users to see all the interview questions, individual pages for all the interview questions (with the problem and an editor for users to write/run their code) and a page for users to create accounts / login. So your front end would be the same as with a traditional application.

However, you don’t have to build a backend. When a user creates an account, you can just send a HTTPS call to a third party service that you’re using for Authentication (Auth0, AWS Cognito, or whatever). You’ll need a database to keep track of what problems a user has solved and you can just use a third party service that provides a NoSQL or SQL database ( Firebase or S3). If you need a message queue then you can use something like AWS Simple Queue Service (SQS).

But, you’re probably wondering how can you write code to check the user’s solutions? Like, if a user writes Python code to solve the Two Sum question, how can you run that code and check all the test cases?

Well, you can use cloud functions for this.

Using a service like AWS Lambda you can write a cloud function that takes in a user’s ID, the code for their solution and the interview question ID.

Then, the cloud function can query one of your databases (again, implemented with S3 or something) to figure out the test cases for that interview question ID. After, the cloud function can execute the solution code and check all the test cases.

If the code passes all test cases, the cloud function can then write to your database ( the database that tracks which problems a user has solved) that the user has successfully completed the interview question (using the user ID provided to the cloud function).

The third party services with Serverless can be split into two main categories

• Backend as a Service (BaaS) - Every website needs things like Authentication, Storage, Message Brokers, Push notifications, etc. All these things can be abstracted away into a third party service so that developers don’t have to implement them. Services that handle this are things like Auth0, AWS Amplify, Firebase, Upstash (serverless database for Redis), etc.

• Functions as a Service (FaaS) - There are services that are specific to a web application that you’re building. Like the “check if a solution is correct” service from our LeetCode example. For these things, you can use Cloud Functions like AWS Lambda. You write your code as a function and host it on AWS’s platform and just call it from your frontend whenever you need it as an HTTPs call.

Pros of Serverless

1. Requires no management of Server hosts/processes - you don’t worry about configuration or implementation of your BaaS or FaaS. You don’t care about how Google is implementing Cloud Functions in GCP, you can just use the API.

2. Automatically auto-scales and auto-provisions based on load - Google will handle adding load balancers or redundancy as your usage of the cloud function grows. If they see that your cloud function is starting to get more requests, they’ll automatically add redundancy so that your app doesn’t slow down.

3. Cost is based on usage - Google will only charge you when your cloud functions are run by their servers. If your cloud function isn’t being called by your frontend, Google won’t charge you! This helps a ton of your traffic is inconsistent. If your app has no traffic, you don’t have to worry about being charged. If your app suddenly goes viral, Google will handle the auto-scaling and will only charge you for that usage.

4. High Availability - Google is handling the availability ( and they’re quite good at that!). You don’t have to worry about your web server going down or keeping it updated.

Cons of Serverless

1. Latency & Cold Start - Since you’re being charged based on usage, Google won’t be running your cloud function on a server unless it’s been called recently by your front end. Therefore, if your front end is quiet for a time period and then makes a call to the cloud function, there will be increased latency. Google has to spin up a new instance of the cloud function on their server and only then can they respond. This is called a cold start. This latency is also an issue if your traffic is increasing very quickly. Google will have to provision more servers to run your cloud function in real-time and that will add more latency.

2. Vendor Lock In - You’re dependent on third party vendors. They can randomly decide to increase the prices on you and then you’ll have to go through the hassle of switching to a different vendor. This can be a pretty difficult thing to do and adds a lot of technical work.

Serverless Computing massively increases the amount of leverage that a small team of developers have. The developers can just worry about building out the front end code and abstract away implementation of the backend.

Have any questions or comments? Feel free to reply to the email!

Best,

Arpan