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
