This document discusses stateful microservices in a cloud native world. It begins by explaining that while cloud native applications are usually designed to be stateless, many real-world applications require stateful capabilities. It then explores techniques for building stateful microservices, such as using caches, databases, cookies, and tokens to preserve state. Finally, it discusses how tools like Kubernetes statefulsets, persistent volumes, and MicroProfile Long Running Actions can help enable stateful applications in a cloud native environment.
4. The 12 Factor Application
• VII. Port binding
• Export services via port binding
• VIII. Concurrency
• Scale out via the process model
• IX. Disposability
• Maximize robustness with fast startup
and graceful shutdown
• X. Dev/prod parity
• Keep development, staging, and
production as similar as possible
• XI. Logs
• Treat logs as event streams
• XII. Admin processes
• Run admin/management tasks as one-
off processes
• I. Codebase
• One codebase tracked in revision
control, many deploys
• II. Dependencies
• Explicitly declare and isolate
dependencies
• III. Config
• Store config in the environment
• IV. Backing services
• Treat backing services as attached
resources
• V. Build, release, run
• Strictly separate build and run stages
• VI. Processes
• Execute the app as one or more
stateless processes
9. Stateless Computing
• State of the data does not get
recorded between
transactions
A communication
protocol that does
not retain any
session information
• Scaling the system is easier
• Recoverability from system
failure is easier
Architecture,
design and
implementation is
complex
10. Stateful Computing
• State of the data gets recorded
at every step across all
transactions
A communication
protocol that would
retain all session
information
• Scaling the system is difficult
• Recoverability from system
failure involves a lot of efforts
Architecture,
design and
implementation is
complex
13. Client-Server
Systems
Stateful database
systems on the
server side
Database-styled
transactions
2-Phase Commit
(2PC)
Java
Enterprise Java
Beans – Stateful EJB
(Session vs Entity
Beans)
Servlet –
HTTPSession
Client-side
caching of server
responses
Cookie-based
authentication
Token-based
authentication
(JWT)
14. What do we mean by ‘Transactions’?
A transaction is a group of read and write
operations that only succeeds if all the
operations within it are succesfull.
Transactions can impact a single record or
multiple records.
Holiday
Request
15. ACID Transactions
Atomic
Consistent
Isolated
Durable
A
C
I
D
All changes to the data must be performed or not at all
Data must be in a consistent state before and after the
transaction
No other process can change the data while the
transaction is running
The changes made by a transaction must persist
16. What are ACID Transactions?
• A set of properties of data transactions
• Designed to be used as a set of guiding principles
• Intended to guarantee data validity
• Supports data integrity and security
• Utilises consensus protocol
• E.g. 2 phase commit (2PC)
17. ACID & 2PC Example
2PC
Coordinator
Holiday
Request
Flight booking
microservice
Hotel booking
microservice
Taxi booking
microservice
23. Client-Server
Systems
Stateful database
systems on the
server side
Database-styled
transactions
2-Phase Commit
(2PC)
Java
Enterprise Java
Beans – Stateful EJB
(Session vs Entity
Beans)
Servlet –
HTTPSession
Client-side
caching of server
responses
Cookie-based
authentication
Token-based
authentication
(JWT)
24. Client-Server
Systems
Stateful database
systems on the
server side
Database-styled
transactions
2-Phase Commit
(2PC)
Java
Enterprise Java
Beans – Stateful EJB
(Session vs Entity
Beans)
Servlet –
HTTPSession
Client-side
caching of server
responses
Cookie-based
authentication
Token-based
authentication
(JWT)
27. Cloud Native Computing: An
overarching approach
► “Extension” to Cloud Computing
► Address the ‘true needs’ of enterprise-level distributed
business application systems.
► What are the true needs?
► Highly available
► Scalable
► Performant
28. The 12 Factor Application
• VII. Port binding
• Export services via port binding
• VIII. Concurrency
• Scale out via the process model
• IX. Disposability
• Maximize robustness with fast startup
and graceful shutdown
• X. Dev/prod parity
• Keep development, staging, and
production as similar as possible
• XI. Logs
• Treat logs as event streams
• XII. Admin processes
• Run admin/management tasks as one-
off processes
• I. Codebase
• One codebase tracked in revision
control, many deploys
• II. Dependencies
• Explicitly declare and isolate
dependencies
• III. Config
• Store config in the environment
• IV. Backing services
• Treat backing services as attached
resources
• V. Build, release, run
• Strictly separate build and run stages
• VI. Processes
• Execute the app as one or more
stateless processes
29. HOW to preserve state across
session, transaction, and
network boundaries?
31. Leader Election (etcd) StatefulSets PersistentVolume
Cookie/Session affinity
(sticky session)
Cloud Native Infrastructure:
Containers/Kubernetes
This Photo by Unknown Author is licensed under CC BY This Photo by Unknown Author is licensed under CC BY-SA-NC This Photo by Unknown Author
is licensed under CC BY-SA
This Photo by Unknown Author is licensed under CC BY-SA-NC
34. What is the SAGA Pattern?
• Failure management pattern
• Helps to establish consistency in distributed applications
• Coordinates transactions between multiple
microservices to maintain data consistency
• It is a sequence of local transactions where each
transaction updates data within a single service
35. ACID vs SAGA (BASE)
Atomicity
Consistency
Isolation
Durability
Basically Available
Soft State
Eventual Consistency
A
C
I
D
BA
S
E
39. SAGA Pattern – Approach 1
Microservice 1 Microservice 2 Microservice 3
SAGA SAGA
SAGA
Each microservices that is part of the transaction publishes an event
that is processed by the next microservice
43. 43
What is
MicroProfile?
● Eclipse MicroProfile is an open-source
community specification for Enterprise Java
microservices
● A community of individuals, organizations,
and vendors collaborating within an open
source (Eclipse) project to bring
microservices to the Enterprise Java
community
microprofile.io
50. Single LRA Participant
• @LRA
• A join/create LRA method that handles any required business logic
• @Complete
• Used by complete methods, to be called after the LRA completes successfully and
handles any required business logic
• @Compensate
• Used by compensate methods, to be called if the LRA fails for any reason and
includes any logic that is required to revert any changes that were made by the
join/create method.
https://openliberty.io/blog/2021/01/27/microprofile-long-running-actions-beta.html
57. Open Liberty session persistence
using JCache & Hazelcast
Interactive Lab version: https://openliberty.io/guides/sessions.html
58. Summary:
• Stateful microservices are still needed in this cloud-native world
• Traditional mechanisms aren’t always suitable/best for cloud-native
• Utilising mechanisms and tools designed and built for the cloud as well as
cloud-native infrastructure can enable us to still build effective stateful
cloud-native apps
• OSS tools and technologies are available to try these out
• E.g. MicroProfile LRA, Hazelcast, JCache, etc