$30 off During Our Annual Pro Sale. View Details »

Avoid Building a Distributed Monolith

Avoid Building a Distributed Monolith

Microservices are the latest and hottest hype. However, the idea of creating small and independent services has been around for some years, under the term SOA - Service Oriented Architectures.

Along the years many SOA implementations have degenerated into what we call a "distributed monolith". A distributed monolith is a system decomposed into several distributed parts. These parts, however, are very tightly coupled.

In a distributed monolith, it is hard to make isolated changes in just one part (or service) without requiring changes to several other parts of the system. Therefore deploys are slow and risky and continuous delivery is impractical. This can have profound business implications.

In this presentation we will explore best practices when building distributed systems and service architectures. The goal is to achieve a service architecture that is loosely coupled and highly cohesive. We will cover three major topics: how to model services, integration techniques and organization structure.

Presented at the 1st Microservices Meetup in Belo Horizonte, Brazil.

Felipe Dornelas

July 28, 2016
Tweet

More Decks by Felipe Dornelas

Other Decks in Technology

Transcript

  1. HOW TO AVOID BUILDING A DISTRIBUTED MONOLITH Felipe Dornelas

  2. As a business, I want to adapt to change fast…

    2
  3. FAST FEEDBACK CYCLE 3 ▫︎Release ▫︎Learn ▫︎Adapt

  4. CONTINUOUS DELIVERY 4 ▫︎Fast and frequent deploys ▫︎Automated tests ▫︎Automated

    infrastructure
  5. THE BIG MONOLITH 5 ▫︎Big codebase ▫︎Tests take a lot

    of time to run ▫︎Hard to deploy isolated changes
  6. THE BIG ORGANIZATION 6 ▫︎Several teams ▫︎Teams might be distributed

    ▫︎Communication overhead
  7. Breaking this app seems to be a good idea, right?

    7
  8. Let’s build a Services Oriented Architecture (SOA)… 8

  9. Behold, the Distributed Monolith™! (it’s a monolith, but distributed) 9

  10. Has anyone here survived a failed SOA implementation? 10

  11. THE DISTRIBUTED MONOLITH 11 ▫︎Changes to one part…

  12. THE DISTRIBUTED MONOLITH 12 ▫︎Break the entire system…

  13. "Making changes in lots of different places is slower, and

    deploying lots of services at once is risky — both of which we want to avoid.” — Sam Newman 13
  14. I heard Microservices are the next big thing now… 14

  15. Microservices = SOA done right (Pssst… don’t tell anyone) 15

  16. The first rule of Microservices is: Do not build Microservices,

    unless… 16
  17. WHEN TO BREAK THE MONOLITH 17 ▫︎Big codebase ▫︎Large team

    ▫︎Tests take a long time to run ▫︎Hard to deploy isolated changes ▫︎Too much overhead
  18. WE ARE GOING TO TALK ABOUT 18 ▫︎How to model

    services ▫︎Integration techniques ▫︎Organizational alignment
  19. HOW TO MODEL SERVICES 19

  20. LOOSE COUPLING 20 ▫︎We want to deploy changes in isolation

  21. HIGH COHESION 21 ▫︎We want to change related behavior in

    one place
  22. BOUNDED CONTEXTS 22 ▫︎We want to find boundaries within our

    problem domain
  23. THE CELL ANALOGY 23 Boundary (Membrane) Hidden Model (Nucleus) Shared

    Model (Nutrients)
  24. It’s all about aligning your services into business capabilities 24

  25. BOUNDED CONTEXTS 25 Warehouse Finance

  26. SHARED MODEL 26

  27. NESTED BOUNDED CONTEXTS 27

  28. NESTED BOUNDED CONTEXTS 28 Order fulfilment Inventory Goods receiving Warehouse

    Domain
  29. SEAMS 29 ▫︎Portion of the code that can be treated

    in isolation ▫︎Should be aligned with business capabilities
  30. SEAMS 30 ▫︎Group code by bounded contexts - com.example.finance -

    com.example.warehouse - com.example.warehouse.order - com.example.warehouse.goods - com.example.warehouse.inventory
  31. PREMATURE DECOMPOSITION 31 ▫︎Do not create services until you understand

    the domain very well
  32. BREAKING THE MONOLITH 32 Seam being extracted into service

  33. COARSE TO GRANULAR 33

  34. NESTED BOUNDED CONTEXTS 34

  35. EXPOSED BOUNDED CONTEXTS 35

  36. AVOID TECHNICAL SEAMS 36 ▫︎Ex: exceptions, services, utils…

  37. AVOID TECHNICAL SEAMS 37 ▫︎Ex: backend, database service ▫︎Layered system

    ▫︎Onion architecture
  38. AVOID ANEMIC SERVICES 38 ▫︎Ex: CRUD-only ▫︎Start with coarse-grained services

    ▫︎Break them down only if necessary
  39. INTEGRATION 39

  40. "Making changes in lots of different places is slower, and

    deploying lots of services at once is risky — both of which we want to avoid.” — Sam Newman 40
  41. 41 AVOID BREAKING CHANGES

  42. 42 HIDE IMPLEMENTATION DETAILS

  43. 43 TECHNOLOGY AGNOSTIC APIS

  44. INTEGRATION TECHNOLOGIES 44 ▫︎RPC ▫︎REST ▫︎Database ▫︎Message Queues

  45. RPC 45 ▫︎Ex: SOAP, Thrift, Protocol Buffers ▫︎Hides the complexity

    of a remote call ▫︎Generates client stubs ▫︎Easy, but…
  46. SOAP PROBLEMS 46 ▫︎Tight coupling ▫︎Changes requires all clients to

    be updated… ▫︎Even for not consumed data
  47. SOAP PROBLEMS 47 ▫︎Network calls are transparent ▫︎But the network

    is not reliable!
  48. TOLERANT READERS 48 ▫︎Ex: if you're consuming an XML file,

    only take the elements you need ▫︎Ignore anything you don’t
  49. “An implementation should be conservative in its sending behavior, and

    liberal in its receiving behavior” — Jon Postel 49
  50. Postel’s Law 50

  51. REST-RPC 51 ▫︎POST /submitOrder ▫︎GET /findOrderById ▫︎GET /findOrderByUser

  52. REST-RPC PROBLEMS 52 ▫︎Think about actions instead of things ▫︎Hard

    to align with bounded contexts ▫︎Not uniform ▫︎OK in some cases…
  53. REST 53 ▫︎GET /orders?user=john_doe ▫︎GET /orders/12345678 ▫︎POST /orders ▫︎PUT /orders/12345678

  54. REST BENEFITS 54 ▫︎Think about resources (things) ▫︎Aligned with bounded

    contexts
  55. REST BENEFITS 55 ▫︎Addressability ▫︎Statelessness ▫︎Connectedness ▫︎Uniform Interface

  56. AVOID SHARED DATABASES 56

  57. SHARED DATABASE PROBLEMS 57 ▫︎Tight coupling ▫︎Exposes implementation details ▫︎Technology

    lock-in
  58. Services should own their data 58

  59. SHARED LIBRARIES 59 ▫︎DRY - Don’t Repeat Yourself ▫︎We want

    to avoid duplicating system behavior and knowledge ▫︎Code reuse FTW, right?
  60. SHARED LIBRARIES 60 ▫︎Potential coupling! ▫︎Updating a library might require

    changes to lots services at once
  61. “The evils of too much coupling between services are far

    worse than the problems caused by code duplication” — Sam Newman 61
  62. SHARED LIBRARIES 62 ▫︎Never share business logic ▫︎Use templates to

    bootstrap your service ▫︎OK to share that logging library… ▫︎Independent versioning
  63. 63 SYNCHRONOUS VS. ASYNCHRONOUS

  64. 64 REQUESTS VS. EVENTS

  65. 65 ORCHESTRATION VS. CHOREOGRAPHY

  66. EXAMPLE BUSINESS PROCESS 66

  67. ORCHESTRATION 67

  68. CHOREOGRAPHY 68

  69. "Systems that tend more toward the choreographed approach are more

    loosely coupled, and are more flexible and amenable to change.” — Sam Newman 69
  70. SERVICES AND THE ORGANIZATION 70

  71. "Organizations which design systems are constrained to produce designs which

    are copies of the communication structures of these organizations” — M. Conway 71
  72. Conway’s Law 72

  73. TECHNOLOGY-ORIENTED TEAMS 73 Front-End Team Back-End Team Database Team

  74. FUNCTIONAL SILOS 74 Back-End Front-End Database

  75. LAYERED DISTRIBUTED SYSTEM 75

  76. “I called this onion architecture, as it had lots of

    layers and made me cry when we had to cut through it.” — Sam Newman 76
  77. FEATURE TEAMS 77

  78. FEATURE TEAMS 78 ▫︎Work across several systems ▫︎Own the application

    lifecycle ▫︎Autonomy to make changes
  79. “If you can’t feed a team with two- pizza, it’s

    too large.” — Jeff Bezos (Amazon) 79
  80. BOUNDED CONTEXTS 80 Order fulfilment Inventory Goods receiving Warehouse Domain

  81. BOUNDED CONTEXTS 81 Order fulfillment Inventory Goods receiving Warehouse Domain

  82. Teams should have complete ownership of the services inside their

    bounded contexts 82
  83. WINDOWS VISTA 83 ▫︎"The Influence of Organizational Structure On Software

    Quality: An Empirical Case Study"
  84. 84 AMAZON

  85. 85 NETFLIX, SPOTIFY…

  86. REALSTATE.COM.AU 86

  87. THE BOOK 87

  88. → felipedornelas.com THANK YOU