DevOps might have been the most influential trend in software development for the past few years. There are currently over 11,000 DevOps positions offered on Indeed in the US and 74 percent of organizations have already adopted DevOps, among which are Amazon, Facebook, Netflix, Walmart, NASA, and more.
One of the main DevOps principles is automating as many things as possible, which also includes automating the infrastructure. Without the approach commonly called Infrastructure as Code (IaC), you can’t adhere to the DevOps philosophy fully.
So let’s review what IaC is, what benefits it brings, and, of course, how to choose the right software for it.
What is Infrastructure as Code (IaC)?
Infrastructure as Code (IaC) is the process of managing your IT infrastructure using automatic scripts instead of manually. One of the crucial elements of the DevOps software development approach, it allows you to fully automate deployment and configuration, thus making continuous delivery possible.
Infrastructure on the whole is a combination of components required to support the operations of your application. It consists of hardware such as servers, data centers, desktop computers and software including operating systems, web servers, etc. Traditionally, an organization installs and manages its infrastructure physically, on-premises. But today, a de facto method to host infrastructure is in the cloud via providers such as AWS, Azure, and Google Cloud.
Cloud computing allows us to use external computing resources through virtualization, which connects distant physical servers and makes them accessible via the internet. With cloud, the development cycle is dramatically shorter and more applications are being released every day, so it becomes difficult to scale the infrastructure up and down, which remains a manual process. Infrastructure as Code can help with that.
How does Infrastructure as Code work?
Without IaC, the team would individually configure the infrastructure (servers, databases, load balancers, containers, etc.) for each deployment. Over time, environments that were intended to be identical, become inconsistent (they are often called “snowflakes”), which makes them harder to configure and subsequently slows down deployments.
So, IaC uses software tools to automate administrative tasks by describing infrastructure in code.
It’s implemented like this:
- The team writes infrastructure configurations in a required programming language.
- The code files are sent to a code repository.
- An IaC tool runs the code and performs the required activities.
Benefits of Infrastructure as Code
We’ve already briefly mentioned why IaC is the most advanced method to manage your infrastructure today. But what exactly does it bring to the table?
Reduced costs. Cloud computing by itself is more cost-effective since you don’t have to spend money on hardware and people to maintain it. By automating with IoC, you also save on infrastructure costs since the effort to administer it decreases and your team gets to focus on more important tasks that bring your business value. Besides, you only pay for the resources you’re using.
Consistency. As we already mentioned, manual deployment introduces many inconsistencies and variations. When you’re using a declarative method (more on that later), IaC avoids so-called configuration or environment drift by ensuring that deployments are repeatable and setting up the same configuration every time.
Version control. Under IaC, infrastructure configurations are put into a code file that’s easy to edit and distribute. As any other code, it can be checked into source control, versioned, and reviewed along with your application source code using existing practices. The infrastructure code can also be integrated directly with CI/CD platforms to automate deployments.
If you like the idea of adopting Infrastructure as Code, the next thing for you to do is choose an appropriate tool. In the following section, we’ll talk about some things to consider.
There are many platforms to choose from and the choice will greatly depend on your decisions about the following topics.
Declarative vs imperative approach
There are two approaches to automating infrastructure: declarative and imperative.
In a declarative approach, you only need to define the desired final condition of the infrastructure without going into detail on how it should be achieved, allowing the platform to handle it by itself. It’s the dominant method because it requires less knowledge on the user’s part and it’s idempotent – it always produces the same result. This is done via a declarative language such as SQL, YAML, or JSON.
In an imperative (procedural) approach, you must define specific step-by-step commands to achieve the required configuration. Here, you can be very detailed and create complex configurations, having more control over the task. But you do need a high level of skill to write those commands with languages like Java, Ruby, or Python.
There’s no right or wrong method here, but in general, if you’re building a large infrastructure, you might prefer the automation the declarative approach provides. But if you’re planning to start with a few scripts, the imperative approach will work fine.
Provisioning vs configuration management
Typically, IaC tools are divided into the ones that do configuration management and the provisioning tools. They are both steps of the deployment process, but there are differences.
Provisioning is the process of setting up an IT infrastructure: virtual machines, databases, access to resources, and making them available to the users. The configuration job is then done by a different tool.
Configuration management comes after provisioning and it means installing software, configuring servers’ desired state and maintaining them.
Some IaC tools can do both, but one is typically more equipped for a specific task than the other.
Mutable vs immutable infrastructure
Tools can also differ by what type of infrastructure they’re building: mutable or immutable. Shifting from one to another is costly and heavy on operations, so carefully consider your needs.
A mutable infrastructure can be changed to fit business needs. You can easily introduce updates to the existing version, apply patches, and scale. While this may be handy, each upgrade compromises your operation security. Besides, this may negate one of IoC purposes – consistency.
An immutable infrastructure can’t be changed once deployed. If you want to make alterations to it, you have to replace it with a new version. Since versions are independent, you can easily roll back, track mistakes, and enjoy consistency and predictability.
Immutable infrastructures are considered a preferred method since it actually delivers on all the benefits of IaC.
All things considered, let’s review some popular IaC tools.
We’ve gathered five most popular platforms that you will encounter in your own research, compared them and explained why you might prefer one over the other.
Terraform – provisioning for any cloud with a unique language
An open-source tool, Terraform takes a declarative approach and uses its own language Hashicorp Configuration Language (HCL). HCL is based on Go and is considered one of the easiest languages to pick up for IaC. Terraform also has a CDK that allows using Typescript, Python, Java, C#, and Go.
Any cloud provider supported. With Terraform, you can use the same configuration for multiple cloud providers. And since many organizations today opt for the hybrid cloud model, Terraform can easily be called the most popular IaC tool.
The core Terraform workflow
Source: Terraform Docs
Provisioning tool. Terraform is capable of both provisioning and configuration management, but it’s inherently a provisioning tool that uses cloud provider APIs to manage accesses depending on required resources. And since it easily handles the orchestration of new infrastructures, it’s more equipped to build immutable infrastructures, where you have to replace them fully to make changes.
State management. Terraform uses state files to manage infrastructure resources and track changes. State files record everything Terraform builds, so you can easily refer to them.
Commercial version. Terraform has paid editions, though they provide pricing after contacting. Generally, commercial editions offer better support and extra features like audit logs and team management.
Often considered an obvious choice for an IaC tool, Terraform is popular among larger organizations that can support the learning process of its unique language.
AWS CloudFormation – provisioning for AWS
CloudFormation is an AWS service offered for free. It uses JSON and YAML for its declarative approach. It also has a CDK to support provisioning in TypeScript, Python, Java, .NET, and Go.
Stacks. To manage states CloudFormation uses the concept of stacks – collections of AWS resources, which basically allows for calling templates from other templates. Templates can be reused and replicated in multiple environments.
AWS support. CloudFormation covers services and features provided by AWS. Since it has a custom resources feature, technically you can use CloudFormation to provision infrastructures on other clouds. But it’s certainly not as easy.
How AWS CloudFormation works
For companies mainly working with AWS resources, CloudFormation is a solid provisioning tool.
Ansible – configuration management with simple syntax
Acquired by RedHat in 2015, Ansible is an open-source configuration management tool, written in Python and supporting any language that can return JSON, so it’s rather easy to learn. Ansible uses agentless architecture, meaning that it collects data from computers without installing software (agent) that would push that data on each computer from which data is needed. Instead, it relies on an SSH (Secret Shell) connection to access client systems. Agentless architecture is fairly easy to set up.
How Ansible works
Configuration management. Ansible is typically used in combination with a provisioning solution like Terraform. It uses an imperative approach, where you define infrastructure in YAML. Ansible has blueprints with prewritten code and ad-hoc commands called Ansible Playbooks.
Code repository. Ansible has a repository of modules built by the community called Ansible Galaxy. Currently, there are almost 3,000 modules allowing you to easily automate your project.
Commercial version. Ansible has a commercial tooling called Ansible Automation Platform (formerly Ansible Tower) with pricing being based on the number of nodes. You can review two editions of it as well as contact Ansible for pricing here. There’s also a free 60 days trial.
Ansible is a great traditional configuration management tool with a simple syntax that simplifies coding. Also, keep in mind that it’s a rather young tool with poor community support.
Puppet – mature and loved configuration management tool
Released back in 2005, Puppet is a configuration management tool based on a server-agent architecture. It uses a declarative approach and its own language called PuppetDSL. It’s a server/client-based tool that refreshes the state using a catalog. It has robust metadata management and takes advantage of a system called Hiera to store configuration data. You can write Hieradata in YAML.
How the Puppet components fit together
Source: Puppet Docs
Configuration management. Puppet is a configuration management tool that relies on instruments like Terraform to prepare the ground.
Code repository. Puppet has a code repository called Puppet Forge containing community-built modules similar to Ansible Galaxy. But due to its age and community support, it’s much larger totalling 7000+ modules.
Commercial version. There’s a Puppet Enterprise offering which you can use on 10 nodes for free. Pricing information is available upon request.
Puppet is considered a reliable option for longer-term deployments. Its maturity and community support are some of the best on the market, though you have to consider the time it will take to adopt its unique language.
Chef – robust configuration management on Ruby
Chef is another veteran on the market of configuration management tools, supporting all popular cloud platforms. Chef uses a declarative approach and Ruby for writing scripts, which is not the easiest language to learn if you don’t have the skills already. Similar to Puppet, it also runs on master-agent architecture, where you install an agent on every distributed device and use a master software to be a central hub managing those agents.
Configuration management. While Ansible calls its configuration files Playbooks, Chef uses cooking terminology and calls them Cookbooks. While Playbooks are easier to understand, Cookbooks are more robust and allow for performing more complex tasks. Chef also has a component called Workstation that stores your configurations. To communicate with the infrastructure, you can use the Knife command tool as well.
The map of Chef components
Source: Chef Docs
Commercial version. There are a few choices for the Chef Enterprise subscription that gives access to certified profiles for compliance purposes, 24/7 support, and expert help. Per usual, you can contact them directly for pricing details.
Chef is a flexible solution for programmers comfortable with Ruby that seek greater flexibility and require a tool for complex tasks.
Challenges of Infrastructure as Code
Being a fairly new way to run an infrastructure, IoC presents some challenges, mainly in terms of adoption. Let’s review them.
Just as IaC introduces more optimized processes, it should also be better controlled. Conventional security tools used for your current configuration and provisioning tasks might not handle the increased dynamics of IaC.
New cloud features are constantly being introduced but you might not access them immediately since IaC vendors need time to upgrade them. So you’re very much dependent on their update cycle.
Steep learning curve and adoption process
Implementing IoC correctly will take preparation in terms of learning the new technology, coordination between teams, understanding how to approach security and compliance, and hiring new staff. You will need to invest in DevOps professionals, infrastructure engineers, or the education of your existing employees.Perhaps you would choose to outsource IaC in the early stages. You also need to set up an audit process as you’re learning the ropes.
Regardless, IaC is becoming a norm for many organizations, so the sooner you migrate your infrastructure from manual to automated, the better.