Infrastructure as Code is a key element of most top performing engineering setups. It’s a big leap forward in the way Ops and Devs interact with their own infrastructure. (Galante, 2021)

After the introduction of the QA and IaC topic in the first blog post of this series, we now dive head first into the origins of IaC - Why do we even need to in the first place?

The Need for Automation 🤖

The massive adoption of cloud over the past years has forced the need for automation in the infrastructure sector. As shown in the hype cycle depicted below, topics like industry cloud platforms or cloud sustainability are an innovation trigger ready to define new industry standards soon. Previously a change in infrastructure was limited by the hardware purchasing cycle often spanning weeks before a new piece of hardware arrived. Due to this circumstance, there was no need to rush its proper setup (Morris, 2016).

Hype Cycle for Emerging Tech (Perri, 2022)

With cloud deployment of virtual anything needed in infrastructure can be configured, deployed, and destroyed in a matter of minutes. This of course leads to fast provisioned yet poorly maintained systems, an ever-growing portfolio of servers, sometimes even spanning multiple cloud providers, and configuration drift as well as snowflake servers.

Early on it was clear that the full potential of cloud could only be utilized using novel tools, which for one, help to automate deployment, and additionally, enable those responsible to maintain the system with reasonable effort. As Morris put it...

The essence of Infrastructure as Code is to treat the configuration of systems the same way that software source code is treated.

... only the reorientation of infrastructure development and management towards software development can ensure the most efficient handling of this new and unique technology.

Four Levels of Operational Maturity 🌡️

The full automation of processes and making them auditable, scalable, and their results reproducible nowadays is the overall goal of the ongoing digitalization. In this context the question of maturity of a system or procedure, as in this case, the operation processes, always needs to be answered before progress can be made. For practices of provisioning in operations there are four levels of maturity define by HashiCorp:

• Manual
• Semi-Automation
• Infrastructure as Code
• Collaborative Infrastructure as Code

Each of those stages is characterized by how the infrastructure is provisioned and how traceable changes made are as well as the ability to rollback and collaboration, respectively reuse, possibilities. The model provided also corresponds very well with the common maturity model seen over the whole operation department. There is a general agreement on a model similar to the hereafter graphic representation by Accenture:

Operational maturity model (Henneborn & Mody, 2021)

It also describes a stable, yet labour-intensive workflow at the start of operations, it then gets more and more efficient by automation until the processes are orientated towards only judgment-based manual tasks, automating the others. With this it can be seen that the clear definition of what level of maturity in the provisioning regard a company currently has, is crucial for the introduction of IaC workflows and tools in operations. It defines the starting point of this operational evolution leaning more and more towards DevOps.

Next Steps 🪜

In the next blog post Terraform comes into the picture. We are going to discuss how this tool works and see what we can do with it. So, stay tuned if you are interested!

Cover Image by Skitterphoto! 🥳