Treating infrastructure as code is the smart and modern way to deploy software in the cloud. Here you will learn what this is and why it is better. […]
As more and more companies move to the cloud, the ability to deploy and configure a physical server is becoming less and less important for the development and deployment of modern software.
In today’s complex, software-driven world, where you often neither see nor hear the computer infrastructure, the ability to deploy and manage this infrastructure with the help of declarative code instead of manual configurations or even scripts is essential for the operation of web-scale applications.
A Brief History of Infrastructure as Code
While system administrators have been using scripts to manage their infrastructure since the 1990s, the practice of handling Infrastructure as Code (IaC) didn’t catch on until the late 2000s, when engineers like Devops pioneer Andrew Clay-Shafer, chief co-founder Adam Jacob, and Puppet founder Luke Kanies started using this terminology.
In a world of distributed applications, manually customizing servers has never been scalable, and scripting had its own limitations, so the ability to automate infrastructure deployment became a central need for many first movers in the early days of the cloud.
Today, the underlying infrastructure is usually provided as code, thanks to popular early tools in this area such as Chef, Puppet, SaltStack and Ansible. But technology is developing fast, and things have evolved since then. In the following, we explain the basics of Infrastructure as Code and why it is the basis of modern software development practices today.
Infrastructure as defined by Code
In Infrastructure as Code: Dynamic Systems for the Cloud Age, Kief Morris explains that Infrastructure as Code is limited to three core practices: “Define everything as code, test and deliver everything continuously as you work, and build your system from small, loosely coupled parts.“
As a working definition, Morris offers that IaC is “an approach to infrastructure automation based on software development practices. He focuses on consistent, repeatable routines for deploying and modifying systems and configuring them“.
In practice, this usually means that Devops teams make changes to an environment description and the version of the configuration model using a well-documented language such as JSON or YAML. Once this environment is configured, changes can be made to the source, not the destination, allowing for safer and more regular changes to the infrastructure on a much larger scale.
Where Infrastructure as Code and Devops meet
As a way to automate the initial configuration and subsequent changes, Infrastructure as Code is an important part of modern Devops practices, where developers and operators have to work hand in hand to deploy software faster and more frequently. By automating and versioning infrastructure builds, IaC tools can help application developers focus on what they do best, and system administrators no longer have to deal with manual processes.
Using code to deploy and maintain the infrastructure helps to bring developers and operations specialists together at an earlier stage in the software development cycle and to anchor the discipline, clarity and repeatability of software development in operations. Since automation and collaboration are among the most important tenets of Devops practices, IaC tools are also becoming a central pivot for the effective collaboration of this team.
The benefits of Infrastructure as Code
The main advantages of handling Infrastructure as Code are the move away from manual processes and the freedom that automation offers to Devops teams. This brings some cost savings and can also increase the speed at which these teams can safely deploy changes to their applications.
Simple Thread co-founder Justin Etheredge wrote in a 2020 blog post, “Infrastructure as Code gives you the freedom to make changes without fear of putting things in an unrecoverable state. And it gives you a better understanding of how the environment came into being the way it is, which gives you more confidence to make the necessary changes.“
In his book, Morris outlines seven key advantages of IaC over traditional deployment methods. These are:
- Use of the IT infrastructure as a basis for the rapid provision of values
- Reducing the effort and risk of changes to the infrastructure
- Enabling infrastructure users to get the resources they need when they need them
- Providing common tools for development, operation and related functions
- Creation of reliable, secure and cost-efficient systems
- Making governance, security and compliance controls visible
- Improving the speed of troubleshooting and troubleshooting
The tools required for the implementation of Infrastructure as Code can be divided into two camps: configuration orchestration and configuration management.
The most popular orchestration tools are AWS CloudFormation, Google Cloud Deployment Manager, HashiCorp Terraform, Microsoft Azure Resource Manager and Pulumi, which allow developers to automate the deployment of infrastructure in different ways.
As for configuration management, third-party tools such as Ansible, Chef, Puppet and SaltStack are still popular methods for configuring, storing and automating builds of virtual server environments, while many developers use Docker for their container images.
Many of these tools can be used in tandem, as Ansible, Chef, Puppet and SaltStack focus on managing configurations on an already existing infrastructure, while provisioning tools such as Terraform abstract this infrastructure layer.
Getting Started with Infrastructure as Code
The adoption of Infrastructure as Code is usually part of a broader organizational shift to the cloud and Devops practices. While this transition may sound intimidating, implementing Infrastructure as Code is the key to modernizing your approach to software creation and execution.
“Sometimes it can take a little longer to make changes with Infrastructure as Code,” Etheredge warns, “but this is one of the situations where you have to slow down to get faster. If you are careful when making changes through your scripts, you will undoubtedly save countless hours in the event of a failure or troubleshooting. In addition, you have much more confidence in your changes, because you can test the changes in a test environment, instead of doing the update directly in the production environment on the off chance that you are lucky. Even in small environments, this can pay off enormously.
Or, as Morris wrote, “Automating your infrastructure involves work, especially if you learn how to do it. But when you do, it helps you to make changes, including the construction of the system in general.
*Scott Carey is the group editor for IDG UK’s corporate titles and writes mainly for InfoWorld.