Infrastructure as code, the practice of managing and provisioning cloud infrastructure through software code rather than manually, may be the darling of many analysts, as the IaC market is projected to reach more than $2 billion in 2027. But it’s going through some growing pains as it matures.

A recent analysis by Jason Turim on The New Stack brings to light the latest challenges and prospects of using infrastructure-as-code techniques. IaC describes the automation of common application development tasks to orchestrate cloud workloads and allocate resources as part of normal coding pipelines. Instead of manually configuring servers and databases, IaC puts this information into scripts that when run create the necessary infrastructure.

That means that a developer can quickly pre-populate identical development, testing and production environments and avoid common manual configuration errors. But though this is a boon for developers and does help speed up coding projects, IaC also creates new risks in terms of security and governance.

For example, Turim mentions that developers are “now expected to understand and manage infrastructure configuration, adding another layer to their responsibilities.” That blurs roles between developers and operations teams, even though the two have been moving closer together over the past several years. Sorting that out could be a challenge for technology managers.

The early IaC automation efforts came from companies such as Puppet Inc. and Chef Software Inc. Then the cloud providers got into the act, realizing they had to make configuring their myriad cloud services easier, using tools such as Red Hat’s Ansible, IBM Corp.’s Cloud Schematics and Amazon Web Services Inc.’s Cloud Formation and CodeCommit services. But these had downsides because they further locked in developers to use their particular clouds.

Then came two signs of IaC maturity: First was that providers have moved into solving deeper problems. For example, startups such as Pulumi Corp. can generate natural language IaC scripts, making them more accessible and not dependent on a particular coding language.

Second was support for multicloud environments, which is where HashiCorp Inc.’s Terraform came along. It made automation more powerful by working across multiple cloud platforms without the need to create custom scripts or cloud-specific tools.

However, though Terraform has long been the poster child for IaC, earlier this summer Hashi changed its licensing from open source to a business license that ruffled developers’ feathers. One counter-effort has risen from this discontent, the Linux Foundation’s Open Tofu project. It sticks with open-source methods and is designed to be a quick replacement, using Terraform configuration files and scripts.

But this rich open-source heritage is also a major issue for IaC deployments, because “many development teams don’t account for the extent of open source code components used by their IaC,” as Palo Alto Networks Inc. wrote in its playbook almost a year ago.

Both Open Tofu and products such as Pulumi make the infrastructure development more collaborative and understandable to more of the team. They also eliminate costly manual configuration processes in wider areas, making IaC more potent.

Like many aspects of modern software development, what is usually left for later work has to do with making networks more secure. Developers aren’t security specialists, and though the concept of “shifting left” or building in security by design early in the development process, have assumed folklore status, they are often neglected.

The number of public open storage containers – or those using hard-coded passwords — is testimony to how such simple errors can continue to plague developers and corporate security managers. “The primary goal of IaC should always be to not only produce repeatable infrastructure but to also prioritize the security of what’s built,” wrote Turim. To move this from folklore to actual practice, Palo Alto Networks suggests a three-step “crawl, walk and run” approach to operationalize IaC security, as shown in its diagram below.

A second challenge has to do with how IaC handles versioning. This means development teams can apply version tracking with their infrastructure needs just as they do as part of their normal coding process. That’s the theory, anyway.

But it can also mean that sometimes an environment isn’t provisioned correctly and requires tedious debugging and backtracking, which can eat up the time savings in the automated setup process. Because of the power of IaC automation, a single misconfiguration can be quickly deployed across hundreds of resources, in what is called the snowball effect.

Turim points out that modern software development practice depends on quick feedback on coding errors, but this feedback can often be missing in many IaC deployments. “This means developers spend more time waiting to see if their configuration and deployments succeed rather than getting the feedback they need, leading to inefficiencies in the development process,” he writes.

Automation can be a two-edged sword. The trick for future IaC success is to ensure that the benefits have sufficient guardrails and the tools can deliver on them.

Images: MrPanda/Pixabay, Palo Alto Networks