Evolvability lets infrastructure accommodate scale, growth, and architectural change while minimizing the effort, cost, and risk of failure. It is one of the four IaC principles alongside reproducibility, idempotency, and composability. section 1.3.4 section 1.3
Centralize changing infrastructure metadata
A resource name used across hundreds of tags, names, and dependent resources creates a fragile find-and-replace task. Defining a top-level NAME variable makes one update propagate throughout the configuration, reducing effort and missed fields. section 1.3.4
Prepare for architectural replacement
An application may need to replace Google Cloud Bigtable with Amazon Elastic MapReduce. Using Apache HBase and consuming a database endpoint lets the infrastructure change behind the scenes while the application interface remains stable. Configurations for both offerings can be created, tested, and switched through the output endpoint. section 1.3.4
Apply evolvability through design and organization:
- Choose infrastructure module patterns according to purpose, reuse, update frequency, and composition; factory and prototype patterns commonly support flexible, reusable modules. section 3.6
- Share standardized modules across teams so environments can reuse established configurations while overriding team-specific requirements. section 5.0
- Use multiple repositories when independently managed module life cycles, granular changes, or CI performance outweigh the convenience of a single repository. section 5.1.2 section 5.1.3
- Reduce infrastructure variation so automation encounters configurations that match expectations, making changes more reliable and limiting failure risk. section 1.4.1
Evaluate evolvability together with the other IaC principles. Ask whether a tool can recreate environments, enforce configuration repeatedly, compose configuration fragments, and evolve resources without affecting unrelated systems. A missing principle can hinder updates or increase the blast radius of failure. section 1.3.5
Practice: assess an infrastructure configuration
Choose an infrastructure script or configuration and assess whether it supports reproducibility, idempotency, composability, and evolvability. Record where changes require manual edits, depend on shared resources, or risk affecting unrelated systems. section 1.3.5
Figure 1.10 Rather than finding and replacing all instances of the name, you can set a top-level variable with the name for all resources.
Use the figure to compare repeated name edits with a top-level variable whose value propagates across resources. section 1.3.4
