This content is part of the Essential Guide: Use these DevOps examples to reimagine an IT organization
News Stay informed about the latest enterprise technology news and product updates.

Infrastructure as code tops IT's DevOps challenges

Infrastructure as code is seen as the best way for IT pros to keep pace with modern application development, but that is easier said than done.

IT operations pros have some work to do to automate the infrastructure underpinning DevOps initiatives.

While cultural barriers are some of the most daunting DevOps challenges, IT operations practitioners say that capturing infrastructure as code is the most significant technical hurdle to supporting modern application development practices.

Even though configuration management tools such as Puppet and Chef that enable infrastructure as code have been on the market for years, the concept can still be difficult for some IT pros to grasp.

Not everyone has yet bought into the concept of taking a traditional rack and stack infrastructure with management of IPs in Excel spreadsheets, and automation through Bash scripts and Ruby code, according to Pauly Comtois, vice president of DevOps for a multi-national media company. 

"A lot of our customer organizations barely have operations automated in any way," echoed Nirmal Mehta, senior lead technologist for the strategic innovation group at Booz Allen Hamilton Inc., a consulting firm based in McLean, Va., who works with government organizations to establish a DevOps culture.

"It's 2016, and we should be able to automate those deployments," he said. "Once you do that, you can start to use the exact same tools to manage the infrastructure that you use for your application code."

A big reason why companies have been slow to automate their operations is that infrastructure as code work can be more easily discussed than done -- legacy applications often weren't designed with tools such as Chef or Puppet in mind.

Third-party software that runs on Windows isn't conducive to automation via the command line, Comtois pointed out. "What makes that really technically challenging is when that piece of software also happens to be critical to the workflow of that organization, so I can't just go in and rip it out and replace it with something else."

These issues can be overcome, but "some transitions are more painful than others," he said.

Security teams also have to be brought on board with managing infrastructure as code, according to Mehta.

"Infrastructure as code and configuration management make compliance a lot easier, but that also means that compliance is no longer a thing that you do once a year," he said. "It gets enveloped in the DevOps process [just like] any piece of code needs to go through."

The majority of time spent by IT operations into the foreseeable future will be transitioning manual processes into infrastructure as code, or automated steps that follow the same pipeline that application code does, according to Mehta.

DevOps and IT ops: a two-way street

You know the top challenges, but do you know where they stem from? Learn how a changing DevOps culture affect IT pros' day-to-day responsibilities and the tools you can use to bridge that gap.

Infrastructure as code benefits

So why go through the technical headaches to establish infrastructure as code?

According to experienced DevOps practitioners, it's the only way to create an automated IT infrastructure that adequately supports automated application development testing and release cycles.

"In our environment, Jenkins makes many calls into Ansible to build stuff and deploy and configure it," said Baron Schwartz, founder and CEO of VividCortex, a database monitoring SaaS provider based in Charlottesville, Va. "Whatever we want to be automated, we have CircleCI calling a Web service that pokes Jenkins, which runs Ansible -- it sounds like a Rube Goldberg machine, but it works well."

Even things the VividCortex team wants to kick off manually use a chat bot to call into Jenkins and kick off a build job with Ansible, Schwartz said.

Getting IT ops staffs used to the concept of infrastructure as code is key to securing their buy-in as DevOps is more broadly rolled out in an environment, according to Caedman Oakley, DevOps evangelist for Ooyala Inc., a video processing service headquartered in Mountain View, Calif.

"Operations doesn't want to see things change unless [it] know[s] what controls are in place," Oakley said. "Everything being written in a Chef recipe or in cookbooks means [operations] can see what the change was and ... knows exactly who did the change and why it's happening -- and that actually is the greatest opener to adoption on the operations side."

Ultimately infrastructure as code simplifies infrastructure management, Oakley said.

"Operations can just go manage the infrastructure now, and don't have to worry about figuring out why one server is slightly different from another," he said.  "You can just fire up an instance any way you want to."

Beth Pariseau is senior news writer for TechTarget's Data Center and Virtualization Media Group. Write to her at or follow @PariseauTT on Twitter.

Next Steps

Guide to infrastructure automation tools and methods

What's the difference? DevOps vs. NoOps

How to nail a DevOps job interview

Dig Deeper on Real-Time Performance Monitoring and Management

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

What's the biggest technical challenge to operationalizing DevOps?
The biggest technical challenge is maintaining business operations intact while migrating to DevOps model.
Thinking of all those tricky scripts and settings that need to be updated, rewritten, or ported to another tool. One way is to do it slowly, replacing and testing component after component, mitigating the risks. And it takes time.
From my experience, it is managing the technical barriers across firewalls and vendors. Almost every enterprise technical landscape I have seen involves multiple vendors - with pieces of infrastructure and platform management owned by different companies and vendors. So the text book 'end to end automation' examples and even best practices simply break down.
I agree with both @Albert and @Bandimatt. We’ve spent a great deal of time, effort, and money working to consolidate our vendor list, which is now paying dividends. In fact, we spent much more time and effort on vendor consolidation that we did on cultural changes, etc.
I'd say it's skills and people possessing them. Somehow nowadays the focus is too much on tools as if they create, operate, and maintain themselves.
Infrastructure as code has been a real struggle for us. Not in supporting DevOps, because they see the benefit, and work with our change management team to make it happen. The real problem comes from other areas of IT that lie outside the DevOps sphere of influence, and fight tooth and nail to maintain the status quo and don’t see the benefit of infrastructure as code.