CLOSE

Hybrid & multi-cloud infrastructure

Function as a Service (FaaS)

Definition of Function as a Service (FaaS)

Function as a Service (FaaS) is a deployment model where a developers create functions (most major programming languages are supported) and then upload them to a FaaS engine, together with the configuration of trigger events and (mostly) function output destinations.

When the function is invoked, the FaaS engine takes care of proper execution and covers operational issues like scaling, operation system updates, server failures, etc..

FaaS is an implementation of the Serverless architecture, and its functionals are typically stateless.

Major cloud service offerings are available for FaaS. The price model includes a fee for function invocation plus onebased on execution duration and memory allocation. There is no cost if no invocation takes place. This is a major differentiator to coarser-grained offerings like Platform as a Service (PaaS) and Container as a Service (CaaS).

Technically, FaaS is typically based on containers that run the functions. From a technical perspective and somewhat simplified, FaaS can thus be perceived as a Cloud service that is running ephemeral containers with automatic management of start/stop and scaling.

Technology Evaluation

Architecture

FaaS is particularly suitable for functions that are event-driven, stateless, asynchronous, easy to parallelize, and carry high elasticity demands. FaaS is a very attractive option for these kind of functions.

Most of these characteristics are architecturally desirable anyways (see also event-driven architecture, EDA). Thus, using FaaS also fosters well-architected solutions.

This does not negate the fact that some functions are much less or not at all suitable for FaaS, and many existing architectures are de facto different.

Development

FaaS shines in development environments that require a high level of agility, where it can contribute to high developer productivity.

Some solutions allow to leverage functions that are offered by third parties (BaaS), improving efficiency and time-to-market further.

On the downside,

  • monitoring and troubleshooting capabilities are limited
  • the programming languages available are limited
  • some FaaS Service offerings make it difficult to switch FaaS providers (vendor lock-in). This can e.g. be mitigated by using Open Source FaaS engines on own Kubernetes-as-a-service environments.

Economics of FaaS Services

FaaS Services are often economically attractive with drastically reduced operational costs compared to IaaS, for example. This is in particular true for strongly fluctuating workloads and workloads with a smaller load overall.

However, estimating FaaS cost in advance is hard, let alone computing a FaaS/IaaS cost break-even point. The lack of cost predictability is a major disadvantage of FaaS in itself.

Potential cost traps include:

  • FaaS is priced on memory and function duration (unit: Gigabyte-second), but both dimensions are often rounded up. FaaS is thus less attractive for tasks with many small functions like web page delivery.
  • FaaS typically comes with a high startup latency. This can sometimes be reduced, but at a very significant cost.

Market - current adoption

The market adoption of FaaS Services is significant. According to Research and Markets (somewhat simplified here), the market size of USD BN 7.6 in 2020 is expected to nearly triple by 2025.

FaaS providers are AWS Lambda, Microsoft Azure Functions, Google CloudFunctions, IBM Cloud Functions, and many others. Additionally, open source FaaS engines are available (OpenFaaS, OpenWhisk, Kubeless, Fission, etc.). Companies that need to run and manage Kubernetes workloads anyways may find it financially more attractive to use these, even in cloud deployments.

How to Adopt

FaaS is a good and light-weight option for companies going towards cloud. Adoption is generally recommended. However, prerequisites are established architectural principles, proper governance, and an upfront evaluation of the potential drawbacks listed above.

A sensible adoption to FaaS requires an undogmatic matching of the functional and nonfunctional requirements at hand with the capabilities that FaaS provides. Typically, hybrid application designs will result. If an application calls a third-party image resize function (the ubiquitous FaaS example), the result is already a hybrid application. The recommendation is thus not an unreserved “Do FaaS!", but rather: “Adopt a ‘FaaS first!’ paradigm, and build team skills to identify the sweet spot of FaaS and leverage it!".