$30 off During Our Annual Pro Sale. View Details »

Microservices: software that fits in your head

Microservices: software that fits in your head

Software gets complicated fast. Most of good architecture and design practise is about trying to slow the rate at which software gets complicated. You can’t stop it, it’s a form of entropy. You can only slow it down and do your level best to stay on top of things.

One way to manage the mess is to maximise the likelihood that everyone knows what’s going on in the codebase. This requires two things: consistency and replaceability. Consistency implies you can make reasonable assumptions about unfamiliar parts of the application. Replaceability means you can kill code easily and replace it with something better.

Dan North argues that code should either be new enough that someone remembers writing it, or well-enough established that everyone knows how it works. It’s code in that awkward middle stage, between brand new and part-of-the-furniture, that gets forgotten about and starts to smell. If code is going to die it should die quickly. If it is going to stick around it should be stable.

In this talk, Dan describes a model for thinking about the age of code and argues for replaceability as a first class concern. He also discovers that if you optimise for both replaceability and consistency you can end up with something that looks a lot like microservices.

Daniel Terhorst-North

March 06, 2015
Tweet

More Decks by Daniel Terhorst-North

Other Decks in Technology

Transcript

  1. Code is not the asset… Code is the cost! -

    writing code costs
 - waiting for code costs

  2. Code is not the asset… Code is the cost! -

    writing code costs
 - waiting for code costs
 - changing code costs

  3. Code is not the asset… Code is the cost! -

    writing code costs
 - waiting for code costs
 - changing code costs
 - understanding code costs
  4. Short Software Half-Life - write discrete components
 - define component

    boundary
 - define component purpose
 Design considerations
  5. Short Software Half-Life - write discrete components
 - define component

    boundary
 - define component purpose
 - define component responsibility Design considerations
  6. Short Software Half-Life - write component tests and docs
 -

    optimise for replaceability
 Stewardship considerations
  7. Short Software Half-Life - write component tests and docs
 -

    optimise for replaceability
 - expect to invest in stabilising
 Stewardship considerations
  8. Short Software Half-Life - write component tests and docs
 -

    optimise for replaceability
 - expect to invest in stabilising
 - build a stable team Stewardship considerations
  9. Fits In My Head - multiple dimensions - multiple scales

    - “What would James do?” Contextual Consistency
  10. Fits In My Head - multiple dimensions - multiple scales

    - “What would James do?” Contextual Consistency - agree guiding principles
  11. Fits In My Head - multiple dimensions - multiple scales

    - “What would James do?” Contextual Consistency - agree guiding principles - agree idioms
  12. Fits In My Head - multiple dimensions - multiple scales

    - “What would James do?” Contextual Consistency - agree guiding principles - agree idioms - difference is data
  13. Fits In My Head - multiple dimensions - multiple scales

    - “What would James do?” Contextual Consistency - agree guiding principles - agree idioms - difference is data - familiarity ≠ simplicity
  14. Microservices can be a Replaceable Component Architecture - if you

    choose to optimise for replaceability and consistency

  15. Microservices can be a Replaceable Component Architecture - if you

    choose to optimise for replaceability and consistency
 - smaller is not necessarily better

  16. Microservices can be a Replaceable Component Architecture - if you

    choose to optimise for replaceability and consistency
 - smaller is not necessarily better
 - more replaceable is better