Chapter 16. Building Stacks from Components
Chapter 15 explained how well-designed components can make an infrastructure system easier and safer to change. This message supports this book’s theme of using speed of change to continuously improve the quality of a system, and using high quality to enable faster change.
This chapter focuses on modularizing infrastructure stacks; that is, breaking stacks into smaller pieces of code. There are several reasons to consider modularizing a stack:
- Reuse
-
Put knowledge of how to implement a particular construct into a component so you can reuse it across different stacks.
- Composition
-
Create the ability to swap different implementations of a concept, so you have flexibility in building your stacks.
- Testability
-
Improve the speed and focus of testing by breaking a stack into pieces that can be tested separately before integrating them. If a component is composable, you can replace them with test doubles (“Using Test Fixtures to Handle Dependencies”) to further improve the isolation and speed of testing.
- Sharing
-
Share composable, reusable, and well-tested components between teams, so people can build better systems more quickly.
As mentioned in “Stack Components Versus Stacks as Components”, breaking a stack into modules and libraries simplifies the code, but it doesn’t make stack instances any smaller or simpler. Stack components have the potential to make things worse by obscuring the number and complexity of infrastructure resources ...
Get Infrastructure as Code, 2nd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.