What is Serverless?

It’s the future, y’all.

The TL;DR

• Serverless has become a catchall for applications and products that operate without the need for teams to manage their own servers.
• Traditional applications run on servers, requiring complex and resource-intensive management.
• In practical terms, serverless often adopts a function-based architecture instead of a traditional app-based one.
• Leading cloud providers, such as AWS, provide serverless platforms, with AWS Lambda being a prime example.

Diverse Interpretations and Growing Popularity

• The term “serverless” is interpreted in various ways by different individuals.
• Despite these diverse meanings, serverless is gaining popularity and holds the potential to influence the future of app development.
• The FUTURE!

Context: Backend Architecture Today

As a developer crafting your app, consider how you deploy your backend. Most apps comprise two key elements:

1. Frontend: This is the user interface found in web browsers or phone apps.

2. Backend: This houses the app’s logic and data, typically involving a database and APIs.

Take Medium as an example.

• Medium’s frontend, built with HTML, CSS, and Javascript, allows me to write posts, view analytics, and send emails.
• The Medium backend stores content, manages recipients and stats, and incorporates APIs for mail delivery and subscription additions.
• The frontend and backend collaborate to present what you see on your favorite app’s page.

Developing and deploying the backend is often the most intricate task, enduring the most “stress” and requiring scalable solutions. As user numbers rise, backend components, such as databases, need to efficiently handle an increasing number of queries, illustrating the potential complexity.

When ensuring your database and APIs can handle your app’s traffic, you have a couple of choices:

- Scaling Vertically: Boost the capacity of the server running your database — make it bigger, faster, and stronger.

- Scaling Horizontally: Duplicate your server and distribute the load among multiple copies.

Scaling vertically is straightforward (just instruct AWS to consume more of your budget), but it’s not sustainable or cost-efficient. In contrast, scaling horizontally is notoriously challenging.

Scaling isn’t your only hurdle when running your backend. Guaranteeing server performance involves stack-dependent tasks, such as:

1. Setting up servers, installing necessary components, and so on.
2. Monitoring your app to ensure smooth request processing.
3. Keeping an eye on hardware to check CPU, RAM, and Disk utilization.

These are just a few of the challenges engineers (especially those with a DevOps focus) face when managing their own servers.

🚨 Don’t Be Confused

Scaling requirements extend to frontends as well. Components that act as a bridge between the frontend and backend — such as when using a web framework like NextJS — must operate on a server. While our focus is primarily on the backend in this discussion, it’s important to note that this is a somewhat simplified perspective.

To navigate through the complexities, let’s consider three definitions of serverless below. The third and final one is particularly crucial, as it aligns with what developers generally mean when discussing serverless.

1) Serverless as SaaS:
When developers outsource any part of the software stack to a third party via Software as a Service (SaaS), it qualifies as serverless. Examples include using GitHub for code hosting, Auth0 for app authentication, Datadog for monitoring, and Stripe for payments. While acknowledging that these SaaS solutions eliminate the need for developers to build and maintain their infrastructure, it’s not the typical sense of serverless. This is often referred to as the MBA definition — i.e., it’s considered less relevant.

2) Serverless as PaaS:
Descending further into the infrastructure layer, outsourcing parts of your infrastructure to managed services from cloud providers is another interpretation of serverless. Examples include Vercel and Netlify for frontends, Confluent for event busses, and S3 for object storage. Terms like “serverless database” or “serverless frontend” apply here.

3) Serverless as Functions:
The most specific and commonly referenced definition of serverless by developers is deploying apps through functions instead of monolithic apps and endpoints. Each major cloud provider offers its own product for this:
— AWS has Lambda
— GCP has Cloud Functions
— Azure has Functions
In essence, with serverless architecture, you don’t just avoid managing servers; you deploy your app as a series of separate functions, a departure from the traditional approach. Serverless, in this context, is both an architectural decision and a product.

So when encountering the term “serverless,” it’s crucial to consider context. Some might use the term to sound sophisticated, but as explored, not all “serverless” products necessarily replace traditional server functionalities. Approach with skepticism 🙂.

AWS Lambda and Its Counterparts: The Serverless Essence

When developers mention serverless, they’re often referring to platforms like Lambda. So, what exactly does Lambda (and its equivalents from other cloud providers) offer?

• In Lambda, your code is deployed as distinct, logically independent functions.
• These functions can be triggered either manually or through defined events within the AWS ecosystem.

Consider a scenario where you have a single function in your app responsible for inserting a new user into the database. Instead of running this function, along with all others, on a central server, you can upload them individually to Lambda. Subsequently, you can trigger these functions directly from your frontend. Remarkably, Lambda’s user interface even allows you to paste your code directly as a function.

The Irony of AWS Lambda and Its Not-So-Serverless Reality

When you trigger a Lambda function, AWS takes the reins, either by spinning up a new server or allocating it to an existing one — hence, the term serverless.

Yet, it’s ironic that Lambda, often hailed as a serverless solution, isn’t entirely devoid of servers. Here’s why:

• Lambda isn’t a database; you still need one and must contend with scalability concerns.
• Sizing Lambda functions is necessary; you must pre-allocate a specific amount of RAM to them. Sounds a bit like managing a server, doesn’t it?

In practice, Lambda and its counterparts are often employed for non-core aspects of an app. Many customer case studies focus on areas like image pipelines, analytics, or general machine learning. It’s rare to find high-growth startups running their core app logic on Lambda, or so it seems for now.

🔍 DEEP DIVE

AWS crafted a proxy service specifically for their managed database service, RDS, facilitating its connection to functions operated through Lambda. Strangely enough, on the features page of their “serverless” product, they guide you on handling the “server-full” components of your app. It’s a little SUS, IMO.

Conclusion

There’s a challenge with function-driven architectures these days — the developer experience isn’t quite up to par, especially when it comes to developing functions locally and then moving them to the cloud. For example, I had a frustrating experience with GCP Cloud Functions where testing specific data types was a headache due to limited tools for mocking or running on my laptop. That’s why frameworks like SST (Serverless Stack) are emerging to enhance the developer experience for platforms like Lambda.

On the flip side, the database space is evolving with more intriguing developments. Fauna claims to be serverless, charging solely based on usage, not on server size or similar metrics. BigQuery, a widely used data warehouse, is undeniably serverless. Although we may be on the brink of advancements, it’s definitely a trend worth keeping an eye on.