Beyond Microservices

This presentation defines microservices and shows benefits and challenges. It then discusses alternatives to microservices and why they might make sense.

Transcript

1. Eberhard Wolff Fellow @ewolff http://ewolff.com INNOQ
2. http://continuous-delivery-buch.de/ http://continuous-delivery-book.com/
3. http://microservices-buch.de/ http://microservices-book.com/
4. http://microservices-buch.de/ ueberblick.html http://microservices-book.com/ primer.html FREE!!!!
5. http://microservices-praxisbuch.de http://practical-microservices.com/
6. http://microservices-praxisbuch.de/ rezepte.html http://practical-microservices.com/ recipes.html FREE!!!!
7. What are Microservices?
8. Independent Systems Architecture: ISA Creator: INNOQ | http://isa-principles.org
9. 1 | Modules Creator: INNOQ | http://isa-principles.org
10. Creator: INNOQ | http://isa-principles.org >Reuse “Module” ideas: >High cohesion, low coupling, >Separation of concerns, >Single Responsibility … 1 | Modules
11. 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
12. 2 | Container Creator: INNOQ / http://isa-principles.org
13. Creator: INNOQ | http://isa-principles.org >Modules = containers (or VMs, processes …) 2 | Container
14. 3 | Macro / Micro Architecture Creator: INNOQ / http://isa-principles.org
15. Creator: INNOQ | http://isa-principles.org >Decisions for all modules 3 | Macro / Micro Architecture Macro Architecture
16. Creator: INNOQ | http://isa-principles.org >All modules part of one system 3 | Macro / Miro Architecture Why Macro Architecture?
17. Creator: INNOQ | http://isa-principles.org >Decisions per module 3 | Macro / Miro Architecture Micro Architecture
18. 4 | Integration Creator: INNOQ | http://isa-principles.org
19. Creator: INNOQ | http://isa-principles.org >Integrate modules to become a system Synchronous, asynchronous, or UI 4 | Integration
20. 5 | Communication Creator: INNOQ | http://isa-principles.org
21. Creator: INNOQ | http://isa-principles.org >Technical implementation >REST, messaging … 5 | Communication
22. 6 | Independent Continuous Delivery Pipeline Creator: INNOQ | http://isa-principles.org
23. Creator: INNOQ | http://isa-principles.org >Microservices can only be deployed independently … >... if pipelines are independent 6 | Independent Continuous Delivery Pipeline
24. 7 | Standardize Operations Creator: INNOQ | http://isa-principles.org
25. Creator: INNOQ | http://isa-principles.org >Configuration, log analysis, tracing, monitoring, deployment >Reduce effort 7 | Standardize Operations
26. 8 | Standards: Interface only Creator: INNOQ | http://isa-principles.org
27. Creator: INNOQ | http://isa-principles.org >Standardize e.g. configuration … or log interface >Do not standardize the library! 8 | Standards: Interface only
28. 9 | Resilience Creator: INNOQ | http://isa-principles.org
29. Creator: INNOQ | http://isa-principles.org >Module still work … if other modules fail 9 | Resilience
30. Creator: INNOQ | http://isa-principles.org Independent System Architecture Modules Macro / Micro Architecture Independent Continuous Delivery Pipeline Resilience Integration Communication Standardized Operations Standards: Interface only Container
31. Why Microservices?
32. Organizational Benefits
33. Deployment Monolith Stories Technical Coordination Coordinating Releases
34. Microservice Stories Technical Coordination Stories Technical Coordination Stories Technical Coordination Order Billing Search Release Release Release
35. 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
36. Take one huge project and make it several small projects…
37. Independent Technologies Independent Bounded Contexts Self- organization Organizational Benefits
38. Technological Benefits
39. 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)
40. Clean Architecture
41. Developer
42. Developer
43. REST REST Architecture Firewalls
44. ECommerce System Order Catalog Billing Search
45. ECommerce System Order Catalog Billing Search
46. ECommerce System Catalog Billing Search
47. ECommerce System Order Catalog Billing Search
48. Replaceability Small components hard to mess up Each module can be replaced …small green field project ...different technology stack possible
49. Continuous Delivery
50. Microservices ECommerce System 3rd party systems Database
51. Microservices 3rd party systems Database Order Catalog Billing Search
52. Pipeline per Microservice
53. Build Pipeline for Microservices Smaller Easier to set up Less features (3rd party systems) Faster Feedback: Less tests
54. Decoupled Development Decoupled Scalability Decoupled Crashes Security Architecture Firewalls Replaceability Continuous Delivery Technological Benefits
55. Microservices: Challenges
56. Consistency Order Invoice Delivery What about order #42?
57. Consistency Order Invoice Delivery Order #42 is cancelled!
58. Inconsistencies are quite common also without microservices.
59. Customer Order Catalog Domino Effect
60. Customer Order Catalog Domino Effect
61. Customer Order Catalog Domino Effect
62. Customer Order Catalog Domino Effect
63. Build resilient microservices!
64. Refactoring Move code to a new service: Easy Move code from service to service Might be a port to a different language Hard
65. 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.
66. Many New Technologies Microservices framework Service discovery Routing / API Gateway Continuous Delivery pipeline Docker Kubernetes ....
67. Challenges Consistency Fail safeness New Technologies
68. Microservices are an all or nothing approach.
69. Microservices are an all or nothing approach. Too Monolithic!
70. Which benefits are important? Which challenges acceptable?
71. Moving beyond Microservices: Rightsize the Architecture!
72. Layered
73. Layered iOS Android Web Order Product Delivery Invoice Customer Process Layer
74. Layered: Issues Changing a business process cause many changes …in frontends and many backends Lots of communication between teams and components
75. Independent Technologies + Independent Bounded Contexts - Self-organization - Organizational Benefits
76. Decoupled Development - Decoupled Scalability - Decoupled Crashes + Security + Architecture Firewalls + Replaceability + Continuous Delivery - Technological Benefits
77. Challenges Consistency + Fail safeness - New Technologies -
78. 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!
79. Centralized DB
80. Billing Order Process CRM Order Order Order True Microservices
81. Shared Database Order Schema Billing Order Process CRM
82. Independent Technologies + Independent Bounded Contexts - Self- organization - Organizational Benefits
83. Decoupled Development - Decoupled Scalability + Decoupled Crashes + Security + Architecture Firewalls - Replaceability - Continuous Delivery - Technological Benefits
84. Challenges Consistency + Fail safeness - New Technologies - -
85. Centralized Database Bad idea Consistency can require lots of compromises Why all the effort for microservices if you allow such strong coupling?
86. Microservice+ Bounded Context
87. Order Shipping address Tracking # Items Item Categories Priority shipping Customs # Account # ... Credit card # Order #
88. My Domain Model is a mess!
89. Bounded Context Domain model is only valid for one context There is no universal data model! See all failed SOA attempts
90. 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 #
91. Self-contained Systems Search Invoice Logistics Checkout Web Web Web Web See http://scs-architecture.org
92. Independent Technologies + Independent Bounded Contexts + Self- organization + Organizational Benefits
93. Decoupled Development + Decoupled Scalability + Decoupled Crashes + Security + Architecture Firewalls + Replaceability + Continuous Delivery + Technological Benefits
94. Challenges Consistency ? Fail safeness ? New Technologies -
95. Microservice + Bounded Context Microservices as they should be. …even though Bounded Context is older than microservices
96. Deployment Monolith
97. Deployment Monolith Deploy everything as one module Might be structured …but most often Makes no sense to talk about benefits and challenges
98. Structured Monolith Modules with Maven Architecture Management OSGi WAR Might be Bounded Contexts
99. Build order / Architecture management Build order / Architecture management
100. Independent Technologies - Independent Bounded Contexts + Self- organization - Organizational Benefits
101. Decoupled Development + Decoupled Scalability - Decoupled Crashes - Security - Architecture Firewalls + Replaceability - Continuous Delivery - Technological Benefits
102. Challenges Consistency + Fail safeness ? New Technologies +
103. Structured Monolith Clean architecture with a lot less technical challenges. Limited deployment speed.
104. Conclusion
105. 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!
106. Usually bad tradeoffs Centralized database Layered model
107. Usually good tradeoffs SCS, Bounded Context, Microlith Bounded Context in a deployment monolith Strongly separated modules in a deployment monolith …structured monolith
108. 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