Today there is a large push in enterprise architecture towards serverless architecture. In a blog post, Jonas Bonér argues that although he strongly believes in the serverless movement, the programming model should not focus only on stateless functions, as this limits the range of supported use-cases.
Bonér, inventor of Akka and founder of Lightbend, notes that in his experience Function as a Service (FaaS) is often confused with serverless, and points out that serverless is all about the user experience (UX), with FaaS being just the first of many implementations.
With a well-defined input and output, functions can be composed into larger functions, and Bonér this compares to Lego – functions are Lego blocks that can be composed into something larger. But he points out that although functions are great for processing data, they suffer from severe constraints and limitations when used beyond their intended scope.
One limitation is that FaaS functions are ephemeral, stateless, and short-lived. From a performance and latency perspective, it’s too costly to lose the computational context and having to load and store the state from backend storage all the time. Another limitation for Bonér is that they lack direct addressability, all communication must therefore use publish-subscribe which means all data have to be passed through some slow and expensive storage mechanism. This may work for event-driven use-cases, but has too high latency for general-purpose distributed computing problems.
Although functions are a great tool, Bonér points out that if serverless is to meet the expectations and vision of an ops-less world while still allowing us to build data-centric real-time applications, it must deal with the hardest problem in distributed systems — managing state. This is also something he believes is the most interesting opportunity for serverless. For him the serverless movement is too focused on automation of the infrastructure, thus ignoring dealing with state. State is moved out of the application layer, but with applications becoming increasingly data-centric and data-driven, this is not a viable solution. For many applications it’s too expensive to make a roundtrip to get data storage for every request; they need to continuously process data in near real-time, extracting knowledge from streams of data. This is a shift from "data at rest" to "data in motion" which has led many companies towards architectures based on distributed stream processing and event-driven microservices.
For Bonér, serverless version 1.0 was all about stateless functions; 2.0 must have a focus on state, allowing us to benefit from the advantages of serverless while building distributed general-purpose applications. End-to-end correctness, consistency and safety mean different things for different services and depend on the use case. A stable system is therefore the responsibility of the application, and the next generation of serverless implementations must provide support for the most important problem – how to reliably and at scale manage data in the cloud.
In a presentation at Serverless NYC 2018, Gwen Shapira, working for Confluent, discussed the challenges when building a data processing architecture on a stateless infrastructure. She notes that a lot of what we want to do requires state; managing state is therefore important also in a serverless world. Since functions scale very well, we need the database to be very fast, scale as well as the functions using the storage, and also have the same pay-for-use model. But looking into the alternatives she doesn’t find any database that has the automatic scaling she expects and none using a pay-for-use model. She also notes that the FaaS model is similar both to the stream processing model and to event driven design, which means we can use patterns from one model in another one, and that a lot of our experiences are still relevant. Instead of having a focus just on functions, which are actions we take, she recommends that we consider the real needs of our applications and use events which she believes more accurately reflect the real world.
Mike Roberts, from Symphonia, notes in an earlier blog post when discussing serverless architectures that FaaS functions are restricted regarding local state. There is state but no guarantees that it’s persisted across multiple invocations, or between different invocations of the same function. Due to this, they often are described as stateless, but for him it’s more accurate to say that any state that must be persistent must be external to the function. A fast NoSQL database or an object or file store of some kind are some options, but he points out that these are a lot slower than persistence locally, in memory or on server. He also notes that this can have a large impact on application architecture.
