My notes on Devoxx 2016 Belgium - Microservices Evolution: How to break your monolithic database by Edson Yanaga (I attended this conference)

Reduce maintenance window

Achieve zero downtime deployments

“Code is easy, state is hard”

Changes in a database schema from one version to another are called database migrations

Tools: Flyweight Liquibase

Migrations require back and forward compatibility

Baby steps = Smallest Possible Batch Size

Too many rows = Long Locks

Shard your updates (not updating the entire table in one go)

Renaming a column

ALTER TABLE customers RENAME COLUMN wrong TO correct;

becomes:

ALTER TABLE customers ADD COLUMN correct VARCHAR(20);
UPDATE customers SET correct = wrong WHERE id < 100;
UPDATE customers SET correct = wrong WHERE id >= 100 AND id < 200;

{…}

(later)ALTER TABLE customers DELETE COLUMN wrong;

Adding a column

ADD COLUMN, setting NULL/DEFAULT value/computed value

Next release: Use Column

Renaming / Changeing Type / Format of a Column: Next version: ADD COLUMN, Copy data using small shards Next release: Code reads from old column and writes to both Next release: Code reads from new column and writes to both Next release: Code reads and writes from new column Next release: Delete old column

Deleting a column

Next version: Stop using the column but keep updating the column Next version: Delete the column

For migrating from a monolithic application with a monolithic database to many microservices with own database each:

Using Event Sourcing

tool: debezium.io

You tell it which tables you want to monitor, and from then on it monitors them and generates an event for each DDL/DML statement you issue. The event is propagated to as many event consumers as you want. So, microservices can receive these events and update their own databases.

“HTTP and REST are incredibly slow”