SpringOne Platform 2018 Cloud Native Data Architecture: Break Away From Data Monoliths for Cloud Native Applications Anupama Pradhan, HCSC; Jeff Cherng, Pivotal

1. Cloud Native Data
Architecture
Anupama Pradhan
Sr. Director IT Product - Data
HCSC
Jeff Cherng
Advisory Data Engineer
Pivotal

2. 80+ Years of Success and Tradition
#6on Diversity MBA’s
50 Out Front for Diversity Leadership Best Places
to Work for Women & Diverse Managers
Operating Blue Cross
and Blue Shield plans in
FIVE states: IL, MT,
NM, OK, TX
OUR PURPOSE
To do everything in our power to stand with our
members in sickness and in health®
1936
year founded
+$1billion
in IT spend
Over
21,000
employees
15million
members
2,100
IT employees
208.3million
claims processed
annually
LARGESTcustomer-
owned
health insurer in the U.S. and
4th largest overall
2

3. Traditional
3

4. • Greenfield Projects
• Small Applications
• Simple Dataset (Not Shared)
• Optimized Performance Tuning
• Easy to Maintain
Simple Application
Application
Datastore
4

5. • Legacy & Brownfield Projects
• Tightly Coupled Inter-Team
Data Model Dependencies
• Complex Dataset (Shared)
• Mixed Workload
• Limited Scalability for Database
• Compromised Performance
Tuning
• Hard to Maintain
Complex Applications (Monolith)
RDBMS
Applications
Applications
Applications
Applications
Applications
Applications
Applications
ApplicationsApplications
Schema Schema Schema
5

6. Example of Monolith Approach
PaymentSupply ChainShopping
Shared Dataset
Customer Cart Order Product
Other
Dataset
Customer
Management
Order
Management
Product
Management
Inventory
Management
Shipping
Management
Payment
Management
6

7. Cloud Native
7

8. twelve-factor
○ processes are stateless and share-nothing
○ treat data backing services as attached resources
microservice design patterns
○ single responsibility
○ shared database is anti-pattern
Cloud Native Application
8

9. • Twelve-Factor Applications
• Microservices Patterns
• Easy to Maintain & Scale
• Is it really this simple?
Cloud Native Application
ShippingCustomer Order Product
Datastore Datastore Datastore Datastore
Application UI Supply Chain
9

10. Data boundary is based on the context of the microservice
○ Domain-Driven Design (DDD)
Design datastore based on use cases of the microservice
○ Identify read/write access patterns
○ Access patterns dictate the performance tuning
Persisted data store per microservice
○ Cross domain reference by using keys
○ Apply Command Query Responsibility Segregation (CQRS) if
needed
Cloud Native Data
10

11. Cloud Native Transformation
RDBMS
Applications
Applications
Applications
Schema
Transform
Microservice Microservice
reference by keys
Data Backing
Service
Data Backing
Service
CQRS and/or share
reference keys
11

12. Integrated Solution
Microservice
1
Data Backing
Service
Microservice
2
Data Backing
Service
Microservice
3
Data Backing
Service
Aggregator Proxy
• Performance could be an
issue
• How about data consolidation
12

13. Cache as Data Backing Service
Microservice
1
Cache Backing
Service
Microservice
2
Cache Backing
Service
Microservice
3
Cache Backing
Service
Aggregator Proxy
Datastore
• Simple Dataset
• Highly Scalable
• Optimized Performance Tuning
• Dedicated Caching Backing
Service
• Remove Inter-Team Data Model
Dependencies
• Allows Iterative Improvement
13

14. Cache Backing
Service
14

15. ● In-memory-data grid (IMDG) based on Apache Geode (OSS)
● Scalability, availability, and performance
● Supports many design patterns
○ Side cache
○ Inline cache
○ Http session management
○ Event driven
○ Data aware compute (map reduce)
● Supports data replication between multi data centers
○ Active-active, active-passive, and disaster recovery
● CI/CD friendly
Geode/GemFire/PCC
15

16. • Performance Improvement
• Easy to Implement
• Supported by Spring Data
Gemfire - @Cacheable
Annotation
Caching Pattern - Side Cache
Application
Datastore
Geode
16

17. • Highly Performant
• Read-Through and Write-
Behind Patterns
• Decoupling Between
Applications & Shared
Datastore
Caching Pattern - Inline Cache
Application
Datastore
Geode
17

18. • System of Record
• CQRS Pattern
• Event Driven Microservice
Supported by Spring Cloud
Stream
Not Just Caching
Application
DatastoreGeode
Event Driven Microservice
18

19. Exercise
19

20. Domain Microservices
20
• Cross Domain Reference by Using Keys
Customer
Full
Customer Shipping
Payment
Order
Customer
ID
CRUD

21. Access Patterns
21
Customer Domain
ReadWrite
Customer
Shipping
Payment
Order
• Different Requirements for Read vs Write

22. Simple CQRS
22
• Choice for Database and Schema
Customer ShippingPaymentOrder
Read Only
Customer
Full
Customer
Update
Customer
Read
Customer

23. Store Only What Your Service Needs
23
Customer ShippingPaymentOrder
Customer
Customer
Shipping
Customer
Payment
Customer
Order
Event Store

24. Example of Cloud Native
Transformation
24
Customer ProductPaymentOrder
Geode GeodeGeodeGeode
Event Driven Microservices
Application UI Supply Chain
Shipping
Geode Data Lake
OLAP / BI / Reports

25. • Simple Dataset
• Highly Scalable
• Optimized Performance Tuning
• Dedicated Caching Backing Service
• Remove Inter-Team Data Model Dependencies
• Allows Iterative Improvement
Summary
25

26. https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/microservice-
ddd-cqrs-patterns/apply-simplified-microservice-cqrs-ddd-patterns
https://docs.microsoft.com/en-us/azure/architecture/microservices/microservice-boundaries
https://www.infoq.com/articles/microservices-aggregates-events-cqrs-part-1-richardson
https://microservices.io/patterns/data/database-per-service.html
https://microservices.io/patterns/data/shared-database.html
References
26

27. Stayed Connected
Other Sessions
9/25-2:40 pmBuilding Data Environments for Production Microservices with
Geode
9/26-5:40 pmEvent Driven Architectures with Apache Geode and Spring
Integration
Contact Info
Anupama Pradhan
https://www.linkedin.com/in/anupama-pradhan-24028b3b/
Jeff Cherng
https://www.linkedin.com/in/jeff-cherng-72914632
27