This document discusses stateful microservices in a cloud native world. It begins by covering some key aspects of cloud native applications including the Twelve-Factor App methodology and its emphasis on stateless processes. It then explores the differences between stateless and stateful computing models. While cloud native is often viewed as requiring stateless microservices, the document explains that real-world applications often need stateful capabilities. It discusses some traditional stateful approaches and their limitations in cloud native environments. The document then covers some techniques for building stateful microservices in cloud native environments, including caching, databases, cookies/tokens, and approaches using cloud native infrastructure like Kubernetes. Programming patterns like SAGA and long-running actions are also discussed. Finally
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)
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
47. 47
MicroProfile 5.0
Reactive
Streams
Operators 2.0
Reactive
Messaging
2.0
GraphQL 1.1
Context
Propagation
1.3
Standalone Projects
LRA 1.0
https://developer.ibm.com/components/open-liberty/series/what-is-microprofile/
Jakarta EE
JSON-B 2.0
Jakarta EE
JSON-P 2.0
Jakatra EE
CDI 3.0
Config 3.0
Fault
Tolerance 4.0
JWT
Propagation
2.0
Health
4.0
Metrics 4.0
Open Tracing
3.0
Open API 3.0
Jakatra EE
JAX-RS 3.0
Rest Client
3.0
48. Open Liberty and LRA
Consists of two parts:
1. LRA participants
2. The LRA coordinator
*Beta driver needed https://openliberty.io/blog/2021/01/27/microprofile-long-running-actions-beta.html
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