What is infrastructure as code? A big step up from server scripting

IAC is more powerful than scripting and almost a necessity in the era of cloud computing to manage all your servers

What is infrastructure as code (IAC)? A big step up from scripting
Getty Images

If you have ever had to provision and configure a server, you know the pain it can bring. Take the process of configuring hardware connections, the software stack, and their interdependencies, and then multiply that across however many servers you are deploying—you are talking days and days of tedium.

Scripts are often the solution to performing repetitive tasks, but even there, scripting has its limitations, because scripts are mostly linear if-then statements that don’t have the strength and capabilities of application code.

This is where infrastructure as code (IAC) comes in. IAC—sometimes referred to as programmable or statically defined infrastructure (SDI)—is a type of IT setup to automatically manage and provision the technology stack from hardware through the software layers, with greater control than scripting and far more automation.

Infrastructure as code (IAC) defined

“The simplest definition of IAC is being able to treat your infrastructure as if it’s software,” says Nigel Kersten, vice president of architecture at Puppet, an open source configuration management provider. “Things like virtual APIs, IaaS, provisioning cloud resources, and programmatically talking to hardware to kick off provisioning process are all IAC.”

IAC lets engineers use “code”—generally a high-level scripting or programming language—to program the infrastructure setup for any given application or service. This lets any authorized user execute predefined, repeatable, known good processes to build and rebuild IT infrastructure automatically, the same way every time, at machine speed.

“This enables software developers and production engineers to use code to not just build an application, but also to build the systems that the application will run on,” says Andi Mann, chief technology advocate at Splunk, a management and compliance monitoring software provider.

Scripts don’t work well for infrastructure and configuration management for several reasons:

  • Scripts are limited in what they can do. They are pretty much a series of if-then statements and don’t have the versatility of actual code.
  • Script writing tends to be more loose and informal than a structured coding project, where you have checkin/checkout, revisions and rollback, testing, and deployment.
  • Scripts lack something called idempotence. Idempotence means that if you run a script multiple times, you get the same results each and every time. Most of the scripts can’t make that promise.

In addition to setting up a machine and establishing connections, IAC handles the establishment of credentials. When a new machine comes online, it has its master credentials, which are turned off and switched to the company’s trusted credentials, like Active Directory.

In a legacy approach, a person has to log in with master credentials to add private ones, disable master credentials, and log out. In an IAC system, a utility can talk to the trusted system, which is notified a new system is available and goes through the whole process of establishing the trusted credentials automatically.

Configuration management vs. infrastructure as code (IAC)

You may be familiar with some early configuration management products that have been updated to include IAC. These include Puppet, Chef, SaltStack, and CFengine. All let you manage the more automated provisioning of code onto shared cloud computing platforms. But IAC is the next step up.

It can be a little confusing because different vendors have different terms for the same component or element. For example, Puppet calls its IAC scripts manifests, while Chef calls them recipesand cookbooks. Both do the same thing despite their different names: They store the code instructions.

The advantages of infrastructure as code (IAC)

IAC is useful for any organization and any IT team but it best suited for organizations looking to take advantage of new, more responsive approaches to IT, like cloud computing, agile development, and devops.

Because it involves using developer methodologies and disciplines, IAC tends to promote better quality code than scripting, its main alternative. Scripts are usually written by whomever has the time, and so they are not always maintained.

IAC code goes through the same cycle of development, testing, quality assurance, staging, and release as application code. With greater rigor and quality control during development, IAC provides predefined “known good” processes for provisioning, desired state controls to revert manual or out-of-band changes, etc., IAC helps reduce the number of problems caused by misconfigured infrastructure in production and can roll back to a “known good” state if there is a problem in the code.

However, you do not need to be engaged in these new approaches to benefit from IAC, because it provides clear benefits even for relatively simple on-premises server deployments as well. IAC’s benefit is in getting hardware deployed quickly on-premises, in the cloud, and in the fast-growing edge computing—for too many IT shops, that approach is still a new concept.

