An initiation into infrastructure automation tools and methods
A comprehensive collection of articles, videos and more, hand-picked by our editors
"The business is growing very fast and IT must move even faster." Sound familiar?
Faced with development demands and expectations for a stable infrastructure, Jonathan Fletcher, enterprise architect at Hiscox Ltd., an insurance provider incorporated in Bermuda, turned to DevOps. The company uses the Puppet configuration management tool to make its environment "a well-known state."
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Hiscox's development and production environments are configured in different ways with different settings. The Puppet configuration management tool helps solve that problem, Fletcher said, as part of a DevOps toolchain.
That toolchain isn't likely to simplify any time soon, said Steve Hendrick, principal analyst for application development and deployment research at Enterprise Strategy Group Inc. (ESG), in Milford, Mass. DevOps is unlikely to ever succeed without it -- custom scripting can't match the level of policy-driven automation that configuration management and other DevOps tools provide.
"To have a comprehensive take on DevOps, you need a toolchain," Hendrick said, as the scope of coverage for one tool can't cover every aspect of development and infrastructure management.
Hiscox commonly uses the Puppet configuration management tool to set up a server environment and go from the operating system buildup to a working application, but Fletcher said the company could do more to take advantage of its capabilities. He uses it to configure middleware, and to define infrastructure, firewall rules and network component parameters. The goal is to manage the entire environment.
They also considered CA Technologies' Release Automation before deciding on Puppet, based on the tool's support through proof of concept and ease of adoption.
"The way that Puppet is written -- the way that it manifests -- is the most simple," Fletcher said.
Puppet provides a collaboration environment, allowing him to roll changes back and forward, and see who made them. Everyone can see the server changes in the test file.
A good DevOps tool will fully embrace this kind of auditability, according to Hendrick.
"An audit trail is absolutely critical," he said. "The more information you have, the easier and faster it is to get to the source of the problem."
Taking a calculated risk with supported open source
Open source tools are not common at Hiscox, and the company bought support through Puppet Enterprise to ensure predictable operations. Still, there are items on his wish list.
Fletcher called Puppet on Windows "immature," and said he has to run it partly on Windows and partly on Linux. Fletcher runs a Linux box just to support Puppet, and he encounters incompatibilities between Linux and Windows.
"The Puppet master [server] will probably always run on Linux," said Carl Caum, technical marketing manager at Puppet Labs, "but the agents have great support for Windows."
Code Manager, introduced in March 2015 on Puppet Enterprise, eliminates the majority of interaction Puppet administrators used to have with the Linux file system. DevOps teams can write configurations and use Code Manager to deploy them, and don't have to know much about Linux, he said. Secure Shell forays into the Puppet master on the Linux server will become fewer and further between, he added.
Hiscox's biggest problems have been with upgrades to Puppet Enterprise.
"It doesn't feel like a production-ready tool," Fletcher said.
Puppet Enterprise underwent "a lot of massive changes" over the past year, Caum said. On the agent side, the configuration management tool now has a unified agent for open source and enterprise versions. The unified agent packages all the core technology together, allowing users to pull updates straight from a public repository.
On the master side, the company switched from a proprietary upgrade script to using the Puppet tool to manage upgrades to all of the components that make up Puppet Enterprise.
"The upgrade script didn't work well for a lot of reasons. And Puppet's really good at managing upgrades," Caum said.
Beginning with the release of Puppet Enterprise 2015.2 in July, this is the default upgrade method for all Puppet services.
"We had to re-architect the services that make up Puppet Enterprise; now, that's done [with 2015.2], and we're not going to be ripping out chunks of functionality and replacing [them]," Puppet's Caum said.
The transition meant there wasn't always an easy path from an old method to a new one, and Hiscox experienced that firsthand. The aim was to make quarterly tool upgrades smooth and predictable, with little intervention from Puppet.
All this change is to be expected.
"Open source tools can be more dynamic [than proprietary products]," said ESG's Hendrick. "A lot depends on the vendor themselves," and the difference between free and supported versions is often remarkable.
Following the DevOps path
Despite these issues, using the Puppet configuration management tool for nearly one year has cut Hiscox's costs by 97% per release compared to previous tools, Fletcher said.
Fletcher is working to convince everyone in his organization that Puppet is part of a new way of working -- a way that requires buy-in from other employees.
Hendrick agrees: DevOps requires education for the IT team on what it means and what's feasible for the company, he said.
IT pros just starting out with DevOps, automation and configuration management shouldn't expect to jump into tools.
Steve Hendrickprincipal analyst, ESG
"Companies need to look at their IT environment and understand how you do things now, and how you want to do things," Hendrick said.
What changes between those two realities is where to start investing in tools. Simply interviewing the developers and operations staff gives managers an understanding of what's working and what's not -- both of which are key to decisions, he said.
For companies already following a DevOps methodology, move to cloud-native application development and deployment, Hendrick said, to gain dynamic scalability and easily accessible resources.
"You don't have to worry about spinning up VMs or containers and shutting them down. That [freedom] opens the doors for DevOps," where a lot of components run and scale independently of each other, he said. Automation-based policy is the only way to spin up and down resources at the right time, when microservices and cloud-native development generate exponential images.
"There's too much going on [for manual IT processes]," he said.
Robert Gates is a news writer for SearchDataCenter.com, and Meredith Courtemanche is the site's senior editor. Reach them via Twitter @DataCenterTT.
How to shape a DevOps-ready team
Make your DevOps foray a success
Beware the downfalls of DevOps efforts
Learn automation and configuration management with a Puppet setup