Modern Stack
Maksim Kabakou - Fotolia
Benefits of infrastructure as code range from speed to scaling
Provisioning large numbers of servers takes time. One of infrastructure as code's benefits is that once you declare a desired state, code maintains that environment with ease.
While there are differing ideas about what exactly constitutes infrastructure as code, experts tend to agree that IaC holds potential transformative power.
The central concept is built around automation. "With IaC, you can automate more of the infrastructure," said Jay Lyman, an analyst at 451 Research. Companies such as Chef, Puppet and Ansible, he noted, have been talking about this kind of IT automation and using declarative language for quite a while.
Although adoption is hard to measure, Lyman believes many organizations recognize the benefits of infrastructure as code, at least in concept.
Tools that aim to automate the management of large-scale environments through declarative or desired state rules, such as HashiCorp Terraform or AWS CloudFormation, are also part of the IaC spectrum.
That declarative concept refers to instructions needed to get an environment to meet certain conditions. It is often contrasted with the imperative approach, which provides specific definitions for the environment.
Among the benefits of infrastructure as code that drive its adoption, the first is the need to better serve developers, Lyman said. "Central IT teams are under a lot of pressure to keep up with the developers -- who are moving faster and faster -- and to work more closely with them," he said. Companies can't afford to keep developers waiting for months for the environments they need, which is why companies try to speed up configuration and provisioning. They use automation to provide test/dev environments that developers and line-of-business teams need, Lyman said.
Infrastructure as code's capabilities "play into hybrid cloud and multi-cloud, too," he said.
Organizations want to run apps where they are best suited, based on cost and performance data, weighing data sovereignty concerns and other factors, Lyman said. Even though public cloud gets most of the attention, Lyman said, that's not the whole story.
"People sometimes still want to run their own cloud because of privacy concerns. And they also write a lot of applications for on premises, so applications must span across all of those," he said.
Specifications are key
IT teams feel a growing pressure to be flexible with how systems are configured, but that malleability isn't easy to achieve. The automation at the heart of infrastructure as code, therefore, appeals to those being told to make infrastructure less rigid, Lyman said. "Infrastructure as code makes it more flexible."
Gartner analyst Paul Delory sees a key distinction between thinking about systems in terms of behavior and in terms of specifications -- similar to the differences between declarative and imperative. With a traditional behavior-oriented mindset, whether the focus is servers, switches or something else entirely, Delory said, "You need to manage that behavior through scripts and perhaps some degree of automation. But it tends to be very procedural and very workflow-oriented."
That is because the goal is to control the behavior of devices, whether physical or virtual. The other, and probably better option, is to provide a set of specifications, he said.
"You want to go to a server and say, this is what I want, and rather than having a series of commands that say, do this and do that, you have a specification expressed programmatically, which describes the desired state of the system. And you hand this to the server and say, this is what I want you to look like," he said.
Once the specification is in place, an automation tool can read that specification, implement what it describes and then enforce that. This ability to manage specifications -- as opposed to just behaviors -- is an important benefit of infrastructure as code, Delory said.
Delory believes this is where most people are aiming toward; trying to go from scripts and a runbook-based automation to specifications. However, that thinking process is often conflated with a discussion of declarative versus imperative IaC.
A lot of things get better once you're managing specifications, Delory said, and it is a huge enabler for DevOps. Tools like Puppet or Ansible are starting to work fluidly across both declarative and imperative modes. "For anyone, I think specifications is the way to go," Delory said.
Why? For one thing, developers probably can't write a script to configure a network switch and probably don't have the infrastructure-specific knowledge to understand what needs to be done. Developers can help specify what an app needs, Delory said. With infrastructure as code, if you have a description of the desired state of a system, perhaps in the form of a Puppet manifest or an Ansible playbook, that is something that the developer can generate and then incorporate in an application, Delory said.
Or perhaps the developer can write a description using a higher-level language format, like YAML, he added. All of those benefits of infrastructure as code set IT teams up for DevOps.
"Dev is then responsible for scripts and ops for maintaining infrastructure, so now you have your division of responsibility," Delory said.
While IaC is often discussed in the same context as DevOps, "one doesn't require the other," said Justin Nemmers, general manager for Ansible. Still, many organizations committed to DevOps approach infrastructure as code from this perspective, he said.
"People want to be able to more effectively track the configuration of infrastructure, just as they do with app code," Nemmers said. A bonus is that anytime you have something in code, as you do with infrastructure as code, repeatability is clearly within reach. For example, he said, a database and all the configuration information around that -- versions, settings and more -- can constitute a master version. "This is helpful for organizations with large operations, where there are benefits to being able to repeat something," he said.
HashiCorp CTO Armon Dadgar agreed: "Now we have moved from something in the head of someone to something you can inspect; you can open a file and say this is the exact process."
The second aspect, Dadgar said, is that you can put it in a version control system like GitHub, where you can see how the changes were made, who made the changes and the incremental steps. "And now we can automate it. I can put it behind an API and say, 'Here's your new VM,'" Dadgar said. "IaC gives us the ability to do that at larger scale," he added.
With traditional manual methods, an organization might need 1,000 job tickets to provision 1,000 VMs. "By contrast, IaC can automate the deployment of thousands of VMs at a time, potentially cutting deployment from months to minutes," Dadgar said.
What does that mean for organizations?
It is an enormous story around agility and elimination of error as central benefits of infrastructure as code. With 1,000 manual iterations, maybe 100 will have a problem, Dadgar said, versus the 1,000 pristine copies you get with IaC.
Not a passing fad
"I compare IaC adoption to what happened in the dev community with version control 15 to 20 years ago," Dadgar said. Version control adoption required developers to be retrained. While infrastructure as code is increasingly considered best practice, it may also require operations professionals to learn new skills.
"In five to 10 years, we will look back in amazement that anyone used to provision manually," Dadgar said.
There's no need to implement code-based infrastructure provisioning right away with all your projects, Lyman said, especially at the start. "It is newer apps and cloud data apps and smaller apps that will all make the most sense," he said.
