Duplicating data or replicating data in Micro Services

transcript

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

Developer

Architect

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

NServiceBus Champ

Typemock MVP

Certified Trainer

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

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

ViewModel

Change

Product

Database

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.

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

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

arketing

Deployment 18

arketing

Architectural style 19

arketing

Event SourcingCRUD

there is no

top level

architecture

Coupling aspects 20

SpatialTemporalPlatform

Messaging

arketing

Messaging

arketing

Messaging

arketing

SQLPublish / Subscribe

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

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

Messaging 29

CustomersTaxiRequested

TaxiRequested

RequestTaxi

Messaging 30

TaxiTaxiRequested

RequestTaxi

FinanceTaxiAssigned

Customers

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.

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

Emaildennis@bloggingabout.net

Twitter@dvdstelt

Websitehttp://dennis.bloggingabout.net

Thank you for your time…

Duplicating data or replicating data in Micro Services

Technology