10 Refactoring

 

This chapter covers

  • Determining when to refactor IaC to avoid impacting systems
  • Applying feature flagging to change infrastructure attributes mutably
  • Explaining rolling updates to complete in-place updates

Over time, you might outgrow the patterns and practices you use to collaborate on infrastructure as code. Even change techniques like blue-green deployment cannot solve conflicts in configuration or changes as your team works on some IaC. You must deliver a series of major changes to your IaC and address problems with scaling the practice.

For example, the sundew team for Datacenter for Carnivorous Plants expresses that it can no longer comfortably and confidently roll out new changes to its system. The team puts all infrastructure resources in one repository (as per the singleton pattern) to quickly deliver the system and just kept adding new updates on top of it.

The sundew team outlines a few problems with its system. First, the team finds its updates to infrastructure configuration constantly overlapping. One teammate works on updating servers, only to find another teammate has updated the network and will affect their changes.

Second, it takes more than 30 minutes to run a single change. One change makes hundreds of calls to your infrastructure API to retrieve the state of resources, which slows the feedback cycle.

10.1 Minimizing the refactoring impact

10.1.1 Reduce blast radius with rolling updates

10.1.2 Stage refactoring with feature flags

10.2 Breaking down monoliths

10.2.1 Refactor high-level resources

10.2.2 Refactor resources with dependencies

10.2.3 Repeat refactoring workflow

Summary