Creator: INNOQ | http://isa-principles.org
>Modules provide interfaces
>Access only through interface
>Microservice must not use other microservices’
internals (e.g. database schemas).
1 | Modules
Creator: INNOQ | http://isa-principles.org
>Microservices can only be
deployed independently …
>... if pipelines are independent
6 | Independent Continuous Delivery Pipeline
8 | Standards: Interface only
Creator: INNOQ | http://isa-principles.org
Slide 27
Slide 27 text
Creator: INNOQ | http://isa-principles.org
>Standardize e.g. configuration
… or log interface
>Do not standardize the library!
8 | Standards: Interface only
Inverse Conway Maneuver
Architecture drives organization
Cross-functional team (database, logic, UI)
Team responsible for Bounded Context(s)
With so much independence…
...teams can decide for themselves
Self-organization
Slide 36
Slide 36 text
Take one huge project
and make it several
small projects…
Extreme Decoupling
Originally: Changing a module does not influence
other modules.
i.e. independent development
Now: Independent …
– technical decision
– scalability
– deployment
– crashes
– security (e.g. firewall)
Slide 40
Slide 40 text
Clean Architecture
Slide 41
Slide 41 text
Developer
Slide 42
Slide 42 text
Developer
Slide 43
Slide 43 text
REST REST
Architecture Firewalls
Slide 44
Slide 44 text
ECommerce
System
Order
Catalog
Billing
Search
Slide 45
Slide 45 text
ECommerce
System
Order
Catalog
Billing
Search
Slide 46
Slide 46 text
ECommerce
System
Catalog
Billing
Search
Slide 47
Slide 47 text
ECommerce
System
Order
Catalog
Billing
Search
Slide 48
Slide 48 text
Replaceability
Small components hard to mess up
Each module can be replaced
…small green field project
...different technology stack possible
Slide 49
Slide 49 text
Continuous Delivery
Slide 50
Slide 50 text
Microservices
ECommerce
System
3rd party
systems
Database
Slide 51
Slide 51 text
Microservices
3rd party
systems
Database
Order
Catalog
Billing
Search
Slide 52
Slide 52 text
Pipeline per Microservice
Slide 53
Slide 53 text
Build Pipeline for
Microservices
Smaller
Easier to set up
Less features (3rd party systems)
Faster Feedback: Less tests
Consistency
Order
Invoice
Delivery
What about
order #42?
Slide 57
Slide 57 text
Consistency
Order
Invoice
Delivery
Order #42
is cancelled!
Slide 58
Slide 58 text
Inconsistencies are
quite common also
without microservices.
Slide 59
Slide 59 text
Customer Order Catalog
Domino Effect
Slide 60
Slide 60 text
Customer Order Catalog
Domino Effect
Slide 61
Slide 61 text
Customer Order Catalog
Domino Effect
Slide 62
Slide 62 text
Customer Order Catalog
Domino Effect
Slide 63
Slide 63 text
Build resilient
microservices!
Slide 64
Slide 64 text
Refactoring
Move code to a new service: Easy
Move code from service to service
Might be a port to a different language
Hard
Slide 65
Slide 65 text
Global Refactoring
Really hard: Global restructuring
i.e. moving everything to a different place.
…but that is always hard…
...and the result of a major screw-up.
Do you want to optimize for this?
Bounded Context are quite stable
– probably no need for large refactoring.
Slide 66
Slide 66 text
Many New Technologies
Microservices framework
Service discovery
Routing / API Gateway
Continuous Delivery pipeline
Docker
Kubernetes
....
Slide 67
Slide 67 text
Challenges
Consistency Fail safeness
New
Technologies
Slide 68
Slide 68 text
Microservices are an
all or nothing
approach.
Slide 69
Slide 69 text
Microservices are an
all or nothing
approach.
Too Monolithic!
Slide 70
Slide 70 text
Which benefits are
important?
Which challenges
acceptable?
Slide 71
Slide 71 text
Moving beyond
Microservices:
Rightsize the
Architecture!
Slide 72
Slide 72 text
Layered
Slide 73
Slide 73 text
Layered
iOS Android Web
Order Product Delivery
Invoice
Customer
Process Layer
Slide 74
Slide 74 text
Layered: Issues
Changing a business process cause many changes
…in frontends and many backends
Lots of communication between teams and
components
Challenges
Consistency
+
Fail safeness
-
New
Technologies
-
Slide 78
Slide 78 text
Layered
More challenges, less benefits, same effort
Microservices worsen problems caused by strong
coupling.
Microservices are just modules implemented
differently.
It the domain architecture, stupid!
Slide 79
Slide 79 text
Centralized DB
Slide 80
Slide 80 text
Billing
Order
Process
CRM
Order
Order Order
True Microservices
Slide 81
Slide 81 text
Shared Database
Order Schema
Billing
Order
Process
CRM
Challenges
Consistency
+
Fail safeness
?
New
Technologies
+
Slide 103
Slide 103 text
Structured Monolith
Clean architecture
with a lot less technical challenges.
Limited deployment speed.
Slide 104
Slide 104 text
Conclusion
Slide 105
Slide 105 text
Conclusion
Microservices: set of architecture decision
…a new way for modularization
Independent System Architecture
Architecture is about trade-offs
Architecture is different for each project
Go beyond microservices & pick the best decisions!
Slide 106
Slide 106 text
Usually bad tradeoffs
Centralized database
Layered model
Slide 107
Slide 107 text
Usually good tradeoffs
SCS, Bounded Context, Microlith
Bounded Context in a deployment monolith
Strongly separated modules in a deployment
monolith
…structured monolith
Slide 108
Slide 108 text
EMail jax2018@ewolff.com to get:
Slides
+ Microservices Primer DE / EN
+ Microservices Recipes DE / EN
+ Sample Microservices Book DE / EN
+ Sample Practical Microservices DE/EN
+ Sample of Continuous Delivery Book DE
Powered by Amazon Lambda & Microservices