how to split your system into microservices
TRANSCRIPT
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 [email protected] to get:Slides+ Microservices Primer+ Sample Microservices Book+ Sample of Continuous Delivery Book
Powered by Amazon Lambda & Microservices