Duplicating data or replicating data in Micro Services

in a Microservices Architecture

Dennis van der SteltSoftware Architect

v a n d e r s t e l t

2Your presenter

Dennis van der Stelt

http://dennis.bloggingabout.net/

Software Architect

Geek

Developer

Architect

Gamer

Enthousiast

Professional Skills

Something about me that you should know

About Dennis

Innovative software architect

Almost 20 years of experience in development ofdistributed systems. Has a continuous drive tolearn and improve knowledge in differentarchitectural styles, including quality in softwaredevelopment. Highly motivated to share hisknowledge via articles, presentations and his blog.

Awards

98%

80%

60%

40%

100%

NServiceBus Champ

Typemock MVP

Certified Trainer


3

AgendaIn a polyglot architectural landscape with a lot of business logic, data and information, how can we build solid loosely coupled systems?

Let’s have a look at the differences between those opposites

Monolithic vs Microservices

Dividing your system’s business logic over logical boundaries

Service Boundaries

Why duplicating data is a bad practice, but replicating data is perfectly fine

Replicating vs Duplicating


Monolithic application

Wikipedia : large, powerful, and intractably indivisible and uniform.

A monolithic application is build and deployed as a single unit.

WordPress is a successful & scalable monolithic application used by millions!

Monolith is therefor not by default a badly designed system

4


5Microservices

a software architectural style for complex applications of small, independent processes.

services are small, highly decoupled and focus on a single task

communicate via language agnostic APIs

boundaries are explicitservices are autonomous

share schema & contract, not classescompatibility is based on policy


Monolithic application 6

single deployment unit


Microservices 7

multiple deployable services


Authentication

8Coupling

OSS

ViewModel

Change

Product

Database

Razor


9

First law

“My First Law of Distributed Object Design: Don't distribute your objects”

Martin Fowler in Patterns of Enterprise Application Architecture


10Monolithic application problems

Problem Analysis

of all monolithic systems are buildwith high time constraints, resultingin big balls of mud in which nodeveloper can find their way.

42%

MaintenanceThe coupling makes it hard to change anything

Documentation

Cost to add new featuresBuilding the 100th feature as fast as the 1st

Project Ownership


Monolithic application 11


12


13

Microservices“don't even consider microservices unless you have a system that's too complex to manage as a monolith”

Martin Fowler

SERVICE BOUNDARIESDividing your system’s business logic over logical boundaries


15Microservices architecture

DeploymentDon’t necessarily need to separately deploy every single service

Services boundariesDefine boundaries around logical business processes

MonitoringDocument message flows and monitor them with great tools

MessagingAsynchronous communication

via messaging & publish/subscribe


Any organization that designs a system will produce a design whose structure is a

copy of the organization's communication structure.“

”Conway’s law – 1968


Service boundaries 17

Ship

pin

gFin

ance

Sale

sM

arketing


Deployment 18

Ship

pin

gFin

ance

Sale

sM

arketing

SQL

SQL

{ }


Architectural style 19

Ship

pin

gFin

ance

Sale

sM

arketing

CQRS

Event SourcingCRUD

there is no

top level

architecture


Coupling aspects 20

SpatialTemporalPlatform


Messaging

21

Ship

pin

gFin

ance

Sale

sM

arketing

SQL


Messaging

22

Ship

pin

gFin

ance

Sale

sM

arketing

SQL


Messaging

23

Ship

pin

gFin

ance

Sale

sM

arketing

SQLPublish / Subscribe


24

Messaging

Handle business events through

Inversion of communication

by supplementing SOA with EDA

“”


25Resume

Service BoundariesTry to see if your organizational communication structure can be the model for your logical service boundaries.

MessagingAvoid RPC style communication between services. Use messaging with an event driven architecture.

DeploymentDon’t necessarily see every microservice as a deployable unit. Do keep an eye out for coupling. Avoid joins in your database between entities.

DUPLICATION vs REPLICATIONWhy you shouldn’t duplicate, but replicate data


27

Do not duplicate

across service boundaries

You can share…

some information

Publish / Subscribe

to notify in advance


28Duplicating data

What event just took placebusiness process related

events that other services require to properly function

and take action on

Status changes Identifiers Date Time Info

Who was the subjectthe triggered event has a

specific subject in our domain

When does the status expirewhen status updates expire or

are no longer relevant at a point in time, we provide

expiration information


Sales

Messaging 29

Taxi

CustomersTaxiRequested

TaxiRequested

RequestTaxi


Sales

Messaging 30

TaxiTaxiRequested

RequestTaxi

FinanceTaxiAssigned

Customers


Sales

Messaging 31

TaxiRequestCancelled

Finance

RequestCancelled

CancelRequest


32Replicating vs Duplicating data

So duplication of data is not good But what about this

replicating data?


33Replicating vs Duplicating data

So duplication of data is not good But what about this

replicating data?

Replicating within a service boundary is okay

for performance or connectivity issues


34Replicating data options

Performance optimization

Suitable for all categories business and personal presentation

In memory cache

Prepare for optimal querying

Prepare data for querying, for example into a specific readmodel / viewmodel

Resolve latency issues

Replicating data across physical machines does not break service boundaries

Resolve network issues

Different sites across the globe, or a moving site without connection,

like a large container ship

Viewmodels

Different machines

Different sites


35Composite UI

SalesLists requests made by

customer

CustomerDisplays customer information such as name and current location

TaxiShows where taxi drivers are and at what time they arrive at your location

FinanceDisplays status of all

financial transactions and outstanding bills

MONITORINGyour services


37Monitoring


38Monitoring


39Monitoring


40Resume; how we build microservices

Define BoundariesDefine boundaries of your services. Your organizationalstructure may help. Do not duplicate data across services.Share status changes, identifiers and date-times.

ImplementImplement your microservices that handle a single task.Use publish/subscribe to notify other services with statuschanges.

Composite UIEverything from data up until the user interface shouldbelong in a service, resulting in a composite ui thatretrieves data based on the mentioned identifiers.

DeployDeploy your microservices, but not necessarily as singleunits. A possibility is a deployment unit per serviceboundary.


41

Microservices can be hard to build, deploy & monitor. Get help from people with experience

Think about temporal coupling between services and how to solve this, possibly with messaging

Do not duplicate data between services, as at some point business logic will follow

Conclusion


42Contact Me

AddressRotterdam, The Netherlands

[email protected]

Twitter@dvdstelt

Websitehttp://dennis.bloggingabout.net

Thank you for your time…

Duplicating data or replicating data in Micro Services

Technology

Transcript of Duplicating data or replicating data in Micro Services