[PPT] - Migrating to Microservice Databases: From Relational Monolith to PowerPoint Presentation

SLIDE 1

Migrating to Microservice Databases:

From Relational Monolith to Distributed Data

Edson Yanaga Director of Developer Experience @yanaga

SLIDE 2

Join developers.redhat.com

2

Java Champion Microsoft MVP

SLIDE 3

http://developers.redhat.com/promotions/ migrating-to-microservice-databases

SLIDE 4

“Now, every company is a software company” — Forbes

SLIDE 5

Join developers.redhat.com

5

SLIDE 6

DevOps & Microservices

SLIDE 7

Feedback Loop

SLIDE 8

Batch Size

SLIDE 9

Join developers.redhat.com

9

Maintenance Window

SLIDE 10

Zero Downtime

SLIDE 11

Join developers.redhat.com

11

Blue Green

Deployments

SLIDE 12

Join developers.redhat.com

12

Deployment

SLIDE 13

Join developers.redhat.com

13

Deployment

Proxy

SLIDE 14

Join developers.redhat.com

Zero Downtime Migrations

SLIDE 22

Back and Forward Compatibility

SLIDE 23

Baby Steps = Smallest Possible Batch Size

SLIDE 24

Too many rows = Long Locks

SLIDE 25

Shard your updates

SLIDE 26

Join developers.redhat.com

ALTER TABLE customers RENAME COLUMN wrong TO correct;

26

SLIDE 27

Join developers.redhat.com

ALTER TABLE customers ADD COLUMN correct VARCHAR(20); UPDATE customers SET correct = wrong WHERE id BETWEEN 1 AND 100; UPDATE customers SET correct = wrong WHERE id BETWEEN 101 AND 200; ALTER TABLE customers DELETE COLUMN wrong;

27

SLIDE 28

Join developers.redhat.com

28

Scenarios Add a Column Rename a Column Change Type/Format of a Column Delete a Column

SLIDE 29

Join developers.redhat.com

29

Add a Column 1 ADD COLUMN 2 Code computes the read value and writes to new column 3 Update data using shards 4 Code reads and writes from the new column

SLIDE 30

Join developers.redhat.com

30

Rename a Column 1 ADD COLUMN 2 Code reads from the old column and writes to both 3 Copy data using small shards 4 Code reads from the new column and writes to both 5 Code reads and writes from the new column 6 Delete the old column (later)

SLIDE 31

Join developers.redhat.com

31

Change Type/Format of a Column 1 ADD COLUMN 2 Code reads from the old column and writes to both 3 Copy data using small shards 4 Code reads from the new column and writes to both 5 Code reads and writes from the new column 6 Delete the old column (later)

SLIDE 32

Join developers.redhat.com

32

Delete a Column 1 DON’T 2 Stop using the read value but keep writing to the column 3 Delete the column

SLIDE 33

What about referential integrity constraints?

SLIDE 34

Drop them and recreate when migration is done

SLIDE 35

Microservices Characteristics

https://martinfowler.com/microservices/

SLIDE 36

Componentization via Services
Organized around Business Capabilities
Products not Projects
Smart endpoints and dumb pipes
Decentralized Governance
Decentralized Data Management
Infrastructure Automation
Design for failure
Evolutionary Design

SLIDE 37

Extracting your Microservice database

SLIDE 38

Join developers.redhat.com

38

One database per Microservice

SLIDE 39

Join developers.redhat.com

39

But I have a monolithic database!

SLIDE 40

Join developers.redhat.com

40

SLIDE 41

Splitting is not easy, but how do I integrate later?

SLIDE 42

Consistency Models

SLIDE 43

Strong Consistency Eventual Consistency

SLIDE 44

CRUD & CQRS

SLIDE 45

Join developers.redhat.com

45

CRUD (Create, Read, Update, Delete)

SLIDE 46

Join developers.redhat.com

46

CQRS (Command Query Responsibility Segregation)

SLIDE 47

Join developers.redhat.com

47

CQRS with separate data stores

SLIDE 48

CQRS & Event Sourcing

SLIDE 49

Join developers.redhat.com

49

Scenarios Shared Tables Database View Database Materialized View Mirror Table using Trigger Mirror Table using Transactional Code Mirror Table using ETL Mirror Table using Data Virtualization Event Sourcing Change Data Capture

SLIDE 50

Join developers.redhat.com

50

Shared Tables Fastest Data Integration Strong Consistency Low cohesion and high coupling

SLIDE 51

Join developers.redhat.com

51

Database View Easiest one to implement Largest support from DBMS vendors Possible performance issues Strong Consistency One database must be reachable by the other Updatable depending on DBMS support

SLIDE 52

Join developers.redhat.com

52

Database Materialized View Better performance Strong or Eventual Consistency One database must be reachable by the other Updatable depending on DBMS support

SLIDE 53

Join developers.redhat.com

53

Database Trigger Depends on DBMS Support Strong Consistency One database must be reachable by the other

SLIDE 54

Join developers.redhat.com

54

Transactional Code Any code: usually Stored Procedures or Distributed Transactions Strong Consistency Possible cohesion/coupling issues Possible performance issues Updatable depending on how it is implemented

SLIDE 55

Join developers.redhat.com

55

ETL Tools Lots of available tools Requires external trigger (usually time-based) Can aggregate from multiple datasources Eventual Consistency Read only integration

SLIDE 56

Join developers.redhat.com

56

Data Virtualization Real Time Access Strong Consistency Can aggregate from multiple datasources Updatable depending on Data Virtualization Platform

SLIDE 57

Join developers.redhat.com

57

SLIDE 58

Join developers.redhat.com

58

Event Sourcing State of data is a stream of events Eases auditing Eventual Consistency Usually combined with a Message Bus High scalability

SLIDE 59

Join developers.redhat.com

59

Change Data Capture Read datasource is updated through a stream of events Eventual Consistency Usually combined with a Message Bus High scalability

SLIDE 60

http://debezium.io

SLIDE 61

Join developers.redhat.com Feedback welcome! @yanaga

SLIDE 62 plus.google.com/+RedHat linkedin.com/company/red-hat youtube.com/user/RedHatVideos facebook.com/redhatinc twitter.com/RedHatNews

Thank you!