beawolf - Fotolia
IT operations pros increasingly rely on infrastructure-as-code tools to keep up with DevOps, but these tools have advanced almost as quickly as the apps sys admins have to support.
Established infrastructure-as-code companies Chef and Puppet have recently remodeled their tools to support containers and their underlying infrastructure. Chef overhauled its codebase into three major open source projects last year, and users are still trying to understand its Habitat product. Puppet its own roadmap last quarter to bolster its container support and will soon offer an API for container management. Amazon Web Services (AWS) CloudFormation, released in 2011, has also received various feature updates -- approximately once a month during the last year.
Among newer tools, Ansible, which was launched five years ago and subsequently acquired by Red Hat in 2015, offered integration with networking equipment earlier this year, as well as integration with Red Hat CloudForms for multicloud support. HashiCorp Terraform, which industry watchers said has gained momentum quickly since its initial release in 2014, has yet to reach a 1.0 stable release, which leaves users to grapple with breaking changes in recent upgrades.
"It's a rapidly evolving , and a lot of companies are just getting into this space," said Brandon Cipes, managing director of DevOps at cPrime, an Agile consulting firm in Foster City, Calif. "Most of the people working with these tools are sys admins who are trying to figure out how to scale, rather than developers."
Infrastructure-as-code tools mix and match
Most companies use a combination of the tools named above, which can further compound the complexity of DevOps environments, Cipes said.
Forward-thinking companies that want to establish DevOps practices tend to use AWS, which usually makes CloudFormation their choice among infrastructure-as-code tools. But in an increasingly multicloud world, many companies then seek out alternatives that work on other public cloud platforms as they mature, or offer a friendlier user experience.
"It's just not the most friendly tool in the world," Cipes said of CloudFormation. "It doesn't use an easy-to-read language, it requires a lot of parameters to be set, and all of those parameters and details have to be very particularly configured or it will break."
However, CloudFormation isn't easily discarded altogether.
"CloudFormation is the lingua franca to exchange ideas about infrastructure and AWS resources [with other users]," said Joaquin Menchaca, DevOps engineer at San Francisco-based goBalto Inc., which markets software for clinical trials in the healthcare industry. "We definitely need to know the technology to be able to exchange ideas with the rest of the community because of its ubiquity."
Menchaca's team prefers to work with Ansible, since its basis in YAML files makes it interchangeable and manageable alongside the company's application code. But Ansible's development of network automation features of late detracts from progress in other areas, and it still has work to do on containers, he said.
"Their efforts with Docker have been disappointing, as they focus more on Ansible Container projects," Menchaca said. Ansible Container is meant to give admins a familiar interface as they deploy containers, but many in the industry do not use these modules, Menchaca said. Instead, they use Ansible's shell script module to issue commands manually.
"It begs the question, 'Why not just use shell?'" he said.
Terraform offers ease of use, but upgrade headaches
The most recently infrastructure-as-code tool, HashiCorp Terraform, has supporters among DevOps shops that have found its command-line interface easier to use versus CloudFormation's JSON templates. They also like its support for state configurations, which supports a broader range of resources than stateless tools, such as Ansible, Chef and Puppet.
"Terraform is a general language for working across clouds and various resources so that we can work with things like Datadog [monitoring] alerts, AWS resources or potentially spin up parts of Google's cloud infrastructure, all from one place with one uniform configuration language," said Calvin French-Owen, co-founder of San Francisco-based data analytics company Segment, which was among the early adopters of Terraform.
"CloudFormation makes you want to poke your eyes out, whereas Terraform is much simpler to understand," French-Owen said.
Infrastructure-as-code tools prompt stateful vs. stateless debate
While state configuration in Terraform has attracted some users, it turns others off.
"Terraform is scary, because if the state is incorrect, you can destroy your entire organization's infrastructure with a single command," said Joaquin Menchaca, DevOps engineer at goBalto Inc.. "Stateless has always been the preferred way to manage configuration, from CFEngine to Puppet, to Chef and to Ansible; Terraform broke away from this and tries to sell it as a feature."
It's true that a single command can destroy an infrastructure that's monolithic, said Dale Ragan, senior software engineer for SAP's Concur Technologies Inc., but a modularized infrastructure will prevent that.
"This is the approach we took, because knowing about the resources you have is important, and state gives you that," Ragan said. "Also, remote state is tracked [in Terraform] to allow teams to build on top of infrastructure they may not control."
In the end, Terraform probably won't totally replace tools such as Ansible, Chef and Puppet for most shops, said Brandon Cipes, managing director of DevOps at cPrime. It's best used to create infrastructure and make minor changes to something that was already created by Terraform, but not to make changes to operating systems as users do with Puppet and Chef.
"You could call Terraform a subset of Chef, Puppet and Ansible," Cipes said. "It's a tool people like to get infrastructure up quickly, cloud-agnostically, without having to build out all the other stuff those other products necessitate."
However, Terraform's release, which the company labels 0.10, is still at least a month away from general availability, and a stable 1.0 release won't be available until next year at the earliest. A 1.0 release represents a commitment by HashiCorp to stability at scale and fewer -- if any -- breaking changes with updates, but Terraform has endured seismic upheavals with recent pre-1.0 releases.
The 0.9 release, for example, refines support for remote state configuration -- a feature that helps teams that share an infrastructure not to step on each other's toes when they make changes -- in a way that makes an upgrade both a necessity and a pain, said Dale Ragan, senior software engineer for SAP's Concur Technologies Inc., an expense management software-as-a-service provider based in Bellevue, Wash.
"It looks like it'll be a lot easier for new engineers or developers to initialize their workspace and save the state to remote state by running just one command," Ragan said. This fundamentally changes how state files are stored in Terraform, however. "We have to reimplement a few things on our side as far as our workflow and re-educate ourselves to move our state as it is now to the 0.9 version," he said.
French-Owen's team has discovered bugs in previous attempts to update remote state in Terraform Enterprise.
"In some cases, we've found it's not quite a -class citizen compared to when we were managing state ourselves and putting it on S3," French-Owen said, referring to Amazon Simple Storage Service.
The 0.10 release also reorganizes Terraform's source code to break out integrations with service providers into separate modules, which means the core product won't be updated as frequently to support service provider features. Ultimately, this means more safety and stability while using Terraform, but it also will be another major change for users who have already navigated many major updates.
Learn the basics with this infrastructure-as-code template
For every benefit of infrastructure as code, there is a challenge
Is configuration management the right step for your IT org?