Adopting Infrastructure as Code? Start Small

Infrastructure as Code delivers many benefits, but organizations often miss out on these opportunities because they don’t approach IaC effectively. 

Managing and provisioning infrastructure is traditionally a manual process that results in tasks being handed off between individuals. These manual processes often create inconsistencies and result in silos of knowledge that are limited to small groups or individuals, which can make it difficult to onboard new employees.

IaC moves these processes into tools that put code in a standardized format. Everyone uses the same language, which improves version control and simplifies knowledge sharing. For organizations with regulatory compliance obligations, IaC also simplifies review processes, with the code serving almost as an audit log.

Some IT professionals assume that IaC is suited to organizations that operate only on-premises or cloud-based infrastructure. In fact, many IaC capabilities can succeed in both environments. The trick is to approach implementation strategically.

When organizations decide to adopt IaC, one of the biggest pitfalls is trying to take on too big a project, or a full IaC configuration in one swoop. IT teams may struggle with accomplishing such a large task, then decide the technology doesn’t work and give up. That’s why my primary piece of advice is to start small. 

For example, an organization should use IaC to configure an IP address, then move on to configuring subnets and virtual LANs. Moving one step at a time lets the team learn the technology and get comfortable with the new processes before focusing on next-level capabilities, such as designing best practices. Ultimately, when an organization matures, it can decompose the IaC that it has developed into reusable components and recognize even more efficiencies in the process.

Getting processes in order also helps. Many people try to shift existing processes to IaC, but they should take time to review existing processes to identify inefficiencies and remove unnecessary steps before committing their first line of code.

Starting small makes it easier to address the human factor. Automation delivers significant value, but it requires a change in how people are used to doing things. It can also raise fears that automation is a path to job elimination. 

The reality is that even with automation, organizations still need people with the technological knowledge to create IaC and then to support these tools. And once the teams get past the initial coding, they find that they transition from a role of solving emergencies to one of innovation. This leads to the elevation of each team member’s capabilities, and the team becomes one of developers and inventors instead of firefighters.

Significant change always requires a culture shift, and one way to instill an IaC culture is to first engage staffers who can champion and lead the change. This ties back to my recommendation to start small. How could the provisioning team, for instance, take advantage of IaC? How could the network team use it? You might simply start with one team or one process.

Teams will begin to recognize the speed with which things are getting done by the group that is adopting IaC and inquire about how they can accomplish the same speed and precision. This leads to teams communicating and a transfer of knowledge, which slowly breaks down the silos within the organization and leads to better flow of information. That’s how culture grows over time, and it builds the communication and collaboration capabilities that are critical to DevOps processes.

Story by Viet Pham, a DevOps Sr. Solution Architect for CDW. He assists customers with understanding the tools and technologies that support successful DevOps practice. Viet has experience with Red Hat Ansible Tower, Red Hat OpenShift, CloudBees Jenkins, Chef, Puppet and Red Hat CloudForms.