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.

08145ecb1ce091d9dd3c328ea2a707fb?s=128

Daniel Terhorst-North

March 06, 2015
Tweet

Transcript

  1. Microservices: software that fits in your head Dan North @tastapod

  2. What is the point of software development?

  3. What is the purpose of software development?

  4. business impact create What is the purpose of software development?

  5. business impact create positive What is the purpose of software

    development?
  6. What is the goal of software development?

  7. What is the goal of software development? to business impact

    minimise lead time
  8. What is the goal of software development? to business impact

    minimise lead time sustainably
  9. The goal is not to produce software!

  10. produce

  11. produce production

  12. produce production productive

  13. ≠ effective productive

  14. Code is not the asset…

  15. Code is not the asset… Code is the cost!

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

    writing code costs

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

    writing code costs
 - waiting for code costs

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

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

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

    writing code costs
 - waiting for code costs
 - changing code costs
 - understanding code costs
  20. understanding code

  21. understanding code code I know

  22. understanding code code I know code everyone knows

  23. understanding code code I know code everyone knows code no-one

    knows!
  24. Code should be stabilised or killed off

  25. Code should be stabilised or killed off fast!

  26. Two complementary patterns

  27. Two complementary patterns Short Software Half-Life

  28. Two complementary patterns Short Software Half-Life Fits In My Head

  29. Short Software Half-Life

  30. Short Software Half-Life Design considerations

  31. Short Software Half-Life - write discrete components
 Design considerations

  32. Short Software Half-Life - write discrete components
 - define component

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

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

    boundary
 - define component purpose
 - define component responsibility Design considerations
  35. Short Software Half-Life Stewardship considerations

  36. Short Software Half-Life - write component tests and docs
 Stewardship

    considerations
  37. Short Software Half-Life - write component tests and docs
 -

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

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

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

  41. Fits In My Head - multiple dimensions

  42. Fits In My Head - multiple dimensions - multiple scales

  43. Fits In My Head - multiple dimensions - multiple scales

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

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

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

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

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

    - “What would James do?” Contextual Consistency - agree guiding principles - agree idioms - difference is data - familiarity ≠ simplicity
  49. Replaceable Component Architecture

  50. Replaceable Component Architecture sustainably…

  51. Replaceable Component Architecture sustainably…

  52. Replaceable Component Architecture sustainably…

  53. Replaceable Component Architecture sustainably…

  54. Replaceable Component Architecture sustainably…

  55. Replaceable Component Architecture sustainably…

  56. Replaceable Component Architecture sustainably… “little computers
 passing messages”

  57. Replaceable Component Architecture sustainably… “little computers
 passing messages” — Alan

    Kay
  58. Replaceable Component Architecture sustainably… “little computers passing messages” — Alan

    Kay
  59. Microservices can be a Replaceable Component Architecture

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

    choose to optimise for replaceability and consistency

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

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

  62. 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
  63. Kill code fearlessly!

  64. Kill code fearlessly! code I know code everyone knows code

    no-one knows!
  65. Kill code fearlessly! code I know code everyone knows

  66. Thank you! Dan North @tastapod http:/ /dannorth.net http:/ /leanpub.com/software-faster