In many ways, infrastructure as code, or IaC, is a wonderful thing. By allowing engineers to define and carry out complex configuration tasks using code, IaC makes processes more repeatable and scalable, while also reducing the risk of configuration oversights that stem from human error.
But there are also reasons to dislike IaC. Even when you implement IaC flawlessly, you may find that IaC hampers your operations at least as much as it helps them.
Keep reading for a look at the potential downsides of IaC, and why it's important to think strategically before deciding to apply IaC to every possible use case within your organization.
The Basics of IaC and Its Benefits
Before looking at the pitfalls of infrastructure as code, let's briefly define what IaC means.
IaC is the use of code instead of manual processes to manage infrastructure. In other words, IaC is the opposite of applying a desired configuration or update to infrastructure by changing its settings manually.
To put this in context, imagine that you want to launch a virtual machine instance in the cloud. You could do so by logging into your cloud console and clicking through the series of steps necessary to launch your chosen instance type. That would be a manual approach.
Alternatively, you could use an IaC tool that lets you write "templates," which are code that defines which type of instance to launch. Then, you could automatically launch that instance based on your configuration.
The advantage of the IaC-based approach is that you can define your configuration once, then reuse it as many times as you want. If you wanted to launch 100 VM instances, for example, you could do so by setting up and applying just one IaC file that defines them. That beats having to launch 100 instances manually, which would take much longer.
In addition, IaC reduces the risk of mistakes or oversights. You can't accidentally choose the wrong type of instance, for example, because you don't have to choose an instance type manually at all. As long as your code is accurate, your configurations will be, too.
Why IaC Isn't Always Beneficial
Just because IaC offers some advantages over manual configuration doesn't mean that IaC is always the way to go, however. On the contrary, there are several good reasons to stick to doing at least some things manually.
IaC setup takes time
Perhaps the most obvious reason is that setting up the IaC code that you need to configure resources requires a lot of effort. In addition to having to devote time to the task, you also need to learn an IaC tool.
If you're going to configure at least dozens of resources, this upfront effort may be worth it. But IaC can be overkill if you are working with a small-scale environment. In that case, manual configuration tends to make more sense.
IaC requires constant maintenance
Infrastructure requirements are always changing, and you need to update your IaC code constantly because of those changes.
Granted, you also have to update infrastructure constantly if you manage it manually. But at least then, you're only performing one maintenance step — updating the infrastructure. If you have to update your IaC templates and then also apply them to your infrastructure so that an update takes effect, your update process is more complicated than it would be without IaC in the picture.
IaC forces developers to 'own' infrastructure
In many cases, IaC templates end up being created and managed as part of the CI/CD pipeline. Teams tend to take this approach because IaC code governs how hosting environments are provisioned for an application, so it's logical to manage the environment configuration within the same CI/CD pipeline engineers use to build the app.
The downside of this approach is that because developers own the CI/CD pipeline, managing IaC templates as part of CI/CD forces developers — rather than IT operations engineers, who are traditionally the ones responsible for managing infrastructure — to become stewards of infrastructure, too.
You could argue that this is a good thing; after all, the idea that developers should participate in infrastructure management is part and parcel of DevOps. But you could also argue that it's a bad thing because it increases the burden placed on developers and distracts them from their main job — writing application code, not infrastructure configuration code.
IaC turns developers into security engineers
Along similar lines, when you embed IaC in the CI/CD pipeline, you force your developers to bear a larger share of responsibility for security management, too. Insecure infrastructure configurations could lead to breaches, and because developers are typically not experts in infrastructure security, they're arguably not the best people to figure out how to optimize the security of hosting environments.
You could, again, make the case that having developers pay more attention to infrastructure security is good. But you could also argue that infrastructure security should be the domain of people who specialize in infrastructure security, and that developers should focus on tasks like writing secure application code.
Measuring IaC Pros Against the Cons
None of the above means that IaC is inherently bad or should never be used. But it does mean that teams should think critically about whether the potential downsides of infrastructure as code outweigh its benefits for a particular use case.
If you are working with small-scale infrastructure, IaC may be more effort to set up and manage than it's worth. And if IaC overextends your developers by forcing them to take ownership of things they are not prepared to own, it can do more harm than good.
About the author
Christopher Tozzi is a technology analyst with subject matter expertise in cloud computing, application development, open source software, virtualization, containers and more. He also lectures at a major university in the Albany, New York, area. His book, “For Fun and Profit: A History of the Free and Open Source Software Revolution,” was published by MIT Press.
