Beyond Microservices

Beyond Microservices

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

2350801025b8e8592dbaa8dd98a24cbb?s=128

Eberhard Wolff

April 24, 2018
Tweet

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