Infrastructure as Code (IaC) uses a high-level descriptive coding language to automate the provisioning of IT infrastructure. This automation eliminates the need for developers to manually provision and manage servers, operating systems, database connections, storage, and other infrastructure elements every time they want to develop, test, or deploy a software application.
In an era when it’s not uncommon for an enterprise to deploy hundreds of applications into production every day—and when infrastructure is constantly being spun up, torn down, and scaled up and down in response to developer and user demands—it’s essential for an organization to automate infrastructure in order to control costs, reduce risks, and respond with speed to new business opportunities and competitive threats. IaC makes this automation possible.
IaC is also an essential DevOps practice, indispensable to a competitively paced software delivery lifecycle. It enables DevOps teams rapidly create and version infrastructure in the same way they version source code and to track these versions so as to avoid inconsistency among IT environments that can lead to serious issues during deployment.
Sai Vennam takes a closer look at IaC in the following video, “What is Infrastructure as Code?”:
Provisioning traditional IT is a time-consuming and costly process, requiring the physical setup of the hardware, installation and configuration of operating system software, and connection to middleware, networks, storage, etc. by expert personnel.
Virtualization and cloud native development eliminate the problem of physical hardware management, enabling developers to provision their own virtual servers or containers on demand. But, provisioning virtualized infrastructure still distracts developers’ focus from coding, still requires them to repeat provisioning work for every new deployment, and doesn’t provide an easy way to track environment changes and prevent inconsistencies that impact deployments.
Infrastructure as Code (IaC) goes the final step of enabling developers to effectively ‘order up’ fully documented, versioned infrastructure by executing a script. The benefits are exactly what you might imagine:
An important decision to make when automating infrastructure with Infrastructure as Code (IaC) and when choosing an IaC solution is whether to establish mutable or immutable infrastructure.
Mutable infrastructure is infrastructure that can be modified or updated after it is originally provisioned. Mutable infrastructure gives development teams the flexibility to make ad hoc server customizations to, say, more closely fit development or application requirements or respond to an emergent security issue. But, it also undermines a key IaC benefit—the ability to maintain consistency between deployments or within versions—and can make infrastructure version tracking much more difficult.
For these reasons, most IaC is implemented as immutable infrastructure—infrastructure that cannot be modified once originally provisioned. If immutable infrastructure needs to be changed, it has to be replaced with new infrastructure. Because new infrastructure can be spun up quickly on the cloud—particularly with IaC—immutable infrastructure is much more feasible and practical than it sounds.
Immutable infrastructure takes IaC to a next logical step, essentially hardening IaC to further ensure the benefits it offers. It all but eliminates configuration drift and makes it even easier to maintain consistency between test and deployment environment. It also makes it easier to maintain and track infrastructure versions and to confidently roll back to any version when necessary.
When choosing an IaC solution, it’s also important to understand the difference between a declarative or an imperative approach to infrastructure automation.
In most organizations, the declarative approach—also known as the functional approach—is the best fit. In the declarative approach, you specify the desired final state of the infrastructure you want to provision and the IaC software handles the rest—spinning up the virtual machine (VM) or container, installing and configuring the necessary software, resolving system and software interdependencies, and managing versioning. The chief downside of the declarative approach is that it typically requires a skilled administrator to set up and manage, and these administrators often specialize in their preferred solution.
In the imperative approach—also known as the procedural approach—the solution helps you prepare automation scripts that provision your infrastructure one specific step at a time. While this can be more work to manage as you scale, it can be easier for existing administrative staff to understand and can leverage configuration scripts you already have in place.
Choosing a declarative or imperative approach is analogous to using a GPS or following turn-by-turn instructions. With a GPS, you enter an address and the GPS does the rest, plotting the fastest route and avoiding traffic for you—but you probably need an expert to tell you why it made the choices it made. The turn-by-turn instructions are based on personal experience; the provider knows the route and why he/she chose it, but if you encounter obstacles or want to optimize the route, you have to call for help or do the work yourself.
While many open-source IaC tools are available, the most commonly adopted tools are Ansible and Terraform:
Ansible (link resides outside ibm.com) is an open source community project sponsored by Red Hat that is designed to help organizations automate provisioning, configuration management, and application deployment. A declarative automation tool, Ansible lets you create ‘playbooks’ (written in the YAML configuration language) to specify the desired state for your infrastructure and then does the provisioning for you. Ansible is a popular choice for automating provisioning of Docker containers and Kubernetes deployments.
Terraform is another declarative provisioning and infrastructure orchestration tool that lets engineers automate provisioning of all aspects of their enterprise cloud-based and on-premises infrastructure.
Terraform works with all the leading cloud providers and lets you automate the build-out of resources across multiple providers in parallel, regardless of where physical servers, DNS servers, or databases reside. It can also provision applications written in any language.
Unlike Ansible, Terraform does not offer configuration management capabilities, but it works hand-in-hand with configuration management tools (e.g., Cloud Formation) to automatically provision infrastructure in the state described by configuration files and to automatically change update provisioning when necessary in response to configuration changes.
For a deeper dive into choosing an IaC tool, see “Infrastructure as Code: Chef, Ansible, Puppet, or Terraform?”
IBM’s IaC capabilities, which feature customizable and shareable templates, can lay the groundwork for modernizing applications, no matter where you are on your journey to cloud.
Take the next step:
Get started with an IBM Cloud account today.
Build, modernize and manage applications securely across any cloud with confidence
Build, deploy and manage security-rich cloud-native applications across multiple devices, environments and clouds with DevOps best practices