Context

Serverless is a trend in Software Architecture that reduces the notion of infrastructure allowing developers to not have to worry about load balancing, multithreading and other infrastructure issues, so that they focus only on their code, since the Serverless platform itself manages the resources.

Advantages and disadvantages of a Serverless Architecture

Serverless still has some way to go to be a widely used technology, but at the same time, as progress has been made, it offers many advantages for organizations by providing a simplified programming model to create applications in the cloud, abstracting most of the operational concerns. so it is safe to say that it will eventually define the way in which organizations develop, deploy and integrate their applications.

Advantages of the Serverless Model

• No more server management: Although "serverless" computing is done on servers, developers do not have to worry even about their existence at the time of application deployment, since the provider manages that automatically, thus reducing the investment required in DevOps and the time developers require to build and extend their applications. Applications would no longer be limited by server capacity or computing power.

• Pay-as-you-go backend: As with a "pay-as-you-go" data plan where you are only billed for the amount of data consumed, in serverless computing, you are only billed when the application code is executed. Application code is only executed when backend functions are executed in response to an event, and the event autoscales on demand, and provisioning remains dynamic, accurate, and instantaneous.

• Serverless Computing = Scalability: Serverless applications scale up and down on demand, allowing applications to go from hundreds of compute instances to one, and back again, in seconds, to accommodate complex demand curves. Serverless computing vendors employ algorithms to start, run, and terminate those instances as needed (in many cases using containers). Consequently, serverless applications can handle millions of concurrent requests, or one single request, with the same throughput.

• Faster deployments and updates: Serverless infrastructure does not require complicated backend configurations for an application to work. A serverless application is a collection of vendor-managed functions rather than one large, unmanageable, monolithic block of code. When releasing updates, patches, and fixes, developers only have to alter the affected features. Besides, new functions can be added to reflect a new feature of the application.

• Locations help reduce latency: Serverless applications are not hosted on the origin server, but rather in multiple locations on the provider's infrastructure, so that, in response to demand, the closest location triggers the event and function. This reduces latency because requests now don't have to go all the way to an origin server.

• Serverless computing helps reduce cost for most use cases: Serverless architectures are more efficient at reducing costs for applications with uneven usage. If the application alternates periods of high activity with instances of little or no traffic, renting space on the server for a fixed period of time makes no sense. Paying for always-on, available server space, is not profitable when it will only be used for a fraction of the rental period.

Disadvantages of the Serverless model

And yet, “no one is perfect” and as with the microservices model, serverless computing is not suitable for all use cases, and besides, its use also creates other complexities.

• Long workloads: If your applications need to run long workloads (such as batch processes that take twelve hours per day, video on demand, or model training) where the applications would be running most of the time, serverless computing will not be practical and its cost will be higher in the Cloud provider than it would be provisioning infrastructure.

• Network Dependency: Building an application on a Serverless Architecture will often involve event streams calling functions that communicate exclusively over standard network protocols, meaning that a network outage or interruption of any kind (often out of our control) will interfere with business operations – and, as the number of deployed features increases, so does the risk of a network outage, jeopardizing any of these services.

• Latency: On the other hand, the network also implies that latency is introduced into the system, and that must be taken into account.

• Management overload: With a Serverless Architecture, a product is divided into a network of smaller functions. As a result, there is an overload that is created in managing these functions, which is the reason why many organizations are not ready to fully embrace microservices, let alone functions.

• Dependencies: Let's imagine hundreds of application components that depend on one single function with an established contract (API specification) – and now let's imagine that the microservices team wants to redesign (or even slightly modify) their specification. The organization must not only coordinate this change across teams, but also keep track of who reports to whom at all times.

• Strict contracts: Related to the previous point, developers should be careful to define a function API specification that is robust enough to provide business value long after the initial release. This kind of forecasting is rare, if not impossible, in some organizations.

• Orchestration: In many scenarios, it will be necessary to orchestrate various functions to compose a business service. Not all providers support it and, among those that do support it, each provider has opted for a solution for this.

• Transactionality: the business process orchestrating the functions will have to manage compensations to a problem in the execution of a function.

• Too easy to create a function: We can classify this as a strength, but also as a weakness. The ability to deploy and incorporate features so easily can lead to an excess of features.

Serverless Offering

The main cloud providers already have offers on this serverless paradigm. In addition to offerings from Amazon Web Service and Microsoft Azure, serverless computing is a promising market for all cloud computing providers, and is supported by leading application development technologies (such as Spring).

Currently, Amazon is the leader in this computing, capturing more than 80% of the market share in 2020, and Microsoft is in the second place.

Analysis of the Choice of Serverless Technology for Onesait Platform

Below is a summary of the analysis that has been carried out on the Platform for choosing the most appropriate Serverless technology to incorporate/support on the Platform.

