10.3 Monoliths, microservices and the honest trade

Work through these

• What a monolith actually is, and why most successful systems started as one

  A monolith is one deployable unit containing the whole application, and most successful systems began as one because it is the fastest thing to build and reason about. The word is used as an insult more often than it is used accurately.

• Microservices: independent deployment, independent failure, and the operational tax

  Splitting into independently deployable services buys independent release and independent failure, and charges an operational tax in networking, monitoring and debugging. The tax is paid whether or not the benefits arrive.

• Service boundaries drawn on data ownership rather than on org chart

  The useful place to draw a boundary is around data one service owns, not around a team on an organisation chart. Boundaries drawn the second way tend to need constant renegotiation.

• The distributed monolith — the worst of both, and how you end up there

  Services that must be deployed together, in order, have all the costs of distribution and none of the independence. Recognising this state is the point, because it is arrived at gradually and rarely noticed.

• Serverless as a third point on the same spectrum

  Functions are a third position on the same spectrum, with the smallest unit and the most platform involvement. Seeing all three as one spectrum makes the choice less tribal.