microservices: redundancy=maintainability
TRANSCRIPT
Microservices:Redundancy =
Maintainability!Eberhard Wolff
@ewolffFellowinnoQ
http://continuous-delivery-buch.de/
http://microservices-buch.de/ http://microservices-book.com/
http://microservices-book.com/primer.html
FREE!!!!
Maintainablity
Redundant data
Redudant code
Legacy System
Too many dependencies
Cyclic dependencies(dotted lines)
> COBOL, Assembler
> Not maintainable
> Not replaceable
L
> We will replace it!
> We will make it maintainable!
> It will be beautiful!
We will take good care of the code!
CleanLikeSpring
Clean Architecture
Developer
Developer
Result?
> Legacy System
> Java
> Not maintainable
> Not replaceable
L
> We didn’t try hard enough!
> We will replace it!
> We will make it maintainable!
> It will be beautiful!
LI need a new job.
While there are still developers:
Replace the legacy system.
Repeat
Insanity:Doing the same thingover and over againand expecting different results.
Albert Einstein
We can achievemaintainability withclean architecture +clean code.
We can achievemaintainability withclean architecture +clean code.
Clean approach tried often.
Results?
Lots of Legacy Code
…and secure jobs.
We need a different approach!
Parnas 1972
Modules
ECommerceSystem
Order
Catalog
BillingSearch
Modules by Domain
> Each domain problem solved in one module.
> New features easy to add
Modules
> Programming language feature
> Class, package, library …
> Rather weak modules
Developer
Microservices
> Modules
> Separate deployment units
> Separate VM / process
Server Server
MicroService
MicroService
ECommerceSystem
Order
Catalog
BillingSearch
Module = separatedeployment units!
ECommerceSystem
Order
Catalog
BillingSearch
Module = separatedeployment units!
Communication e.g. REST
REST REST
ECommerceSystem
Order
Catalog
BillingSearch
Dependencies betweensystems cannot sneak in
ECommerceSystem
Order
Catalog
BillingSearch
Dependencies betweensystems cannot sneak in
ECommerceSystem
Order
Catalog
BillingSearch
Dependencies betweensystems cannot sneak in
“Architecture Firewalls”
“Architecture Firewall”like RESTenforce the architecture
ECommerceSystem
Order
Catalog
BillingSearch
Components small
ECommerceSystem
Order
Catalog
BillingSearch
Components small
Hard to mess up
ECommerceSystem
Order
Catalog
BillingSearch
Components small
Hard to mess up
ECommerceSystem
Catalog
BillingSearch
Components small
Hard to mess up
ECommerceSystem
Order
Catalog
BillingSearch
Components small
Hard to mess upReplace if messed up.
Small,independent deployablemodulesare recyclable.
Recycle your software!!
How many peopleare tryingto replace legacy systems?
Replaceabilityis usually no goalfor a software project.
Why??
We can achievemaintainability withclean architecture +clean code
We can achievemaintainability witharchitecture firewalls +recyclable modules
Maintainability�
Redundancy
RedundancyRedundant data
Every information should be stored and updated in one place.
No redundancy forour product data!
ECommerceSystem
Productsdatabase
ECommerceSystem
InvoicingSystem
Productsdatabase
ECommerceSystem
InvoicingSystem
Productsdatabase
Productsdatabase
ECommerceSystem
Productsdatabase
InvoicingSystem
ECommerceSystem
Productsdatabase
InvoicingSystem
PurchaseSystem
ECommerceSystem
Productsdatabase
InvoicingSystem
PurchaseSystem
MarketingSystem
Productsdata model?
No redundancies
High complexity
Hard to change
A central,redundancy-free data modelis the optimum.
A central,redundancy-free data modelis the optimum.
UBIQUITOUSLANGUAGE
VALUEOBJECT
ENTITY
Address
VALUEOBJECT
ENTITYor
529 pagesPart IVChapter 14
A domain modelis only usefulin a Bounded Context.
There is nouniversal data modelin a large system.
Let me repeat:
There is nouniversal data modelin a large system.
Addressfor a customer
VALUEOBJECT
ENTITYor
Addressfor calculating the
drones’ routes
VALUEOBJECT
ENTITYor
ECommerceSystem
Products
InvoicingSystem
PurchaseSystem
MarketingSystem
ECommerceSystem
InvoicingSystem
PurchaseSystem
MarketingSystem
BOUNDED
CONTEXT
BOUNDED
CONTEXT
BOUNDED
CONTEXT
BOUNDED
CONTEXT
Create a modelfor each BOUNDED CONTEXT.
Each BOUNDED CONTEXTcan be a Microservicewith its own database schema
Low complexity
Easy to change
i.e. easy to maintain
Few redundancies
Separate facets
ECommerceSystem
InvoicingSystem
PurchaseSystem
MarketingSystem
Product:Image
Product:Price
Product:Supplier
Product:Brochure
A central,redundancy-free data modelis the optimum.
A central,“redundancy-free”data modelis often hard to maintainand wrong.
RedundancyRedundant data �
RedundancyRedundant code
Redundant code:The ultimate sin> Fix bug in many different place
> Decisions implemented in many places
> ...and hard to change
DRYDon’t
RepeatYourself
DRY Systems?Great!
DRY between systems?DRY is a trade-off
System System System System
common common common common
System System System System
common abstraction
Reuse:The Holy Grailof the nineties
So where are all the reusable internal frameworks?
Premature optimization,that’s like a sneeze.Premature abstractionis like Ebola;it makes my eyes bleed.
Christer Ericson
The entire history ofsoftware engineeringis that of therise in levels of abstraction.
Grady Booch
Using code is hard.
Reusing code is almost impossible.
But we are reusing Open Source all the time!
Create an Open Source project!
Open Source
> Good code quality
> Documentation
> Model to accept contributions
“But high quality Open Source is hard.
We just share code!”
“You only provide high quality as Open Source…
...but for colleagues low quality is OK?”
Let’s assume it’s possible to reuse code.
Reuse is still a tradeoff.
System System System System
common common common common
System System System System
abstraction
System System System System
abstraction
Change!
System System System System
abstractionChange!
System System System System
abstractionChange!
Impact Impact Impact
System System System System
abstractionChange!
Impact Impact Impact
Now we have reuse
…and a dependency.
Dependency not just in software!
System System System System
common abstractionChange!
Impact Impact Impact
Dependency between teams
Coordination
Meetings
Getting no real work done
L
Reuse is a tradeoff:
Reuse vs.Independence
Independence=Easy to change=Maintainability
Independence is importantfor self-organization.
Self-organization =deciding yourself
Not meetings upon meetings
Deciding yourselfis only possible,if teams and modulesare independent.
Redundancies betweensystems must be avoided.
Redundancies betweensystems must be avoided.
Reuse is a tradeoff:
Reuse vs.Independence
Microservices focus
on independence
The MicroservicesManifesto ;-)
MicroservicesManifesto ;-)
We value:Replaceability overmaintainability
MicroservicesManifesto ;-)
We value:BOUNDED CONTEXT overredundancy-free data
MicroservicesManifesto ;-)
We value:Independence over“Don’t Repeat Yourself!”
Replaceability over maintainability
BOUNDED CONTEXT over redundant-free data
Independence over DRY