Author: Kevin Duss

Gartner identifies Serverless as one of the most significant technology trends in 2022, and while most of our customers are adopting Platform as a Service (PaaS), there is still untapped potential in Serverless.

The new serverless

Serverless originally described web applications and mobile apps whose server-side logic is composed of third-party cloud services. Typical examples of such services are databases and authentication services. This type of service is called Backend as a Service (BaaS). Serverless also describes applications whose server-side logic is implemented by customers themselves as functions, but managed by cloud providers. This type of service is called Function as a Service (FaaS). In this article, the focus is on FaaS, the newer area of Serverless. However, many operational aspects of FaaS, such as resource management, also apply to BaaS.

Functions and their special features

Functions are short-lived. Cloud providers create and destroy FaaS containers based on runtime demand. Cloud providers are entirely responsible for provisioning, allocating and scaling resources. This manifests the main differences between FaaS and other models such as PaaS: users do not have to build or manage clusters themselves and functions do not run continuously. The latter is only possible because of the premise that functions are stateless. More precisely, their state is externalised and persisted in a database, for example.

In addition to statelessness, when developing functions, attention must be paid to their execution time and latency at start-up. Execution times of functions are limited by cloud providers. The time limit is typically around 10 minutes. Start times are decisive for how quickly functions can start up, scale and process events. The start time of a function is particularly important for "cold starts", when no instance of the function can be reused. In such cases, the cloud provider must first start a new container and process before the function can start working.

The advantages mentioned do not mean that FaaS is fundamentally superior to other models. The benefits of FaaS unfold especially in event-driven architectures with homogeneous events and applications with high load peaks. For request-driven architectures with many entry points, it may be more appropriate to provide your own containers (e.g. using PaaS). The article Cloud-Native! But how? Container vs. Serverless offers a direct comparison between functions and container technologies.

Event-driven architectures differ from request-driven architectures in the way services are called. Services in event-driven architectures do not serve synchronous requests from users or applications, but react to events. Events represent state changes. For example, an architecture can provide for the sale of a product as an event. Due to the asynchronous nature of events, components can be loosely coupled. This leads to architectures that are excellently suited for functions.

Dealing with vendor lock-in

Different cloud providers have implemented their (serverless) offerings differently. A change of provider therefore has an impact on the operational tools and code used. The biggest challenge may not be the migration of a service per se, but its integration with existing services. For example, a function can be triggered directly by the messaging service of the same provider. However, if the messaging service is to trigger the function with another provider in the future, additional integration effort is required. This vendor lock-in is a risk for companies.

Various open source frameworks have recognised this risk. They enable developers to provide functions across cloud providers. Two examples are the Serverless Framework and Spring Cloud Function:

The Serverless Framework allows the definition of the required infrastructure, such as databases or API gateways, via code (comparable to Terraform). The uniform configuration with YAML files saves developers from having to know the configuration details of the various cloud providers. In this way, a function and its required infrastructure can be provided by several cloud providers.

Spring Cloud Function enables the cloud-agnostic development of functions through a palette of adapters. These adapters abstract the peculiarities of different serverless implementations. If code is to be migrated from one provider to another, the logic in the affected function does not have to be touched. It is sufficient to exchange the adapter.

The use of such frameworks helps to loosen the vendor lock-in. However, dependencies remain if vendor-specific services are used within the functions. In addition, this approach can lead to new dependencies on frameworks. If, on the other hand, Spring Boot is already part of the development stack, Spring Cloud Function can make it easier for developers to access the serverless world.

Conclusion

• Trends in cloud-native software development point in the direction of FaaS.
• When developing functions, attention must be paid to aspects such as statelessness and start and execution times.
• FaaS should not replace models like PaaS, but complement them.
• When used correctly, FaaS is cheap to run, efficient in resource use and fast to develop.
• FaaS carries the risk of vendor lock-in. The use of open source frameworks can reduce this risk through abstraction.