The document discusses serverless computing, outlining its benefits and limitations, such as statelessness, latency issues, and addressability challenges. It introduces Cloudstate, a framework designed for managing distributed state in serverless applications, supporting various patterns like event sourcing and CRDTs. The document emphasizes the importance of focusing on business logic while utilizing Cloudstate in a Kubernetes environment.

1. Presented By:
Himanshu Gupta
Anjali Sharma
Knoldus Inc
Cloudstate
Distributed State Management for
Serverless

2. Lack of etiquette and manners is a huge turn off.
KnolX Etiquettes
Punctuality
Respect Knolx session timings,
you are requested not to join
sessions after a 5 minutes
threshold post the session start
time.
Feedback
Make sure to submit a
constructive feedback for all
sessions as it is very helpful for
the presenter.
Silent Mode
Keep your screens on mute
unless you have query.
Avoid Disturbance
Avoid unwanted chit chat during
the session.

3. Agenda
01 What is Serverless Computing
02 Limitations of Serverless Platforms
03 Rethinking CRUD
04 About Cloudstate and its architecture
05 Working with Cloudstate

4. What is Serverless Computing ?

5. ● Serverless computing is a method of
providing backend services on an
as-used basis
● Serverless means that the developers
can do their work without having to
worry about servers at all.
What is Serverless Computing ?

6. Simplified Scalability
Low Latency
Easily Deployable
Cost Effective
No Server
Management Required
Benefits of Serverless Computing

7. Stateless
Latency
No addressability
Limitations of Serverless Platforms

8. Stateless
● Aside from the components that are explicitly designed to be data stores, most
Serverless components are effectively stateless
● Forces to load and store the state from the backend storage over and over again.
● Stateless components must, by definition, interact with other, stateful components
to persist any information beyond their immediate lifespan.
Limitations of Serverless Platforms

9. Latency
● Serverless faces two kinds of latency challenges: cold-starts and high tail latencies
● When the first user request arrives, the serverless platform needs to load the
function.
● Cold-starts are avoided by keeping one copy running, by forecasting when the first
call happens, or by improving the startup time of the code.
Limitations of Serverless Platforms

10. No Addressability
● Quite often, functions simply have no direct addressability
● They can’t communicate directly with each other using point-to-point
communication.
● This forces developers to resort to publish-subscribe, passing all data over some
slow and expensive storage medium.
Limitations of Serverless Platforms

11. ● We need to rethink the use of CRUD in Serverless.
● CRUD, in the general sense, means unconstrained database access, and is too broad
and open-ended to be used effectively in Serverless environments
● You are thereby moving all the operational concerns from the Serverless framework
into the user function
Rethinking CRUD

12. ● Is the operation a read, or
a write?
● Can it be cached?
● Can consistency be
relaxed, or is strong
consistency needed?
● Can operations proceed
during partial failure?
Rethinking CRUD

13. Abstracting over State
● When we try to use the existing
CRUD strategy then maintaining
the state becomes difficult.
● Unconstrained CRUD does not
work in this model since we can’t
pass the entire data set in and
out of the function.
Solution?
Restricted I/O Patterns
Rethinking CRUD

14. Event Sourcing
In Event Sourcing, state in is the event
log while state out is any newly persisted
events as a result of handling a
command.
Restricted I/O Patterns

15. CRDTs
In CRDTs, state in is a stream of deltas
and/or state updates, and state out is a
stream of deltas and/or state updates.
Restricted I/O Patterns

16. Key-Value
This is the least complex and most used
pattern. As in it, the Key is the State Out
and the Value is the State In.
VALUE KEY
Restricted I/O Patterns

17. Cloudstate is a specification, protocol, and reference implementation
for providing distributed state management patterns suitable for
Serverless computing.
– cloudstate.io
About Cloudstate and its Architecture

18. ● In simple terms, Cloudstate is a framework that helps in building Distributed Stateful
Serverless Applications.
● It supports a variety of serverless patterns, like:
○ Event Sourcing
○ Conflict-Free Replicated Data Types (CRDTs)
○ Key-Value storage
○ P2P messaging, and
○ CQRS read side projections
● It is polyglot, which means that services can be written in any language that supports
gRPC, like (Dart, Go, Java, Javascript, Kotlin, Python, Sprint Boot, .Net).
What is Cloudstate?

19. ● 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.
Bird’s Eye View of its Architecture

20. ● 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.
What is present Under the Hood?

21. The first step we need to take is, decide the
programming language of our choice.
Cloudstate have connectors for a wide range
of programming languages. Like:
1. Dart
2. Go
3. Java
4. Kotlin
5. Javascript
Choose Your Language Wisely

22. ● The next step of working with
Cloudstate 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.
Focus on Business Logic

23. ● 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
K8 can be used.
● Akka Sidecar: It is injected by the
Cloudstate operator. All requests go
through it.
● f(x): This represents the function
implemented by the user.
● Distributed DB: This is the place
where state is persisted in form
events.
Cloudstate Service Structure

24. References
01 Lightbend Series from Knoldus Inc.
02 Cloudstate official documentation

25. Thank You !
For further queries reach out to us at:
himanshu@knoldus.com
anjali.sharma@knoldus.com