How to Split Your

System into
Microservices
Eberhard Wolff
@ewolff
Fellow
http://continuous-delivery-buch.de/
http://microservices-buch.de/ http://microservices-book.com/
 FREE!!!!
http://microservices-book.com/primer.html
 Microservices:
Definition
> No consistent definition
> Microservices are modules
> Independent deployment units
> E.g. Docker container
> Microservice owned by one team
Microservices: Definition

Micro Micro
Service Service
Server / Server /
Container Container
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?
Scaling Agile Small teams develop and
deploy independently
Handle Legacy efficient Add services – not code
Strong Modularization
Sustainable development
Replaceable Services
Continuous Delivery Small Services

Failure limited to single

Robustness
Microservice
Independent Scaling
Free choice of technology
 Why Microservices?
Scaling Agile Organization

Handle Legacy efficient

Sustainable development Deployment
Units
Continuous Delivery

Robustness
Independent Scaling Technology
Free choice of technology
There are many
reasons for
microservices.
There are many
scenarios for
microservices.
Scenario and reason
influence the split.
Bounded Context
UBIQUITOUS
LANGUAGE

VALUE
OBJECT

ENTITY
 Address

VALUE
or ENTITY
OBJECT
529 pages
529 pages
Part IV
529 pages
Part IV
Chapter 14
A domain model
is only useful
in a BOUNDED CONTEXT.
There is no
universal data model
in a large system.
 Address
for a customer

VALUE
or ENTITY
OBJECT
 Address
for calculating the
drones’ routes
VALUE
or ENTITY
OBJECT
 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
 Creating Microservices
All these services have data about the customer!!
Registration Browsing Checkout
User Registration Search Products
Payment
by Keywords
Update Profile Browse Products Define Shipment
by Category

Preferences Billing address

Basic customer
data Recommendations Payment
information
 Bounded Context
Scaling Agile Organization

Handle Legacy efficient

Sustainable development Deployment
Units
Continuous Delivery

Robustness
Independent Scaling Technology
Free choice of technology
What about other
scenarios??
 Existing Architecture

iOS Android PoS Web

Product Customer Warehouse

Service Service Service

Product Customer Warehouse

 Let’s create some
Bounded Contexts!
 Existing Architecture
Browsing

iOS Android PoS Web

Product Customer Warehouse

Service Service Service

Product Customer Warehouse

 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
Browsing Browsing

iOS Android PoS Web

Product Customer Warehouse

Service Service Service

Product Customer Warehouse

 Introducing
Bounded 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

iOS Android PoS Web

Product Customer Warehouse

Service Service Service

Product Customer Warehouse

 Add services

iOS Android PoS Web Web

News-
letter
Product Customer Warehouse
Service Service Service

Product Customer Warehouse

 Add Service

> Might replace the old system stepwise

> Immediate benefits
> Low risk
> Major reason for microservices
 Cut existing services

iOS Android PoS Web

Product Customer Warehouse

Service Service Service

Product Customer Warehouse

 Existing Architecture
Scaling Agile Organization

Handle Legacy efficient

Sustainable development Deployment
Units
Continuous Delivery

Robustness
Independent Scaling Technology
Free choice of 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
 External Systems

Registration Browsing Checkout

User Registration Search Products
Payment
by Keywords
Update Profile Browse Products Define Shipment
by Category

Payment Logistic
Provider Partner
 External Systems

Registration Browsing Checkout

User Registration Search Products
by Keywords Payment Shipping
Update Profile Browse Products
by Category

Payment Logistic
Provider Partner
 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 Systems
Scaling Agile Organization

Handle Legacy efficient

Sustainable development Deployment
Units
Continuous Delivery

Robustness
Independent Scaling Technology
Free choice of technology
 We expect a
lot more
registrations!
 External Systems

Registration Browsing Checkout

User Registration Search Products
Payment
by Keywords
Update Profile Browse Products Define Shipment
by Category
 External Systems

Registration Browsing Checkout

Search Products
Payment
Regis- Update by Keywords
tration Profile Define Shipment
Browse Products
by Category
 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
 Command

Command

Command
Command
Queue

Command Command Query

Store Handler Handler

Database Read Replica

 Technical Reasons
Scaling Agile Organization

Handle Legacy efficient

Sustainable development Deployment
Units
Continuous Delivery

Robustness
Independent Scaling Technology
Free choice of technology
 Requirements

Marketing Sales Fulfillment Finance

Registration Browsing Checkout
 Requirements

> One microservice should implement one

stream of requirements
> Otherwise: coordinate priorities
> …and therefore less independence
 Requirements

Marketing Sales Finance Fulfillment

Registration Browsing Payment Shipping
 Requirements
Scaling Agile Organization

Handle Legacy efficient

Sustainable development Deployment
Units
Continuous Delivery

Robustness
Independent Scaling Technology
Free choice of technology
Conclusion
 Microservices
= Bounded Context
 Bounded Require-
Context ments

External Technical
Systems Split Reasons

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

Powered by Amazon Lambda & Microservices