We have been talking about Serverless a lot lately and there are a couple of reasons for that. Serverless computing will provide greater scalability, more flexibility, and quicker time to release at reduced cost and this is the reason everybody is after it. Is serverless architecture enough to drive all this we talked about just now? The answer is no, of course. Also, State management has been absolutely challenging in serverless computing but Cloudstate will make it possible for us, wondering how? Keep reading the article until and you will learn it. The Lightbend’s Cloudstate which was released in August last year(2019) has proved to be a game-changer here as it provides stateful serverless computing, Cloudstate brings powerful new distributed and durable state management primitives based on Akka to the Serverless paradigm. Serving of stateful functions powered by Akka Cluster. That was all for the introduction, let’s talk about Cloudstate in detail below.
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
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 ?
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