How to Split Your System into Microservices

How to Split Your System into

MicroservicesEberhard Wolff

@ewolffFellow

http://continuous-delivery-buch.de/

http://microservices-buch.de/ http://microservices-book.com/

http://microservices-book.com/primer.html

FREE!!!!

Microservices: Definition

> No consistent definition

> Microservices are modules

> Independent deployment units

> E.g. Docker container

> Microservice owned by one team

Microservices: Definition

Server /Container

Server / Container

MicroService

MicroService

Microservices aim for decoupling

Why is the Split so Important?

> Microservices implement a part of the logic

> Allow isolated development of features

> …and independent teams

> If split is wrong, you won’t achieve goals.

> …and there is just more complexity.

> But there are even more goals!

Why Microservices?

Strong Modularization

Scaling Agile

Sustainable development Replaceable ServicesContinuous Delivery

Free choice of technology

Handle Legacy efficient

Independent Scaling

Robustness

Small teams develop and deploy independently

Add services – not code

Small Services

Failure limited to single Microservice

Why Microservices?Scaling Agile

Sustainable development

Continuous Delivery

Free choice of technology

Handle Legacy efficient

Independent Scaling

Robustness

Organization

DeploymentUnits

Technology

There are many reasons for

microservices.

There are many scenarios for

microservices.

Scenario and reason influence the split.

Bounded Context

UBIQUITOUSLANGUAGE

VALUEOBJECT

ENTITY

Address

VALUEOBJECT

ENTITYor

529 pages

529 pagesPart IV

529 pagesPart IVChapter 14

A domain modelis only usefulin a BOUNDED CONTEXT.

There is nouniversal data modelin a large system.

Addressfor a customer

VALUEOBJECT

ENTITYor

Addressfor calculating the

drones’ routes

VALUEOBJECT

ENTITYor

Microservice =Bounded Context

Create some Bounded Contexts!

Sir, yes, sir!

Why would you build a universal data model if that is

neither possible nor useful??

Bounded Context: Challenge

> Not a way to design a great architecture

> …but consequence of good domain architecture

> i.e. clearly separated domains will lead to separated BOUNDED CONTEXTS

> …containing logic and data

> How can you find BOUNDED CONTEXTS?

Bounded Context: Challenge

> Coarse-grained

> Ideal: implement a functionality in one unit

> Ideal: Independence

> Might have relationships

> …limiting independence

Divide by Use Cases

> Microservice should implement a use case

> …ideally without calling other microservices

> Divide use cases among microservices

> …then decide about the BOUNDED CONTEXT

BrowsingRegistration

Creating Microservices

User Registration Search Products by Keywords

Browse Products by Category

Checkout

Payment

Define ShipmentUpdate Profile

Basic customerdata

Preferences

Recommendations

Billing address

Paymentinformation

All these services have data about the customer!!

Bounded ContextScaling Agile

Sustainable development

Continuous Delivery

Free choice of technology

Handle Legacy efficient

Independent Scaling

Robustness

Organization

DeploymentUnits

Technology

What about other scenarios??

Existing Architecture

Product Customer Warehouse

ProductService

CustomerService

WarehouseService

iOS Android PoS Web

Let’s create some Bounded Contexts!

Existing Architecture

Product Customer Warehouse

ProductService

CustomerService

WarehouseService

iOS Android PoS Web

Browsing�

� �

�� �

�

���

Bounded Contexts

> Browsing distributed in many artifacts

> Change to Browsing might influence all of them

> …or not

> BOUNDED CONTEXTS would be desirable

Migrate to Bounded Context

Product Customer Warehouse

ProductService

CustomerService

WarehouseService

iOS Android PoS Web

Browsing�

� �

�� �

�

���

Browsing

IntroducingBounded Contexts

> …would change the architecture completely

> …might be very hard

> …and risky

> Is it worth it?

> Is it even doable?

> Might also change the organization

Add services

Product Customer Warehouse

ProductService

CustomerService

WarehouseService

iOS Android PoS Web

Add services

Product Customer Warehouse

ProductService

CustomerService

WarehouseService

iOS Android PoS Web

News-letter

Web

Add Service

> Might replace the old system stepwise

> Immediate benefits

> Low risk

> Major reason for microservices

Cut existing services

Product Customer Warehouse

ProductService

CustomerService

WarehouseService

iOS Android PoS Web

Existing ArchitectureScaling Agile

Sustainable development

Continuous Delivery

Free choice of technology

Handle Legacy efficient

Independent Scaling

Robustness

Organization

DeploymentUnits

Technology

Existing Architecture

> ...has an impact on the target architecture

> What good is an architecture you cannot migrate into?

> Might overrule everything else

> Even BOUNDED CONTEXT

BrowsingRegistration

External Systems

User Registration Search Products by Keywords

Browse Products by Category

Checkout

Payment

Define ShipmentUpdate Profile Browse Products by Category

PaymentProvider

LogisticPartner

BrowsingRegistration

External Systems

User Registration Search Products by Keywords

Browse Products by Category

Checkout

Update Profile Browse Products by Category

PaymentProvider

LogisticPartner

Payment Shipping

External Systems> Limit integration for each external system to

one Microservice

> External system might belong to a domain

> …or BOUNDED CONTEXT

> ...or not

> Simplifies integration

> Easier to achieve robustness

External SystemsScaling Agile

Sustainable development

Continuous Delivery

Free choice of technology

Handle Legacy efficient

Independent Scaling

Robustness

Organization

DeploymentUnits

Technology

We expect a lot more

registrations!

BrowsingRegistration

External Systems

User Registration Search Products by Keywords

Browse Products by Category

Checkout

Payment

Define ShipmentUpdate Profile Browse Products by Category

BrowsingRegistration

External Systems

Search Products by Keywords

Browse Products by Category

Checkout

Payment

Define ShipmentBrowse Products by Category

Regis-tration

UpdateProfile

Technical Reasons

> Independent scalability is just one technical reason

> There are many more

> Might be OK to share database in this scenario

> Might even split read and write

CQRS

> Command – Query Responsibility Segregation

> Commands change data

> Query provide data

> Implement in separate microservices

CommandQueue

Command

Command

Command

CommandHandler

QueryHandler

CommandStore

Database Read Replica

Technical ReasonsScaling Agile

Sustainable development

Continuous Delivery

Free choice of technology

Handle Legacy efficient

Independent Scaling

Robustness

Organization

DeploymentUnits

Technology

Registration

Requirements

Browsing Checkout

Marketing Sales Fulfillment Finance

Requirements

> One microservice should implement one stream of requirements

> Otherwise: coordinate priorities

> …and therefore less independence

Registration

Requirements

Browsing Payment

Marketing Sales FulfillmentFinance

Shipping

RequirementsScaling Agile

Sustainable development

Continuous Delivery

Free choice of technology

Handle Legacy efficient

Independent Scaling

Robustness

Organization

DeploymentUnits

Technology

Conclusion

Microservices= Bounded Context

Split

BoundedContext

Migration

ExternalSystems

TechnicalReasons

Require-ments

EMail slideswjax2016@ewolff.com to get:Slides+ Microservices Primer+ Sample Microservices Book+ Sample of Continuous Delivery Book

Powered by Amazon Lambda & Microservices