“We predict that serverless computing will grow to dominate the future of cloud computing.” —Berkeley CS Department

Serverless has gained popularity, mostly in the adoption of Function as a Service (FaaS). These stateless functions are a good start, but in order to satisfy most application use cases we need to iterate on it—and this next iteration is stateful serverless.

With stateful serverless, the functions and data necessary to make decisions (state) and the decision data (new state) are co-located with the function logic. This means that no longer does a function have to read and write to a database in order to perform its duties in real time. This has a positive, widespread impact on performance, resilience, and responsiveness of the functions, not to mention a streamlined architecture with drastically less real-time reliance on the database. Let’s explore four simple business benefits of such a serverless platform.

1. Less Hardware Spend

One of the fundamental advantages of serverless is to save on hardware and enjoy a pay-as-you-go model. Stateful serverless improves upon this by collapsing your database and middle tier into one, vastly reducing risk and real-time reliance on the database, while increasing capabilities of that middle tier.

This is because stateful serverless functions cache their data as state. They only read from the database upon initial loading of any given domain slice, such as Customer or ShoppingCart. When those domains, running on the middle tier, decide on a state change, they write it back to the database asynchronously. Application state and the ability to make decisions is now completely in-memory and properly located in the all-important middle (or business) tier. Now during real time, normal system behavior, requests come into the middle tier and actions are taken directly from there, without additional hops to the database.

The below figure shows how FaaS must read and write to the database in real time to perform its function:

Next, let’s compare stateful serverless and its simple and predictable real-time behavior:

2. Increased Developer Productivity

Serverless has always provided a productivity boost due to the platform handling ops-related behaviors. A stateful serverless platform takes this to the next level by allowing the modeling of general purpose applications as functions, rather than just small, discrete functions. By applying serverless guarantees on these more coarse functions, not only are developers free of ops worries, but they now also won’t have to think about application characteristics of scalability, availability, resilience, and responsiveness. All of this is now taken care of in the platform. This allows developers to focus on the job at hand—solving business problems—while coding in a language most comfortable for them.

A stateful serverless platform should allow the use of many languages. This best utilizes the skills already existing in an enterprise. By implementing serverless functions with a well-defined interface, using a known standard, any language can be supported. For example, by using gRPC and protobufs, one can define the serverless function interface and it can be implemented in any language that supports protobufs and gRPC. Your development teams may then hone their craft in their chosen language and avoid being a master of none, the full stack fallacy we have seen over and over.

3. Increased Automation

The primary promise of serverless is to remove most if not all of the DevOps burden. If you choose a serverless platform that encapsulates the Reactive behaviors of a system—that being elasticity, resilience, and responsiveness—as well as the database and service locators, DevOps is just a matter of a couple of lines of code to integrate the dev pipeline into the serverless platform.

One very important underpinning of stateful serverless is event sourcing, which is a time series domain model of changes to a domain over time. For example: OrderCreated, OrderShipped, OrderItemAdded. This is a familiar model if you are used to banking statements with deposits and withdrawals over time. At any given time there is a resulting current balance, and for a bank account this would be the current state.

Using event sourcing vastly differs from CRUD (create/read/update/delete), the current state model. With CRUD you only see the application state at a given point in time, with that state potentially changing each time you read. There is no insight as to how things are the way they are. With event sourcing you now have meaningful business data that may be subscribed to increase automation and to tie systems together in a decoupled manner.

For example, an authentication function can authenticate users and issue UserAuthenticated events. A separate machine learning or anomaly detection function may then subscribe to the event and apply logic to guard against too many logins, spoofing, or fraud.

4. Improved Time to Value

With the absence of a bewildering selection of technologies and methodologies, your teams are crisp and can work closely with the functional experts to deliver business value over and over and in a short timeframe. With a decreased architecture burden there is a corresponding decrease in technical debt, the thief of forward momentum. As a result, the partnership with the business is tightened and includes increased collaboration. When development teams are solving business problems rather than architectural patterns, you’ll enjoy less developers per project—and more projects and profit!

Conclusion

As quoted above, the world is going serverless, but that change will come with stateful serverless. With this new architecture at your disposal, you will get your systems into the cloud and enjoy all the cost savings, productivity increases, automation, and business velocity the cloud has to offer while staying ahead of your competitors and disruptors.

Kalix is a Platform as a Service by Lightbend that removes the hurdles of distributed data, distributed systems and all underlying architecture complexity.

Learn more at Kalix.io.