Monolithic architecture defines all infrastructure resources in one tightly coupled configuration and the same state. As the configuration grows, changes to one resource can create conflicts, slow deployments, and make isolated changes difficult. A single repository is not necessarily monolithic when separate directories contain independent infrastructure configurations. section 10.2
Refactor the monolith incrementally:
- Identify high-level resources with no dependencies, such as project-level IAM roles and service accounts. section 10.2.1
- Copy their configuration into a separate directory or repository, initialize separate state, and import the existing resources. section 10.2.1
- Deploy and inspect the plan to confirm that the live infrastructure remains unchanged before removing the resources from the monolith. section 10.2.1
- Extract dependent resources next, replacing direct references with dependency injection through the infrastructure provider API. section 10.2.2
- Repeat the process toward the lowest-level resources, isolating components and testing each change to limit disruption. section 10.2.3
Extracting GCP IAM resources
A team separates project-level IAM roles and service accounts from a large configuration by copying the code, importing existing resources into new state, verifying a no-change plan, and removing the IAM resources from the monolith. The same approach later extracts a container orchestrator, which retrieves network and subnet identifiers through the GCP API. section 10.2.1 section 10.2.2
Figure 10.5 The sundew system’s IAM policies for the GCP project have no dependencies, and you can easily refactor them without disrupting other infrastructure.
Use the figure to trace how dependency-free IAM policies move into separate configuration without disrupting live infrastructure. section 10.2.1
