Small and Simple

Build systems small and simple

Rationale

Monolithic applications can be successful, but increasingly people are feeling frustrations with them - especially as more applications are being deployed to the cloud. Change cycles are tied together - a change made to a small part of the application, requires the entire monolith to be rebuilt and deployed. Over time it's often hard to keep a good modular structure, making it harder to keep changes that ought to only affect one module within that module. Scaling requires scaling of the entire application rather than parts of it that require greater resource. Small and simple allows us to scale more efficiently.

Building small and simple add also makes systems easier to reason about, things that are easier to reason about with less code tend to generate fewer bugs and complex production issues.

Implications

  • Create a suite of small systems
  • Build systems around business capabilities
  • Services are independently deployable and independently testable
  • Keep them light-weight
  • Reduce burden of more smaller systems with automation
  • Designed for failure
  • Published Interfaces
  • Small applications need to be appropriately coupled

Examples

  • Financial processing processing (COFP) for OCCO is self contained in one service so complex business logic related to that is tightly coupled and separate from other order processing tasks.
  • Wishlist service for jl.com is a separate service.

results matching ""

    No results matching ""