Weigh infrastructure as code risks against the benefits

Assess infrastructure as code risks

Automation and infrastructure as code carry out operations with incredible speed -- which is at once both positive and negative.

IaC and automation execute immediately -- depending on how your organization might code in delays. Some organizations write extensive code, which includes prompts to an admin for input before task completion. This pause is a safety check to verify that all code functions as intended before any bugs, mistakes or even simple misspellings apply to the designated area of effect -- and possibly unexpected areas, as well.

With infrastructure as code, automation features resolve any issue or bug in the code release before an IT admin can think to pause or stop it. This isn't a new concern with any form of automation, from simple scripts to comprehensive orchestration, but the challenge with IaC, specifically, is how broadly a code update can affect an IT environment. Scripts and other types of batch files have a limited scope of effect and therefore limit the damage they could deliver unexpectedly.

IaC works only with strong software code control, testing and release processes in place.

With infrastructure as code, the effect of an issue or failure is much greater because it isn't isolated to a single server or application. From incorrect storage allocations that cause I/O issues to network misconfigurations that result in packet loss, one bug in the code could affect a collection of resources -- which could affect the entire company in the blink of an eye.

This domino effect illustrates the level of risk in infrastructure as code vs. that of scripting: higher efficiency gains introduce the potential for higher risk.

IaC works only with strong software code control, testing and release processes in place -- not just in progress or planned in the future. Infrastructure is too critical to wing it. In addition, IT organizations must develop and document detailed plans before they adopt infrastructure as code.

Code variation adds complexity

Infrastructure as code creation is not a step-by-step process detailed in a textbook. IaC development depends as much on business needs and processes as the infrastructure engineer who writes it. Infrastructure code functions similarly, but its development is unique to its writer.

Personalized or specialized code isn't problematic for an IT organization -- unless the code writer leaves the company before it retires. Then, a new admin must make sense of an unfamiliar, highly personal code base.

Once again, the problem lies in scope and effect. To take over an application role or server role is a challenge, but something with which most IT admins have some level of familiarity. It isn't the code itself that proves problematic for fresh eyes, but rather its construction and documentation. And, because of its ultimate range of effect, odds are slim that a new admin will be able to run trials in a sandbox before the code is needed in production.

While this challenge sounds like a personnel problem, it highlights another critical issue in infrastructure as code -- namely, that it requires support that isn't provided typically in a traditional off-the-shelf product.

These challenges shouldn't prevent IaC adoption, but remember to exercise caution. Set up large test environments that can include a larger number of products and enable IT admins, or infrastructure engineers, to test their code. Create specific and comprehensive rules that govern code creation and revision control. Develop and write thorough documentation -- and then continue to develop it. Ensure multiple staff members can work with infrastructure as code and remove any single points of failure.

IaC requires staff familiarity and competence, as well as a notable amount of resources -- especially time to create documentation -- but these requirements ensure that infrastructure code doesn't become a monster that wreaks havoc in the software-defined data center.