Glossary ● Serverless

Ever since the term “serverless” made its debut in 2012, its usage has grown in popularity. However, a concise and accurate definition is not readily available. This article provides a definition for technical and non-technical stakeholders.

This blog post provides a concise and accurate definition of the concept serverless.

Model of computation

The remainder of this blog post is based on a minimal model of computation:

A software system is composed of a set of resources, such as computational resources, network resources, or storage resources. Additionally, a software system handles a set of application events, also referred to as requests.

There are four relevant actions to consider: A software system must be able to acquire and release a set of resources. In addition, a software system must be able to receive events and process events.

In all cases, an event cannot be processed if the required resources are not yet acquired.

Traditional approach

Figure 1. Event Ordering in a Traditional Environment

In a traditional environment the operator of a software system must acquire the necessary resources a priori, that is, before the application event enters the system.

Here, an event cannot be received if the required resources are not yet acquired.

Example

For example, in the context of Kubernetes, the traditional approach may utilize a Kubernetes Deployment Object. The Deployment Object triggers Kubernetes to acquire a set of Pod Objects and therefore a set of containers immediately.

Once the containers are acquired the application may receive and process events.

Serverless approach

Figure 2. Event Ordering in a Serverless Environment

In a serverless environment the software system may acquire the necessary resources on demand, that is, after the application event entered the system.

Consequently, in a serverless environment the software system must be able to determine the required set of resources based on the application event itself.

Here, an event cannot be processed if the required resources are not yet acquired.

Example

For example, in the context of Kubernetes, the serverless approach may utilize a Knative Serving Object. The Serving Object triggers Kubernetes to acquire a set of Pods and therefore a set of containers if and only if an application event is received.

Once the containers are acquired the application may process events.

Cold Path and Hot Path

Figure 3. Cold Path and Hot Path

Typical implementations of a serverless environment do not release resources after processing an application event immediately. Instead, once acquired, resources are held in anticipation of additional application events for some period of time.

Cold Path refers to the situation where receiving an event and processing an event are interleaved by acquiring resources. Hot Path refers to the situation where receiving an event and processing an event are not interleaved by acquiring resources.

Auto Scaling

Auto scaling refers the capability to acquire and release resources on demand in response to application load. For example, load may refer to CPU utilization or memory utilization.

At first glance, auto scaling itself conforms to the defining characteristic of a serverless environment. However, auto scaling is an orthogonal concept applicable to traditional and serverless environments alike:

Auto scaling refers to the acquisition and release of additional resources in response to application load.

According to this notion, serverless environments are a combination of serverless capabilities and auto scaling capabilities:

Conclusion

Contrasting a traditional environment and a serverless environment can be accomplished by examining the respective order of events. In a traditional environment, acquisition of resources must happen a priori, i.e. before an application event is received and processed. In a serverless environment, acquisition of resources may happen on demand, i.e. after an event is
received but before the event is processed.