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.

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