In our previous blog posts, we came to know about, What is Cloudstate? Why we need it? and Why we need to give a second thought to the way CRUD operations are done in Serverless Computing? In this blog post, we will have a look at bird’s eye view of Cloudstate‘s design.
Let’s take a look at its design.
Bird’s Eye View of Design
Cloudstate is built on top of K8, Knative, Graal VM, gRPC, and Akka. A gRPC channel is used for both – Inbound & Outbound communication which goes through sidecars. Also, a single gRPC channel is used per service/entity which allows the infrastructure to safely cache the entity state in memory.
However, the reason to use gRPC was to allow a developer to use his/her preferable choice of programming language. Since gRPC supports different languages, like Dart, Go, Java, JavaScript, Kotlin, Python, Spring Boot, .Net, etc.
The Knative Stateful Serving is an Akka Cluster under the hood. It provides durable Akka Actors which in turn supports several data models, storage techniques, and DBs. This shields the User from the complexities of the Akka Cluster via a set of sidecars which bridges the user code to the backend state & cluster management.
New Domains for Serverless
The Cloudstate‘s design opens up a lot of domains for Serverless Computing. Like:
- Training and Serving of Machine Learning Models
- Low-latency Real-time Prediction/Recommendation Serving/Fraud Detection/Anomaly Detection.
- User Session/Shopping Cart
- Transaction and Workflow Management like Saga Pattern.
- Distributed counting/voting
In the end, we can say that the primary goal of Cloudstate‘s desgin is to provide a way for implementing stateful services in a scalable & reliable way.
I hope you found this blog useful. For more blogs on Cloudstate, stay tuned 🙂
