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

Points for discussion

  • How long do your tests take?
  • Can you describe your components?
  • Can you test your components independently?
  • Can you deploy components independently?

results matching ""

    No results matching ""