Chapter 5. Deployment
This chapter covers
- Understanding the nature of failure in complex systems
- Developing a simple mathematical model of failure
- Using frequent low-cost failure to avoid infrequent high-cost failure
- Using continuous delivery to measure and manage risk
- Understanding the deployment patterns for microservices
The organizational decision to adopt the microservice architecture often represents an acceptance that change is necessary and that current work practices aren’t delivering. This is an opportunity not only to adopt a more capable software architecture but also to introduce a new set of work practices for that architecture.
You can use microservices to adopt a scientific approach to risk management. Microservices make it easier to measure and control risk, because they give you small units of control. The reliability of your production system then becomes quantifiable, allowing you to move beyond ineffective manual sign-offs as the primary risk-reduction strategy. Because traditional processes regard software as a bag of features that are either broken or fixed, and don’t incorporate the concept of failure thresholds and failure rates, they’re much weaker protections against failure.[1]
1To be bluntly cynical, traditional practices are more about territorial defense and blame avoidance than building effective software.