Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

More Decks by Felipe Dornelas

Other Decks in Technology


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

    of time to run ▫︎Hard to deploy isolated changes
  2. "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
  3. 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
  4. WE ARE GOING TO TALK ABOUT 18 ▫︎How to model

    services ▫︎Integration techniques ▫︎Organizational alignment
  5. SEAMS 29 ▫︎Portion of the code that can be treated

    in isolation ▫︎Should be aligned with business capabilities
  6. 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
  7. "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
  8. RPC 45 ▫︎Ex: SOAP, Thrift, Protocol Buffers ▫︎Hides the complexity

    of a remote call ▫︎Generates client stubs ▫︎Easy, but…
  9. TOLERANT READERS 48 ▫︎Ex: if you're consuming an XML file,

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

    liberal in its receiving behavior” — Jon Postel 49
  11. REST-RPC PROBLEMS 52 ▫︎Think about actions instead of things ▫︎Hard

    to align with bounded contexts ▫︎Not uniform ▫︎OK in some cases…
  12. SHARED LIBRARIES 59 ▫︎DRY - Don’t Repeat Yourself ▫︎We want

    to avoid duplicating system behavior and knowledge ▫︎Code reuse FTW, right?
  13. “The evils of too much coupling between services are far

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

    bootstrap your service ▫︎OK to share that logging library… ▫︎Independent versioning
  15. "Systems that tend more toward the choreographed approach are more

    loosely coupled, and are more flexible and amenable to change.” — Sam Newman 69
  16. "Organizations which design systems are constrained to produce designs which

    are copies of the communication structures of these organizations” — M. Conway 71
  17. “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
  18. “If you can’t feed a team with two- pizza, it’s

    too large.” — Jeff Bezos (Amazon) 79