Cloudstate Is Lightbend’s Attempt to Define Serverless 2.0
Serverless has its limits; and chief among them is management of state. AWS Lambda is the dominant serverless platform currently and its functions are, by decree, stateless — meaning there can be no record of previous interactions in a Lambda function. But a relatively new open source project is hoping to change all that. Cloudstate, launched last August by cloud native vendor Lightbend, aims to build a foundation for “Serverless 2.0” by adding stateful functions to the mix.
I spoke to James Roper, a Cloud Architect at Lightbend and the technical lead of Cloudstate, about why stateful functions are needed — and why Lightbend has recently jumped on the serverless bandwagon.
At last month’s KubeCon, Roper accompanied Lightbend founder and CTO Jonas Bonér in a session about Cloudstate. In his opening presentation, Bonér said that serverless is more than just Functions as a Service (FaaS) — which, as the name suggests, is a service that allows users to easily execute functions. AWS Lambda is the original FaaS service, but Cloudstate wants to expand serverless well beyond what Lambda does. The goal of Cloudstate, said Bonér, is to enable the development of general-purpose applications — which includes stateful applications like online banking, e-commerce shopping carts, and messaging.
In my conversation a couple of weeks later with Roper, I asked him why a developer would want to build a stateful application using serverless? He replied that serverless is ultimately about reducing friction.
“If we think of Functions as a Service as being the first iteration of how do we remove this friction,” Roper explained, “the next iteration of that […] is to look at state management, and how to remove that friction; so that a developer can not only be productive on day one, but also producing production-ready code that will scale, that will be resilient, that will be elastic, [and] scale up and down according to their needs.”
Roper added that going beyond FaaS means handling the subtleties of state management too.
“When we talk about state we’re not just talking about state that gets persisted, we’re talking about state that gets coordinated — which could include session state.”
How the Cloudstate Approach Differs from FaaS
It should be noted that the FaaS serverless model doesn’t preclude using stateful data — it’s just that you have to do it by connecting to a database or another storage system. An AWS Lambda FAQ puts it this way:
“While AWS Lambda’s programming model is stateless, your code can access stateful data by calling other web services, such as Amazon S3 or Amazon DynamoDB.”
The main problem with this approach is that the application has to talk to the database or storage service, and that needs to be set up and configured by the developer. To borrow Roper’s terminology, this adds “friction” to the process of creating a stateful application. In the Cloudstate model, the application is no longer responsible for going back and forth to the database in order to manage state. That’s now handled by the Cloudstate protocol, which acts as a kind of middleman between the application and the data store. Here’s how the project’s documentation explains it:
“In a traditional n-tier architecture, one tier (an application tier) will invoke another tier (a database tier) to retrieve and manipulate its state. […] Cloudstate inverts this model. The application code does not call out to the state management system, the state management system calls out to the application code.”
To achieve this inversion, Cloudstate uses “state management proxies” and gRPC Remote Procedure Calls to communicate state. In the KubeCon session, Bonér used the following graphic to illustrate:
“The essence of the protocol approach to state management,” Bonér later clarified to me by email, “is that it is abstracting away (hiding and delegating) all the mechanics of managing the state to the backend, and leaves the user function/service to only have to care about the domain data itself — not how it is persisted, replicated, cached, made consistent, etc. Additionally, now since the backend is managing the state on behalf of all functions it can look more broadly, see general usage patterns, and optimize the data management across services (sharding, caching, batching, etc.).”
Lightbend Goes Serverless
Cloudstate was inspired by — and will be used in conjunction with — Knative, an open source serverless framework based on Kubernetes. Cloudstate is also going to be added to Lightbend’s product line, as a managed service. Roper described this strategy as “a bit of a pivot.”
“So historically we’ve had a bunch of open source projects that we’ve then sold a subscription to, that people run themselves,” he said. “Whereas Cloudstate is moving into the managed, hosted, selling a service, side of things.”
The key product for Lightbend currently is Akka, an open source project for building concurrent and distributed applications that runs on the JVM (Java Virtual Machine). Akka was created by Jonas Bonér in 2009 and became one of the founding technologies of Lightbend when the company launched in 2011 (then named Typesafe). Another founding technology of Lightbend was Scala, a popular Java-based programming language.
Cloudstate is the latest extension of the Akka platform. “Cloudstate is an open source project built on Akka that runs in Kubernetes,” explained Roper.
In one sense, Lightbend is jumping on the serverless gravy train here — the market for serverless is projected to grow by 22.7% per year for the next five years according to MarketandMarkets. Before the Cloudstate announcement last August, the word “serverless” wasn’t even mentioned on Lightbend’s homepage. But it’s now listed as one of the company’s core products, under the banner of Akka Serverless (which is the upcoming managed service version of Cloudstate).
But tackling the serverless market also makes sense technically for Lightbend, because one of the strengths of the Akka platform is its ability to manage state in a distributed system — something that, as noted above, is deficient in the FaaS paradigm. However, Akka is not necessarily easy to deploy. So making it a serverless platform will have benefits to Lightbend’s customers too.
As Roper explained it, the inspiration for Cloudstate came from a combination of the deployment challenges for Akka and the missing stateful functions piece in serverless platforms.
“There were a few things coming together,” said Roper. “One is we wanted to solve the problems of deployment of Akka and we saw [an] opportunity for Akka to be a really important piece in cloud technology. And we saw the gap in serverless.”
Will Cloudstate Get Take-up?
Cloudstate is an effort at standardizing stateful functions in serverless, so Lightbend will need to gather community support for it. I asked Roper if all the key players in the cloud native ecosystem are getting behind the Cloudstate project? He replied that they’ve been talking to people from Dapr (an open source event-driven runtime from Microsoft) and the companies behind Knative (including Google, VMware and Red Hat).
It remains to be seen whether momentum builds for the project; and it’s worth noting that there are alternative stateful serverless projects to choose from, such as Azure Durable Functions (based on Dapr) and RIFF. But it seems like Lightbend is committed to the serverless paradigm and has a lot of motivation to make its Serverless 2.0 vision stick — including that it strengthens Lightbend’s own core platform, Akka.
Lightbend, Amazon Web Services, Red Hat and VMware are sponsors of The New Stack.
Feature image via Pixabay.
At this time, The New Stack does not allow comments directly on this website. We invite all readers who wish to discuss a story to visit us on Twitter or Facebook. We also welcome your news tips and feedback via email: feedback@thenewstack.io.