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.

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