25. FaaS

25.1. Context and Problem Statement

To execute a variety of different functions that are based on different messaging patterns we want to use the Function as a Service (FaaS) approach.

25.2. Decision Drivers

  • MUST support Kubernetes
  • MUST support Kafka to trigger events
  • SHOULD be a well known and proven solution
  • SHOULD support the most common programming languages (at least Java, Python, JavaScript)
  • SHOULD support the Serverless framework

25.3. Considered Options

25.4. Decision Outcome

We want to use OpenFaaS.

25.5. Pros and Cons of the Options

25.5.1. OpenFaaS

  • Good, because it supports Kubernetes
  • Good, because it supports the Serverless framework
  • Good, because it is an easy to use Serverless framework
  • Good, because it has a simple architecture and can be well understood
  • Good, because it supports Kafka via the Kafka-connector

25.5.2. OpenWhisk

  • Good, because it supports Kubernetes (installation via Helm)
  • Good, because it supports the Serverless framework
  • Good, because it is a mature Serverless framework supported by the Apache foundation and backed by IBM
  • Bad, because it is more complex than OpenFaaS and it leverages many components (CouchDB, Kafka, Nginx, Redis and Zookeeper)

25.5.3. Kubeless

  • Good, because it integrates natively into Kubernetes as a CRD
  • Good, because it supports the Serverless framework
  • Good, because it doesn’t require extra tooling (kubectl is enough)
  • Good, because it uses Kafka messaging system as event triggers
  • Bad, because it isn’t as mature as OpenFaaS or OpenWhisk, documentation isn’t as good as the others

25.5.4. Knative Serving

  • Good, because it is baked by Google
  • Good, because it supports Kubernetes
  • Good, because Knative Eventing supports Kafka events
  • Bad, because it requires Istio
  • Bad, because it is more complex than e.g. OpenFaaS