• Cloud Independence: One of Onesait Platform's mantras is to be able to work with the different clouds, in addition to making Cloud and On Premise architectures compatible. These architectural considerations did not recommend the use of proprietary technologies such as AWS Lambda, Azure Functions or Google Functions, which, except in very specific scenarios, involve execution in the provider's Cloud.

• Simple/Native Deployment in Cloud Providers: On the other hand, although independence from the Cloud is sought, the Platform's commitment to the Cloud is clear, including offering the platform in SaaS mode. Therefore, the selected serverless technology should be able to be deployed easily, even natively, in the main Cloud providers.

• Support On Premise Deployment: Although our commitment to the Cloud is clear, we cannot forget that we still have many Platform projects and products deployed in customers' CPDs (and that many of these large customers have their own private Cloud strategy), which forces us to ensure that this technology can be deployed on premise.

• Open-Source Technology: Onesait Platform is open-source software published on GitHub under the Apache2 license, and the product team supports it. Ideally, the technology should also have an Apache2 license, so that it can be integrated and marketed without restrictions.

• Multilanguage Support: a clear winner emerged from the previous points: Spring Cloud Functions, since, on the one hand, it is part of the Spring ecosystem, which is the base technology of the Platform (and Onesait Technology); and on the other hand, it offers support for deployment in the main Clouds. However, it lacked first-level support for feature development in several languages ​​such asPython, Go, Node.js, or C#, and Platform has many use cases in which technologies like these are used for development, for example for the development of AI models based on Python, which also fit very well to execute as functions once trained.

• Compatible Deployment Strategy: the platform deployment strategy is based on containers orchestrated by Kubernetes and managed by a CaaS, with the ability to integrate with Cloud services (more details in this Link), so to avoid managing multiple technologies, it was highly recommended that FaaS functions could be deployed as containers within a Kubernetes cluster (including those of Cloud providers).

• Simplicity and Extensibility of the Technology: we cannot and do not want to forget that one of the objectives of the platform is to simplify the use of technologies, therefore the Functions developer should be able to do it easily, and the platform team should be able to extend this technology to integrate it into the Platform and extend it when necessary.

• Maturity, Community, Popularity, Extensibility, Documentation and Support: in this last point of the analysis, we have added several considerations (in the analysis phase they were studied separately), such as the maturity of the technology, the community that existed around the technology, the popularity of this technology, the existing documentation (quality and quantity), and the support of a great player that guarantees the evolution and maintenance of the technology.

From this analysis, three finalist technologies remain:

• Apache OpenWhisk for which IBM is the main contributor and offers it as a service in its Cloud.

• Spring Cloud Functions that, in addition to being part of the Spring ecosystem, can be used as a facade for AWS Lambda or Azure Functions, …

• Fn Project supported by Oracle and offered as a service in its Cloud.

The first one thta we discarded was Spring Cloud Functions, because it lacked a fundamental feature, which was multi-technology support, while the other two do support it.

In the final analysis between OpenWhisk and Fn Project, we finally opted for Fn Project, because, although OpenWhisk is somewhat more popular and has good documentation, it is much more complex to be used than Fn Project (for example, it drags various technologies). Besides, Fn Project offers integrations with technologies like Spring Cloud Functions (allowing you to create Spring Cloud Functions that run on the Fn Engine) and GraalVM.

Technology Selected to Incorporate in Platform: Fn Project

How Does it Work?

Fn is built on Go and its architecture is based on Docker. It is made up of two main components:

• The Fn command line, which allows you to control all aspects of the framework (such as function creation, deployment ,…) and to interact with the Fn server:

  Open

  

• The Fn server, which is a simple Docker application

  Open

  

Creating a function with Fn is as simple as:

• Create the role with the Fn CLI: Fn generates the Fn configuration file and a simple project based on the selected technology template.

• Deploy the function with the Fn CLI: This Pushes the function's Docker image to the chosen Docker repository (either local or remote) and notifies the server of the existence and location of this latest version.

The functions deployed in Fn are executed in isolated containers, which allows the support of many languages. In their examples, they even explain how to generate a function from an existing Docker image (see). Also, for added convenience, Fn offers a set of built-in runtime templates, making it easy to boot into a wide variety of languages ​​and versions (Go, multiple Java versions, multiple Python versions, etc.).

In Fn, function arguments are passed via STDIN, and their return value is written to STDOUT. If the arguments and return values ​​are not simple values ​​(for example, a JSON object), then they are serialized by an abstraction layer provided by Fn itself, in the form of a Function Development Kit or FDK.

Architecture

In execution, the architecture of Fn is this:

Where a load balancer provides a frontend to multiple Fn servers and each server manages and executes the function code as needed. Servers can be scaled as needed.

Fn UI

Fn has a UI that allows you to manage and interact with the Fn server, allowing you to see metrics about the deployed functions:

As well as invoke them: