Cloudstate (Part 5): How to work with it?

In our previous blog post, Cloudstate (Part 4): A Bird’s Eye view of its Design, we had a look at bird’s eye view of Cloudstate‘s design. To continue the streak, we are going to learn, how to work with Cloudstate in this blog.

Choose Your Language Wisely

To work with Cloudstate the first step we need to take is, decide the programming language of our choice. Cloudstate makes it very easy for us to do that. Because it uses gRPC, which is not tied to any programming language, for communication between services. This allows Cloudstate to have connectors for a wide range of programming languages. Like:

• Dart
• Go
• Java
• Kotlin
• Javascript

Don’t worry, if you don’t see your preferable language in the above list, just let the Cloudstate community know, it may already be in the works!

Focus on Business Logic

The next step of working with Cloudtstate is to focus on the business logic. Yes, you read it correctly. You don’t have to take care of the nitty-gritty details anymore. You just need to provide a Kubernetes environment and run your Cloudstate services on it. However, if you don’t have one, then one can be found here Cloudstate service.

Above is what Cloudstate services looks like. The meaning of components present in it are as follows:

• Ingress: Cloudstate expects traffic to be distributed evenly across its pods. Hence any service approach, like Istio, Knative, or just regular ClusterIP service communication in Kubernetes can be used.
• Akka Sidecar: Akka sidecar is injected by the Cloudstate operator. All requests go through it. The sidecars of a single Cloudstate service form a cluster, communicating directly with each other using Akka remoting. It also takes care of the state management in services.
• f(x): This represents the function implemented by the user. It can be written in any language that supports gRPC. The Akka sidecars communicate with the user functions using a predefined gRPC protocol. This protocol carries both incoming requests and outgoing responses schema, as well as messages conveying the current state of the system.
• Distributed DB: This is the place where state is persisted in form events. It is important to note that, the f(x) (user code) never interacts with the DB directly. All communication has to go via Akka Cluster. This way, all database communication can be directly managed and monitored by the Akka sidecar. Also this allows the sidecars to safely cache, shard, and replicate data across the cluster.

That’s it, in order to work with Cloudstate you need only 2 steps. I know it sounds unrealistic, but that’s true. With Cloudstate, developer experience is going to enhance a lot.

I hope you found this blog helpful. For more blogs on Cloudstate, stay tuned 🙂