I recently wrapped up a story at my client to define our service's infrastructure resource using declarative infrastructure. Specifically, they use a Google Cloud Platform (GCP) tool called Config Connector to do this.
The way I most typically create infrastructure (such as a database) is by clicking through my IaaS (infrastructure as a service) provider's GUI (graphical user interface). There are obvious downsides to this. For example, what happens if the database gets destroyed when I no longer work at the company? Who knows the exact configuration to get it back?
Problems like this are what infrastructure as code (IaC) is meant to solve. Within the IaC bucket there are two approaches: imperative and declarative.
With the imperative approach you have scripts that define how infrastructure gets created. Chef is an example (or at least used to be an example) of this approach. Although this provides some benefits over the GUI approach, these scripts are typically brittle and often out of date.
With a declarative approach—often called “declarative infrastructure”—you define what the infrastructure should look like, in configuration files, and let other tools be responsible for updating your environment to match your config files.
Examples of declarative infrastructure are Config Connector, which I referenced above, and Terraform. RedHat and IBM both recommend the declarative approach over the imperative one. Once a team is over the hurdle of learning how to configure their infrastructure using their preferred tool (which is no small feat), they can rely on well-tested systems to get the job done.
Before this work, I'd heard of infrastructure as code and of some of the tools available, but I couldn't articulate the different approaches, nor the upsides and downsides.
Stephen Meriwether