“Too many processes are stuck in the ’90s. Customers can’t embrace cloud-native development because their infrastructure doesn’t support it. We have to teach customers the basics of SDI. We tell them that it’s basically a very natural extension of statically defined infrastructure. A lot of customers don’t even have that,” says Roman Shaposhnik, vice president of products and strategy at Zededa, a virtualization and orchestration software developer for edge computing. “The issue for customers is ‘How do I reliably introduce change?’ In development, you do it with unit testing, pass or fail. We have nothing like that today in traditional SDI. AIC lets you leverage some of these techniques.”

The most notable benefits of IAC compared to prior methods is the speed and agility in not only provisioning and deploying your hardware but in maintaining it as well. By automating the handling of routine processes like building server connections to storage, switches, and so forth, the IT team is freed up for other tasks.

Hardware configuration is still lagging compared to other technologies, so the benefit of adopting IAC is pronounced. Rob Hirschfeld, CEO of RackN, a startup doing bare-metal cloud configuration automation, notes that the major hardware vendors haven’t put a lot of value in operations. “We pitch IAC as keeping your infrastructure more dynamic and fluid and constantly updated and dynamic and patched to the latest state. Which you would think they would want, but people don’t patch their servers unless they have to,” he says.

The alternative method for many data centers is to have people follow printed instructions, Hirschfeld says. “Most data centers are still like this. You have a person making sure systems are configured correct running vendor tools or their own homegrown script. They piece it together and turn it over to another automation tool like Ansible to finish it,” he says.

Puppet’s Kersten argues that IAC is even more important for moving to the cloud. “Taking an IAC approach is optional in an on-prem environment but mandatory in a cloud environment because you have to treat everything as software since there is no hardware for you to get to,” he says. “As long as you build software and wonder how it is deployed, IAC is relevant.”

That becomes especially true in multicloud environment, says Zededa’s Shaposhnik. “Being on a single cloud is good if you are a small company, but a big company has to be multicloud. All these clouds have different software-defined APIs. IAC is the best way to abstract yourself away from the underlying heterogeneity of the underlying clouds,” he said.

Infrastructure-as-code (IAC) tools

IAC tools fall under two umbrellas: configuration orchestration and configuration management. Many products on the market, whether commercial or open source, offer both functions.

Configuration-orchestration tools include AWS CloudFormation and Terraform. Such tools are designed to automate the deployment of servers and other infrastructure (think an updated version of PXE).

Configuration-management tools like Chef and Puppet are designed to help configure the software and systems on a provisioned system.

When selecting a tool, you should consider the target deployment. For example, AWS CloudFormation is designed to provision and manage infrastructure on Amazon Web Services only. Which makes sense—why would AWS support Google Cloud Platform? Of course, that’s not always the case: Red Hat’s Ansible runs on a variety of platforms, not just Red Hat Enterprise Linux.

Third-party tools like Puppet and Chef work with on-premises servers and multiple cloud providers’ infrastructure-as-a-service (IaaS) offerings. Cloud-focused Terraform is cloud-agnostic, letting you automate infrastructure stacks from multiple cloud service providers simultaneously and integrate other third-party services.

While each tool has its own domain-specific language (DSL), the DSL is usually based on YAML and/or JSON. For example, Terraform uses its own DSL called Hashicorp Configuration Language (HCL), which is based on JSON. AWS CloudFormation templates can be created with both YAML and JSON. Chef uses the Ruby language, as does Puppet.

Because most developers learn by studying the work of others, many IAC vendors provide sample patterns/recipes/blueprints in their own repository. For example, Puppet has a repository called Puppet Forge to offer samples of IAC code and lets developers share their own work. It has things like how to configure and manage a SQL Server database or Apache server among its collections.

Copyright © 2019 IDG Communications, Inc.