FaaS in detail – self-hosted FaaS

We briefly discussed FaaS earlier. As a serverless computing service, it is the foundational service for any serverless stack. So, what exactly defines a FaaS and its functionality?

As in the general definition of a function, it is a discrete piece of code that can execute one task. In the context of a larger web application microservice, this function would ideally serve a single URL endpoint for a specific HTTP method – say, GET, POST, PUT, or DELETE. In the context of EDA, a FaaS function would handle consuming one type of event or transforming and fanning out the event to multiple other functions. In scheduled execution mode, the function could be cleaning up some logs or changing some configurations. Irrespective of the model where it is used, FaaS has a simple objective – to run a function with a set of resource constraints within a time limit. The function could be triggered by an event or a schedule or even manually launched.

Similar to writing functions in any language, you can write multiple functions and libraries that can then be invoked within the primary function code. So long as you provide a function to FaaS, it doesn't care about what other functions you have defined or libraries you have included within the code snippet. FaaS considers this function as the handler function – the name could be different for different platforms, but essentially, this function is the entry point to your code and could take arguments that are passed by the platform, such as an event in an event-driven model.

FaaS runtimes are determined and locked by the vendor. They usually decide whether a language is supported and, if so, which versions of the language runtime will be available. This is usually a limited list where each platform adds support for more languages every day. Almost all platforms support a minimum of Java, JavaScript, and Python.

The process to create and maintain these functions is similar across platforms:

• The customer creates a function, names it, and decides on the language runtime to use.
• The customer decides on the limit for the supported resource constraints. This includes the upper limit of RAM and the running time that the function will use.
• While different platforms provide different configuration features, most platforms provide a host of configurations, including logging, security, and, most importantly, the mechanism to trigger the function.
• All FaaS platforms support events, cron jobs, and manual triggers.
• The platform also provides options to upload and maintain the code and its associated dependencies. Most also support various versions of the function to be kept for rollbacks or to roll forward. In most cloud platforms, these functions can also be tested with dummy inputs provided by the customer.

The implementation details differ across platforms but behind the scenes, how FaaS infrastructure logically works is roughly the same everywhere. When a function is triggered, the following happens:

• Depending on the language runtime that's been configured for the function, a container that's baked with the language runtime is spun up in the cloud provider's infrastructure.
• The code artifact – the function code and dependencies that are packed together as an archive or a file – is downloaded from the artifact store and dropped into the container.
• Depending on the language, the command that's running inside the container will vary. But this will ultimately be the runtime that's invoking the entry point function from the artifact.
• Depending on the platform and how it's invoked, the application that's running in the container will receive an event or custom environment variables that can be passed into the entry point function as arguments.
• The container and the server will have network and access restrictions based on the security policy that's been configured for the function:

Figure 1.6 – FaaS infrastructure

One thing that characterizes FaaS is its stateless nature. Each invocation of the same function is an independent execution, and no context or global variables can be passed around between them. The FaaS platform has no visibility into the kind of business logic the code is executing or the data that's being processed. While this may look like a limiting factor, it's quite the opposite. This enables FaaS to independently scale multiple instances of the same function without worrying about the communication between them. This makes it a very scalable platform. Any data persistence that's necessary for the business logic to work should be saved to an external data service, such as a queue or database.

Cloud FaaS versus self-hosted FaaS

While FaaS started with the hosted model, the stateless and lightweight nature of it was very appealing. As it happens with most services like this, the open source community and various vendors created open source FaaS platforms that can be run on any platform that offers virtual machines or bare metal computing. These are known as self-hosted FaaS platforms. With self-hosted FaaS platforms, the infrastructure is not abstracted out anymore. Somebody in the organization will end up maintaining the infrastructure. But the advantage is that the developers have more control over the infrastructure and the infrastructure is much more secure and customizable.

The following is a list of FaaS offerings from the top cloud providers:

• AWS Lambda
• Google Cloud Functions
• Azure Functions
• IBM Cloud Functions

Other cloud providers are specialized in certain use cases, such as Cloudflare Workers, which is the FaaS from the edge and network service provider. This FaaS offering mostly caters to the edge computing use case within serverless. The following is a list of self-hosted and open source FaaS offerings:

• Apache OpensWhisk – also powers IBM Cloud
• Kubeless
• Knative – powers Google's Cloud Functions and Cloud Run
• OpenFaaS

All FaaS offerings have common basic features, such as the ability to run functions in response to events or scheduled invocations. But a lot of other features vary between platforms. In the next section, we will look at a very common serverless pattern that makes use of FaaS.