Common architecture of a serverless FaaS

Before getting into other technical chapters, the common architecture of at least six serverless FaaS platforms surveyed and studied during the writing of this book is presented in the following diagram. It is a distilled overview of the existing FaaS platforms and a recommended architecture, if you want to create a new one:

Figure 1.3: A block diagram describing the common architecture for FaaS platforms

System layers

A description of the architecture from bottom to top is as follows:

• We have some physical or virtual machines. These machines could be on a public or private cloud. Some of them may be a physical box running inside a firewall or an organization. They may be mixed together as a hybrid infrastructure.
• The next layer is the Operating System and, of course, the kernels. We need an OS with a modern kernel that supports container isolation, such as Linux, or that is at least compatible with runC. Windows or Windows Server 2016 has its own Hyper-V based isolation that is compatible with Docker.
• The next layer in the architecture is the Container Runtime (System-Level). We emphasize that it is the system-level container runtime as it is not for running FaaS functions directly. This layer is responsible for provisioning the cluster.
• Next is the optional container orchestration engine, or Container Orchestrator, layer. This layer is Docker Swarm or Kubernetes. We use Docker Swarm in this book, but you may find that some FaaS platforms presented in this book do not use any kind of orchestration. Basically, just Docker alone with container networking is enough for a FaaS platform to get up and running effectively.

FaaS layers

Now, we will discuss the actual FaaS layers. We will go from left to right:

• The frontier component of the whole architecture is the FaaS Gateway. The gateway in some implementations is optional, but in many implementations, this component helps serve HTTPS and cache some static content, such as UI parts, of the platform. Gateway instances help for making better throughput. It is usually a stateless HTTP-based reverse proxy. So this component is easy to scale-out.
• The Initiator is one of the most important components of FaaS. An initiator is responsible for imitating the real invocation request to the rest of the platform. In OpenWhisk, this component is called the controller, for example. In Fn, the part inside its Fn server acts as the Initiator.
• The Message Bus is the message backbone of a FaaS platform. Some architectures that do not have this component will have a difficulty to properly implement asynchronous calls, or the retry pattern to make the platform robust. The message bus decouples initiators out of executors.
• The Executor is the component that does the real function invocation. It connects to its own container runtime (application-level) to start the real sequence of function execution. All results and logging will be written to the central log storage.
• Log Storage is the platform's single source of truth. It should be designed to store almost everything, ranging from the function activities to the error logs of each invocation.
• Container Runtime (application level) is a component responsible for starting the function container. We simply use Docker and its underlying engine as the runtime component in this book.