What do we want?
Compute resources!
When do we want them?
Now!
Every team I’ve worked with
We usually don’t care about the details of how those resources come about, as long as we get what we want. Here’s a ‘real world’ analog…
When you go to a restaurant and order a meal, you don’t tell them how to make it. You declare that you want a Club sandwich, tea, and a side salad with balsamic dressing. Then the restaurant’s staff prepares your order and gives it to you when ready. You don’t provide the the staff with an imperative set of instructions: cut the bread, toast it, put turkey, ham, and other toppings on it.
It’s about the same way with (most) infrastructure as code tools. You describe the desired state of your system or application in a declarative form to tools like Terraform, CloudFormation, Kubernetes, and Swarm. Then you tell them ‘make it so’ and they get it done by adding, modifying, and deleting compute resources. Let’s dig into the details of this process we often call ‘converging’.
Converge!
Once you have described the desired state of your application’s compute, storage, and networking resources in code, you can use the infrastructure management tool to realize that code into resources that exist in the real world.
The following diagram shows the high-level convergence process executed by many tools:
In Concept: Infrastructure as Code, I said the tool must:
- construct a model of the desired state of the infrastructure as defined by code
- (re-)construct a model of the current, actual state
- compare the desired state to the current, actual state and produce a diff
- construct a plan to using operations in the service’s API to converge the actual state to the desired state
- applying that change, if you choose to
This process is complicated. But if you think about what happens in steps 3 and 4, where a diff of current to actual state and a plan to converge to your desired state is produced… well, to me, this is Indistinguishable from Magic.
Being able to describe nearly arbitrary sets and combinations of resources and have a tool manage transitions between desired states is incredibly powerful. A ‘simple’ change might result in 100s of Cloud service API calls and I get to sit back and review a set of proposed changes instead of painstakingly constructing that sequence of operations myself.
This approach has analogs in the technology world that you may already be familiar with:
- Configuration Management Systems like Chef, Puppet, and Ansible help you declare the desired state of a machine’s files, applications, and kernel configuration and the tool and associated libraries will try to converge it to the desired state.
- Object relational mappers observe changes to data represented in an object graph and figure out the SQL commands to merge or persist that data back to a relational database.
- Web developers describe use the document object model and css to describe how a webpage should look and browsers render it.
Hit me up if you have any questions about how this works, especially with Terraform. I teach how all of this works in detail in the hands-on Building High Quality Infrastructure with Terraform workshop. I’d love to help your team leap-frog to the leading edge of infrastructure management practice using Terraform.
Stephen
#NoDrama
