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
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

5. THE BIG MONOLITH
   5
   ▫︎Big codebase
   ▫︎Tests take a lot of time to run
   ▫︎Hard to deploy isolated changes
   

   View Slide

6. THE BIG ORGANIZATION
   6
   ▫︎Several teams
   ▫︎Teams might be distributed
   ▫︎Communication overhead
   

   View Slide

7. Breaking this app seems to be a
   good idea, right?
   7
   

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

14. I heard Microservices are the next
    big thing now…
    14
    

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

18. WE ARE GOING TO TALK ABOUT
    18
    ▫︎How to model services
    ▫︎Integration techniques
    ▫︎Organizational alignment
    

    View Slide

19. HOW TO MODEL
    SERVICES
    19
    

    View Slide

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

    View Slide

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

    View Slide

22. BOUNDED CONTEXTS
    22
    ▫︎We want to find boundaries within
    our problem domain
    

    View Slide

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

    View Slide

24. It’s all about aligning your
    services into business capabilities
    24
    

    View Slide

25. BOUNDED CONTEXTS
    25
    Warehouse Finance
    

    View Slide

26. SHARED MODEL
    26
    

    View Slide

27. NESTED BOUNDED CONTEXTS
    27
    

    View Slide

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

    View Slide

29. SEAMS
    29
    ▫︎Portion of the code that can be
    treated in isolation
    ▫︎Should be aligned with business
    capabilities
    

    View Slide

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
    

    View Slide

31. PREMATURE DECOMPOSITION
    31
    ▫︎Do not create services until you
    understand the domain very well
    

    View Slide

32. BREAKING THE MONOLITH
    32
    Seam being extracted
    into service
    

    View Slide

33. COARSE TO GRANULAR
    33
    

    View Slide

34. NESTED BOUNDED CONTEXTS
    34
    

    View Slide

35. EXPOSED BOUNDED CONTEXTS
    35
    

    View Slide

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

    View Slide

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

    View Slide

38. AVOID ANEMIC SERVICES
    38
    ▫︎Ex: CRUD-only
    ▫︎Start with coarse-grained services
    ▫︎Break them down only if necessary
    

    View Slide

39. INTEGRATION
    39
    

    View Slide

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
    

    View Slide

41. 41
    AVOID BREAKING CHANGES
    

    View Slide

42. 42
    HIDE IMPLEMENTATION
    DETAILS
    

    View Slide

43. 43
    TECHNOLOGY AGNOSTIC APIS
    

    View Slide

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

    View Slide

45. RPC
    45
    ▫︎Ex: SOAP, Thrift, Protocol Buffers
    ▫︎Hides the complexity of a remote call
    ▫︎Generates client stubs
    ▫︎Easy, but…
    

    View Slide

46. SOAP PROBLEMS
    46
    ▫︎Tight coupling
    ▫︎Changes requires all clients to be
    updated…
    ▫︎Even for not consumed data
    

    View Slide

47. SOAP PROBLEMS
    47
    ▫︎Network calls are transparent
    ▫︎But the network is not reliable!
    

    View Slide

48. TOLERANT READERS
    48
    ▫︎Ex: if you're consuming an XML file,
    only take the elements you need
    ▫︎Ignore anything you don’t
    

    View Slide

49. “An implementation should be
    conservative in its sending
    behavior, and liberal in its receiving
    behavior” — Jon Postel
    49
    

    View Slide

50. Postel’s Law
    50
    

    View Slide

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

    View Slide

52. REST-RPC PROBLEMS
    52
    ▫︎Think about actions instead of things
    ▫︎Hard to align with bounded contexts
    ▫︎Not uniform
    ▫︎OK in some cases…
    

    View Slide

53. REST
    53
    ▫︎GET /orders?user=john_doe
    ▫︎GET /orders/12345678
    ▫︎POST /orders
    ▫︎PUT /orders/12345678
    

    View Slide

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

    View Slide

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

    View Slide

56. AVOID SHARED DATABASES
    56
    

    View Slide

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

    View Slide

58. Services should own their data
    58
    

    View Slide

59. SHARED LIBRARIES
    59
    ▫︎DRY - Don’t Repeat Yourself
    ▫︎We want to avoid duplicating system
    behavior and knowledge
    ▫︎Code reuse FTW, right?
    

    View Slide

60. SHARED LIBRARIES
    60
    ▫︎Potential coupling!
    ▫︎Updating a library might require
    changes to lots services at once
    

    View Slide

61. “The evils of too much coupling
    between services are far worse
    than the problems caused by code
    duplication” — Sam Newman
    61
    

    View Slide

62. SHARED LIBRARIES
    62
    ▫︎Never share business logic
    ▫︎Use templates to bootstrap your
    service
    ▫︎OK to share that logging library…
    ▫︎Independent versioning
    

    View Slide

63. 63
    SYNCHRONOUS VS.
    ASYNCHRONOUS
    

    View Slide

64. 64
    REQUESTS VS. EVENTS
    

    View Slide

65. 65
    ORCHESTRATION VS.
    CHOREOGRAPHY
    

    View Slide

66. EXAMPLE BUSINESS PROCESS
    66
    

    View Slide

67. ORCHESTRATION
    67
    

    View Slide

68. CHOREOGRAPHY
    68
    

    View Slide

69. "Systems that tend more toward the
    choreographed approach are more
    loosely coupled, and are more
    flexible and amenable to change.”
    — Sam Newman
    69
    

    View Slide

70. SERVICES AND THE
    ORGANIZATION
    70
    

    View Slide

71. "Organizations which design
    systems are constrained to produce
    designs which are copies of the
    communication structures of these
    organizations”
    — M. Conway
    71
    

    View Slide

72. Conway’s Law
    72
    

    View Slide

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

    View Slide

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

    View Slide

75. LAYERED DISTRIBUTED SYSTEM
    75
    

    View Slide

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
    

    View Slide

77. FEATURE TEAMS
    77
    

    View Slide

78. FEATURE TEAMS
    78
    ▫︎Work across several systems
    ▫︎Own the application lifecycle
    ▫︎Autonomy to make changes
    

    View Slide

79. “If you can’t feed a team with two-
    pizza, it’s too large.”
    — Jeff Bezos (Amazon)
    79
    

    View Slide

80. BOUNDED CONTEXTS
    80
    Order
    fulfilment Inventory
    Goods
    receiving
    Warehouse
    Domain
    

    View Slide

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

    View Slide

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

    View Slide

83. WINDOWS VISTA
    83
    ▫︎"The Influence of Organizational
    Structure On Software Quality: An
    Empirical Case Study"
    

    View Slide

84. 84
    AMAZON
    

    View Slide

85. 85
    NETFLIX, SPOTIFY…
    

    View Slide

86. REALSTATE.COM.AU
    86
    

    View Slide

87. THE BOOK
    87
    

    View Slide

88. → felipedornelas.com
    THANK YOU
    

    View Slide