Beyond Microservices

This presentation shows the properties, advantages and challenges of microservices. It then discusses alternative architectures beyond microservices.

Transcript

1. Beyond Microservices Eberhard Wolff @ewolff http://ewolff.com Fellow
2. http://continuous-delivery-buch.de/ http://continuous-delivery-book.com/
3. http://microservices-buch.de/ http://microservices-book.com/
4. http://microservices-book.com/ primer.html http://microservices-buch.de/ ueberblick.html FREE!!!!
5. http://microservices-praxisbuch.de/ rezepte.html FREE!!!! Print version at innoQ boot!
6. http://microservices-praxisbuch.de/ Soon…
7. What are Microservices?
8. Independent Systems Architecture: ISA Creator: INNOQ | http://isa-principles.org
9. Creator: INNOQ | http://isa-principles.org > Best practices > for microservices > for Self-contained Systems (SCS) http://scs-architecture.org Introduction Why ISA ? ! ! !
10. 1 | Modules Creator: INNOQ | http://isa-principles.org
11. Creator: INNOQ | http://isa-principles.org > Modules: Old idea > Modularization for a system 1 | Modules
12. Creator: INNOQ | http://isa-principles.org > Reuse “Module” ideas: > High cohesion, low coupling, > Separation of concerns, > Single Responsibility … 1 | Modules
13. Creator: INNOQ | http://isa-principles.org > Modules provide interfaces > Access only through interface 1 | Modules
14. Creator: INNOQ | http://isa-principles.org > Information hiding > Microservice must not use other microservices’ internals (e.g. database schemas). 1 | Modules
15. 2 | Container Creator: INNOQ / http://isa-principles.org
16. Creator: INNOQ | http://isa-principles.org > Modules = containers (or VMs, processes …) 2 | Container
17. 3 | Macro / Micro Architecture Creator: INNOQ / http://isa-principles.org
18. Creator: INNOQ | http://isa-principles.org > Decisions for all modules 3 | Macro / Micro Architecture Macro Architecture
19. Creator: INNOQ | http://isa-principles.org > Decisions per module 3 | Macro / Miro Architecture Micro Architecture
20. Creator: INNOQ | http://isa-principles.org > All modules part of one system > Goal: Minimal Macro Architecture > Macro Architecture stable 3 | Macro / Miro Architecture Why Macro Architecture?
21. 4 | Integration Creator: INNOQ | http://isa-principles.org
22. Creator: INNOQ | http://isa-principles.org > Integrate modules to become a system Synchronous, asynchronous, or UI 4 | Integration
23. 5 | Communication Creator: INNOQ | http://isa-principles.org
24. Creator: INNOQ | http://isa-principles.org > Technical implementation > REST, messaging … 5 | Communication
25. 6 | Independent Continuous Delivery Pipeline Creator: INNOQ | http://isa-principles.org
26. Creator: INNOQ | http://isa-principles.org > Microservices can only be deployed independently … > ... if pipelines are independent 6 | Independent Continuous Delivery Pipeline
27. 7 | Standardize Operations Creator: INNOQ | http://isa-principles.org
28. Creator: INNOQ | http://isa-principles.org > Configuration, log analysis, tracing, monitoring, deployment > Reduce effort 7 | Standardize Operations
29. 8 | Standards: Interface only Creator: INNOQ | http://isa-principles.org
30. Creator: INNOQ | http://isa-principles.org > Standardize e.g. configuration … or log interface > Do not standardize the library! 8 | Standards: Interface only
31. 9 | Resilience Creator: INNOQ | http://isa-principles.org
32. Creator: INNOQ | http://isa-principles.org > Module still work … if other modules fail 9 | Resilience
33. Creator: INNOQ | http://isa-principles.org > Module still work … if moved somewhere else 9 | Resilience
34. Creator: INNOQ | http://isa-principles.org Independent System Architecture Container Modules Macro / Micro Architecture Independent Continuous Delivery Pipeline Resilience Integration Communication Standardized Operations Standards: Interface only
35. Why Microservices? !
36. Technological Benefits "
37. Decoupling > Originally: Changing a module does not influence other modules. > i.e. independent development
38. Microservice Decoupling > Independent scaling > Independent technical decisions > Decoupled crashes > Security: firewalls etc
39. Clean Architecture
40. Developer
41. Developer
42. REST REST
43. ECommerce System Order Catalog Billing Search
44. ECommerce System Order Catalog Billing Search
45. ECommerce System Catalog Billing Search
46. ECommerce System Order Catalog Billing Search Replace if messed up.
47. Replaceability > Small components hard to mess up > Each module can be replaced > …small green field project > ...different technology stack possible
48. Continuous Delivery
49. Microservices ECommerce System 3rd party systems Database
50. Microservices 3rd party systems Database Order Catalog Billing Search
51. Pipeline per Microservice
52. Build Pipeline for Microservices > Smaller > Easier to set up > Less features (3rd party systems) > Faster Feedback: Less tests
53. Decoupled Development Decoupled Scalability Decoupled Technical decisions Decoupled Crashes Security Architecture Firewalls Replaceability Continuous Delivery Technological Benefits
54. Organizational Benefits "
55. Deployment Monolith Stories Technical Coordination Coordinating Releases
56. Microservice Stories Technical Coordination Stories Technical Coordination Stories Technical Coordination Order Billing Search Release Release Release
57. Inverse Conway Maneuver > Architecture drives organization > Cross-functional team (database, logic, UI) > Team responsible for Bounded Context(s)
58. Take one huge project and make it several small projects…
59. Self-organization > With so much independence… > ...teams can decide for themselves.
60. Inverse Conway Maneuver Independent Technologies Independent Bounded Contexts Self- organization Organizational Benefits
61. Microservices: Challenges #
62. Consistency Order Invoice Delivery What about order #42? ✅ ✅ ❌
63. Consistency Order Invoice Delivery Order #42 is cancelled! ✅ ✅ ⁉ Goods might be delivered if order arrives after cancellation.
64. This is quite common without microservices.
65. Customer Order Catalog Domino Effect
66. Customer Order Catalog Domino Effect
67. Customer Order Catalog Domino Effect
68. Customer Order Catalog Domino Effect
69. Build resilient microservices!
70. Refactoring > Move code to a new service: Easy > Move code from service to service > Might be a port to a different language > Hard
71. 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?
72. Many New Technologies > Microservices framework > Service discovery > Routing / API Gateway > Continuous Delivery pipeline > Docker > Docker scheduler (Kubernetes) > ....
73. Challenges Consistency Fail safeness Large scale refactoring New Technologies
74. Microservices are an all or nothing approach.
75. Microservices are an all or nothing approach. Too Monolithic!
76. Which benefits are important? Which challenges acceptable?
77. Moving beyond Microservices: Rightsize the Architecture!
78. Alternative Approaches
79. Centralized DB
80. Billing Order Process CRM Order Order Order True Microservices
81. Shared Database Order Schema Billing Order Process CRM
82. Modules -- Container ++ Independent Continuous Delivery Pipeline + Standardized Operations ++ Resilience - ISA Microservices
83. Decoupled Development -- Decoupled Scalability + Decoupled Technical decisions + Decoupled Crashes + Security - Architecture Firewalls - Replaceability -- Continuous Delivery - Technological Benefits
84. Inverse Conway Maneuver - Independent Technologies + Independent Bounded Contexts -- Self-organization - Organizational Benefits
85. Challenges Consistency ++ Fail safeness - Large scale refactoring - New Technologies + -
86. Centralized Database is a bad idea.
87. Consistency requires lots of compromises.
88. Layered
89. Layered iOS Android Web Order Product Delivery Invoice Customer Process Layer
90. Layered: Issues > Changing a business process cause many changes > …in frontends and many backends > Lots of communication between teams and components
91. Modules ++ Container ++ Independent Continuous Delivery Pipeline ++ Standardized Operations ++ Resilience + ISA Microservices
92. Decoupled Development - Decoupled Scalability - Decoupled Technical decisions ++ Decoupled Crashes + Security + Architecture Firewalls + Replaceability + Continuous Delivery - Technological Benefits
93. Inverse Conway Maneuver -- Independent Technologies ++ Independent Bounded Contexts -- Self-organization -- Organizational Benefits
94. Challenges Consistency + Performance -- Fail safeness -- Large scale refactoring -- New Technologies --
95. Layered: More challenges, less benefits, same effort
96. Microservices worsen the problems caused by strong coupling.
97. Bounded Context Microlith SCS
98. Order Shipping address Tracking # Items Item Categories Priority shipping Customs # Account # ... Credit card # Order #
99. My Domain Model is a mess!
100. Bounded Context > Domain model is only valid for one context > There is no universal data model! > See all failed SOA attempts
101. Order Shipping address Tracking # Items Item Categories Priority shipping Customs # Account # ... Credit card # Order # Customs Order Recommen- dations Order Tracking Order Shipping address Tracking # Item Categories Priority shipping Customs # Payment Order Account # Credit card #
102. Self-contained Systems Search Invoice Logistics Checkout Web Web Web Web See http://scs-architecture.org
103. Modules ++ Container ++ Independent Continuous Delivery Pipeline ++ Standardized Operations ++ Resilience + ISA Microservices
104. Decoupled Development ++ Decoupled Scalability ++ Decoupled Technical decisions ++ Decoupled Crashes ++ Security ++ Architecture Firewalls + Replaceability + Continuous Delivery ++ Technological Benefits
105. Inverse Conway Maneuver ++ Independent Technologies ++ Independent Bounded Contexts ++ Self-organization ++ Organizational Benefits
106. Challenges Consistency + Performance ++ Fail safeness ++ Large scale refactoring + New Technologies +
107. Microservices as they should be.
108. You still gain many benefits from Bounded Contexts in a Deployment Monolith.
109. Modules with Maven Architecture Management OSGi WAR
110. Build order / Architecture management Build order / Architecture management
111. Modules + Container -- Independent Continuous Delivery Pipeline - Standardized Operations ++ Resilience - ISA Microservices
112. Decoupled Development + Decoupled Scalability -- Decoupled Technical decisions -- Decoupled Crashes -- Security -- Architecture Firewalls ++ Replaceability + Continuous Delivery + Technological Benefits
113. Inverse Conway Maneuver + Independent Technologies -- Independent Bounded Contexts ++ Self-organization - Organizational Benefits
114. Challenges Consistency - Performance ++ Fail safeness - Large scale refactoring ++ New Technologies ++
115. Clean architecture with a lot less technical challenges!
116. Conclusion
117. Conclusion > Microservices: set of architecture decision > Independent System Architecture > Architecture is about trade-offs > Architecture is different for each project > Go beyond microservices by picking the best decisions! > …and gain most benefits
118. Usually bad tradeoffs > Centralized database > Layered model
119. Usually good tradeoffs > SCS, Bounded Context, Microlith > Bounded Context in a deployment monolith > Strongly separated modules in a deployment monolith
120. EMail wjax2017@ewolff.com to get: Slides + Microservices Primer + Microservices Rezepte + Sample Microservices Book + Sample of Continuous Delivery Book Powered by Amazon Lambda & Microservices