In our previous blog post, Cloudstate (Part 1): What is it?, we came to know about the Serverless Computing, it’s advantages, and a brief introduction of Cloudstate.
In this blog post we will deep dive further into Cloudstate by understanding, why we need it? For which we need to know the limitations of the Serverless Computing. Why? Because Cloudstate overcomes them and that’s why it is required. So let’s take a look at the limitations of Serverless Computing.
Why we need Cloudstate?
After looking at the limitations of the Serverless Computing, we can easily figure it out that Cloudstate overcomes them. How? Simple by providing Stateful long-lived virtual addressable components to serverless computing.
But the real question is, using what Cloudstate is able to provide Stateful long-lived virtual addressable components to serverless computing? The answer is:
- A wider range of coordination and communication patterns, apart from event-driven pub-sub over a broker, like point-to-point, broadcast, etc.
- Tools for managing distributed state reliably at scale, with options for consistency ranging from strong to eventual consistency.
- Ways to physically co-locate code and data while remaining logically separate. For example, CRDTs.
- Offering end-to-end correctness and consistency, so that it can be reasoned for streaming pipelines and provide guarantee to work as a whole. For example, backpressure, windowing, etc.
- Having predictable performance, latency, and throughput.
Moreover, Cloudtstate provides rich APIs with easily understandable semantics for working with never-ending streams of data, managing complex distributed data workflows, and managing distributed state in a reliable, resilient, scalable, and performant way.
Because of the above mentioned goodies, Cloudstate is needed for building a Stateful Serverless Application. In upcoming blogs we will explore more about Cloudstate, hence stay tuned 🙂
1 thought on “Cloudstate (Part 2): Why we need it?2 min read”
Comments are closed.