Making Sense of Serverless Computing

In 2016 we’re witnessing the serverless paradigm going mainstream. While the name itself is a misnomer — multiple attempts to rename it to something more sensible are known and failed — the basic idea behind it seems to be convincing: make the unit of compute a single function, effectively providing a lightweight and dynamically scalable compute environment.

The argument is put forward that true serverless compute only makes sense in a public cloud offering; the jury is still out on this one.

With the advent of containers, we already saw the first shift: from managing entire (virtual) machines to application-level dependency management. However, even with containers one still has to deal with a different level of abstraction; while, for example, a Docker image nicely packages a web server like NGINX one still has to determine what goes in there and have a CI/CD pipeline in place to produce said images.

Serverless in this sense is much more akin to PaaS: don’t worry about the underlying components, just provide the code. Other, often mentioned advantages include elasticity and costs. Most, if not all, serverless compute offerings use containers under the hood but now the related challenges such as container orchestration are somebody’s else’s problem — you get to benefit from the isolation guarantees and instant execution of (arbitrary) code.

The capability to execute a function in a scalable manner in isolation is, however, not enough: one needs to be able to trigger the function execution. In a nutshell, this means that the better the integration with other services such as gateways and domain-specific offerings such as IoT, the more valuable and useful is the serverless platform. AWS Lambda, the incumbent in the serverless space, is a great example providing wide and deep integration with its other services such as S3, SNS or CloudWatch.

There are a number of well-known cases where serverless is a great fit: mainly centered around rather short-running, stateless jobs in event-driven architectures, usually found in mobile apps (think: Pokemon Go) or IoT applications, such as a sensor array updating its value once per day. The reason why serverless works in this context so great is that you have to deal with a large number of relatively simple operations executing for a short amount of time but in contrast to a PaaS your unit of scale is a single function. Often, in this context of autoscaling, the argument is put forward that true serverless compute only makes sense in a public cloud offering; the jury is still out on this one.

Let’s now turn our attention to the challenges of serverless compute which fall into roughly one of two categories: use case impedance mismatch and DevOps-related topics:

• Stateful services are best done out of serverless functions (integration with other platform services such as databases or storage extremely important for this to happen)
• Long running jobs (high minutes to hours) are not a good fit, typical expectations are in the second’s range.
• Logging and monitoring are a big challenge: On the one hand, the current offerings provide little support for these operational necessities and on top of that the expectations are quite different to traditional environments due the short lifecycles.
• Local development can be challenging: Usually, developers need to develop and test with the online environment.
• Language support: Most serverless offerings limit the support to a handful of programming languages.

To emphasize one point: the serverless paradigm enforces DevOps culture with short feedback loops and operational aspects—while currently not fully addressed — certainly, play an important role.

Serverless compute is here to stay, however, rather than viewing it as a silver bullet, applicable to all sorts of use cases and workloads one is probably better off understanding it as yet another tool in the cloud-native toolbox.

Mesosphere is a sponsor of InApps Technology.