Serverless: Use the potential of Function as a Service

Sometimes serverless is more - for the right use cases and taking vendor lock-in into account.

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.

FaaS_vs_PaaS_en.jpg
Higher abstraction of server-side logic with FaaS compared to PaaS

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.

Three advantages of FaaS

Why should developers be restricted in terms of server-side state and execution times?

Lower operating costs

Cloud providers take over the management of infrastructure and applications. Since they offer this standardised service to a large number of customers, there is an economy of scale. This economy of scale for the providers in turn leads to lower operating costs for the customers. This is not only the case with FaaS, but also with models like PaaS. However, since the automatic scaling in FaaS is more fine-grained and goes down to 0, the cost advantage is more pronounced here. Customers only pay for the computing power they really need. This results in cost savings, especially for applications with sporadic incoming calls or strongly varying traffic.

Simpler operation

By providing and operating the entire infrastructure, cloud providers reduce the complexity of system management for customers. This goes hand in hand with time savings in software development. These savings reduce companies' time-to-market, which is crucial for competition. They also enable companies to experiment with new ideas and rapidly prototype. The article Speed in development thanks to cloud-native looks at the peculiarities of fast and agile cloud-native development.

Sustainability

Data centres have exploded in number and size over the past decades and have massive energy consumption. A significant proportion of this is caused by servers that are switched on but unused. Companies are cautious and prefer to provision too much server capacity rather than risk their systems being unavailable. With FaaS, these capacity decisions no longer lie with the individual companies, but with the cloud providers. They can make the decisions aggregated across all their customers and thus use resources more efficiently.

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.

Your ipt-Experts

How can we support you?