As IT organizations wrap their heads around DevOps, there’s one term they often find being used with "DevOps" — infrastructure as code. (Sometimes "infrastructure as code" even seems to be regarded as synonymous with "DevOps.") But what is infrastructure as code?
Infrastructure as code is the practice of treating infrastructure as if it were code — just like software, in fact. Treating infrastructure as if it were code lets you adopt powerful practices that have been used by software developers for years, and with great success — practices that include version control, peer review, automated testing, release tagging, release promotion, and continuous delivery.
The older methods of infrastructure management — manual processes and documentation, brittle single-purpose scripts, and graphical user interface based tools — each had their uses in the past. Today, though, with the perpetual need to scale infrastructure, adoption of ephemeral infrastructure, and greater application system complexity, new ways of keeping things under control are needed.
The wide adoption of virtualization and self-service cloud infrastructure has shifted the bottleneck from allocating servers to configuring them. Where it used to take weeks or months to allocate a server, now it can be done in a minute or two.
These new challenges require a change to the way IT works, but the primary challenges are the same as they’ve always been:
- Develop the most reasonable change for a problem, then propose its adoption into the main codebase through a pull request.
- Reasonably prove a given change is safe and correct by deploying it to a production like environment and run a sufficient number of tests.
- Orchestrate change to a potentially large and complex portion of the infrastructure.
- Know at any moment the current state of any part of the infrastructure, especially its health.
- Know the history of any configuration, including who proposed it, who approved, and when it was applied.
- Do all of the above as quickly, efficiently, reliably and securely as possible.
To address these challenges at modern scale (both in terms of infrastructure and organization), while still keeping up with the needs of the business (not to mention keeping the lights on), you need new methods of collaborating, delivering, and gaining situational awareness.
Previous methods of IT management won't work if you're trying to address modern scale and agility requirements. Graphical tools often have a low learning curve, but they fall apart when trying to account for differences between platforms or porting configurations as code progresses from one environment to another. Graphical tools also make it difficult — or impossible — to share pieces of configuration with other teams, do peer review on proposed changes, view historical changes, and roll back to a previous set of configurations. And scripts are equally unsuitable for modern scale and agility. They're brittle, unmaintainable, are sprawled throughout teams and individuals, and are rarely portable between environments.
Defining your infrastructure as code solves these problems because code is portable, reusable, shareable, testable, and introspectable. And in case we haven't said it clearly enough, manual changes are just terrible — period.
Aligning with the business
Gene Kim’s Three Ways is a path towards continuously improving IT’s ability to serve the business through rapid learning, experimentation, and continuous feedback loops. With the Three Ways, IT builds and reinforces a culture of fast feedback, collaboration, iteration, and visibility — all of which support the rapid learning, experimentation and continuous feedback that help the business become more competitive.
The cultural characteristics of the Three Ways are enforced through the technical practices of infrastructure automation, peer review, continuous delivery, automated testing, and deployment automation. All of these technical practices, by the way, are DevOps practices, and all are enabled by managing infrastructure as code.
Here's why that is the case. Code is portable, reusable, and can be managed with version control. As changes are made to the infrastructure code, these changes are committed to version control, where they can be peer-reviewed, tested, collaborated on, and approved (merged) by peers. Once the change has been accepted, it can be automatically deployed to thousands of systems just as easily as to a single system. The version control system also provides an audit history. Using a continuous integration/delivery system, these steps can be codified into a continuous delivery pipeline. The result is a workflow that promotes collaboration, dramatically shortens feedback loops, reduces deployment risk, and keeps a continuous history of who did what.
IT’s common language
In order to align everyone in IT, it’s important to establish a common language for everyone to use when contributing to and managing infrastructure. With a common language, everyone can propose infrastructure improvements, collaborate on infrastructure implementations, and read the code itself to understand how any part of the infrastructure is being managed. (You may have seen the term "executable documentation" for infrastructure code. That's because the code itself enforces the documented infrastructure policies.)
When choosing your infrastructure code language, there are important factors you should consider. Since you want everyone aligning with a common language, the language needs to have a low learning curve, be declarative, be idempotent, and holistically manage the infrastructure as a single source of truth. Let’s break that down.
It’s important to consider the strengths and skill level of everyone who contributes to the infrastructure. Are they all software developers with degrees in computer science? Probably not. At the same time, do not underestimate their capabilities, nor their experience in writing some form of code. Ask your DBA to show you their PL/SQL queries — that should convince you your DBA really does know how to write code. Or ask to see your Windows administrator’s batch files or login scripts. Almost anyone in IT can pick up an infrastructure language, provided it is well-designed, purpose-built, and imposes a strong opinion on how it should be used.
Idempotence is defined as the property of an action always having the same result. A example in mathematics is taking the absolute value of a number and continuing to apply the absolute value to the result. No matter how many times you perform that operation, the result is always the same. An example operation from Unix is the
rm -f command. No matter the beginning state, the result is always that the file does not exist.
The more your code is idempotent, the more it can handle any condition, and always do the correct thing. Idempotency is a critical component to successfully using infrastructure as code.
As more and more of your IT team contributes to the infrastructure code, you need to know the solution you’ve chosen can scale to potentially hundreds of contributors across a plethora of teams. Where are all the different places the infrastructure code can live? How many different pieces of code manage the same system? What happens when two contributors write code that manages the same configuration differently?
With holistic modelling, all the infrastructure code is combined to a single central source of truth that identifies how each piece of infrastructure code relates to every other piece. Because the relationships between all the pieces of code is understood, common mistakes such as two contributors trying to manage the same configuration differently are caught, and problems averted.
Infrastructure as code is an important practice to adopt if you want to implement DevOps in your organization. I hope this has helped you understand the importance of infrastructure as code in making your IT organization more responsive, collaborative, faster, and ultimately more innovative.