BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Lightbend Release CloudState, Providing a Spec for Managing "Serverless" State and a RI with Knative

Lightbend Release CloudState, Providing a Spec for Managing "Serverless" State and a RI with Knative

Leia em Português

This item in japanese

Lire ce contenu en français

Lightbend has recently released CloudState, an open source serverless framework designed to implement stateful management on the Knative and Kubernetes stack. Lightbend, the team behind Akka and the Play framework, have stated that CloudState consists of two components: a standardisation effort to define a state management specification, which includes a protocol and a TCK; and a reference implementation, which implements the backend and a set of client API libraries in many languages.

CloudState is designed for event-driven architecture, event sourcing, CQRS, cluster sharding, co-location of data and processing, and CRDTs, alongside other common distributed patterns. Furthermore, CloudState's reference implementation leverages Knative, gRPC, Akka Cluster, and GraalVM running on Kubernetes, which allows applications to not only scale efficiently, but to manage distributed state reliably at scale while maintaining a global or local level of data consistency.

According to Jonas Bonér:

CloudState is an initiative to define what is "Serverless 2.0"- or what's the next generation of serverless is all about- by adding a concept, model, and implementation around managing state. Anyone who has built a cloud application, a distributed system, knows that state is actually the hardest thing to deal with, while serverless up to this point more or less ignores that. So we're trying to add that to the mix with essentially two things. First is a standardization effort defining a specification, a protocol and a TCK for implementing these things. Second is a reference implementation, implementing the spec.

The following diagram shows the underlying architecture of a CloudState implementation:

(Image taken from https://github.com/cloudstateio)

  • Ingress - This component is responsible for getting user traffic into the cluster, and can be Istio, Knative, or a regular ClusterIP service in Kubernetes
  • Akka Sidecar - This is injected by the CloudState operator, and every single request goes through it. The sidecars of a single CloudState service form a cluster, communicating directly with each other using Akka remoting
  • Code - The function implemented by the developer. It can be written in any language that supports gRPC. The Akka sidecars communicate with the user functions using a predefined gRPC protocol
  • Distributed Datastore - Used when a service needs to persist state. It is important to note that the user code does not interact directly with the datastore - it interacts with the Akka sidecars, and the Akka sidecars communicate with the datastore.

CloudState implements its own autoscaler, because initial experiments with the Knative autoscaler highlighted several issues when scaling up an Akka cluster. These included: the cost of starting an Akka cluster is not free, and state has to be rebalanced across nodes, but the Knative autoscaler does not take this into account; the JVM warmup/jitting can take a long time, and the default autoscaler did not take this into account when making scaling decisions; and the Knative proxy, which the Akka sidecar replaces, is "highly coupled to the Knative autoscaler, and the interface between them is not well defined, making reliance on it from the Akka sidecar high risk in terms of future evolution of Knative".

More details on the CloudState can be found at the GitHub repo. There is also a sample application that implements a simple chat, available in Java and JavaScript.

Users who want to contribute can subscribe to the mailing list, join the discussion on Gitter Channel, or can keep in touch through Twitter.

Rate this Article

Adoption
Style

BT