Defining Serverless — Part 1

In case you’re new to my articles: Serverless Architecture is a new approach to building systems in the cloud. It incorporates Backends-as-a-Service (BaaS) — vendor-hosted, highly scalable, data and logic components to handle our needs for databases, messaging platforms, user management, and more. Additionally Serverless Architecture includes Functions-as-a-Service (FaaS) — the ability to write custom server-side software in small, event-triggered, functions, deployed to a fully-managed platform. FaaS outsources all deployment, resource allocation & provisioning, scaling, operating system maintenance and process monitoring.

In our recent ebook — ‘What is Serverless?’ John Chapin and I include a chapter to more clearly differentiate Serverless from other cloud-native approaches (it’s Chapter 5 for those following along.) We say:

“It is worth putting some more precise definition around the term Serverless so that we can at least clarify our understanding of what we’re getting, and so that we can more effectively judge various technologies to see which is best for any given context.”

Serverless applications are ones that are implemented using Serverless services. A Serverless service is one that entirely, or very nearly entirely, exhibits five common traits. This series of mini articles describes these five traits, namely that a Serverless service:

1. Requires no management of Server hosts or Server processes (explained below)
2. Self auto-scales and auto-provisions, based on load
3. Offers costs based on precise usage
4. Has performance capabilities defined in terms other than host size / count
5. Has implicit High Availability

Trait #1 — No management of Server hosts or Server processes

When most people start learning about Serverless, this is the element that is most apparent. We are building server-side software solutions, but the servers themselves are all abstracted. They’re still there somewhere, behind the scenes, but we have no need to consider them.

With products like AWS Lambda our compute capability is a nebulous platform of event-driven function execution. With user management products like Auth0 we cannot see any implementation behind their API. With AWS S3 we store our objects in a ‘bucket’ that has no visible connection to any network file servers.

The most obvious conceptual disconnect from servers, when using Serverless, is with regard to server hosts. In other words we’re not concerned with virtual, or physical, server machines. A side effect to this is we are no longer concerned with host-level networking.

However, just as important is the removal from our view of server processes or components. We are certainly no-longer concerned with operating system processes, or the management of operating systems at all. In this aspect Serverless is very similar to Platform-as-a-Service (PaaS.)

But where Serverless goes beyond a traditional PaaS, and in fact most usages of containers, is the removal of the concept of a long lived ‘server’ component that we define, ready and listening for requests. We configure capacity, in the case of Backend-as-a-Service, and we define event-driven functions, in the case of Functions-as-a-Service, but nowhere in the Serverless model is a long-lived component instance that we manage ourselves.

This is quite a change from how we’ve built server-side applications before, and with it comes the need for significant re-architecture. It also requires a change in how we operate our software, especially in the realm of monitoring. It’s no longer useful to be concerned with metrics of an individual server instance, instead we should look to higher-level metrics such as request processing time and count.

In Part 2 we address Trait #2 — Self auto-scale and auto-provision, based on load.

Need help with Lambda, or other Serverless technologies? We’re the experts! Contact us at Symphonia for advice, architectural review, training and on-team development.