The main aim of DevOps teams is to provide efficiency and security at every stage of software development. In our series of articles we introduced a few DevOps tools dedicated to containers and container orchestration. Now let’s focus on IaC tools and their role in the software development lifecycle.
What’s IaC?
IaC stands for Infrastructure as Code - a way of infrastructure management in a descriptive way of managing infrastructure in code with use of source control, in similar fashion as the DevOps and product team handles their code. Simply put, Infrastructure as Code (IaC) is the managing and provisioning of infrastructure through code instead of through manual processes. Thanks to IaC configuration files are created. They contain infrastructure specifications that help with edition and sitribution of the configurations. It also ensures that you provision the same environment every time. By codifying and documenting your configuration specifications, IaC aids configuration management and helps you to avoid undocumented, ad-hoc configuration changes.
Infrastructure as Code and automation are closely related, but are two different things. Infrastructure as code keeps the configuration or state of the data center infrastructure in a specific way. Automation stand for the process of automatically pushing that state into the infrastructure.
The value of IaC is based on 3 pillars: price, speed and risk reduction. The reduction in costs refers not only to the financial component, but also to the amount of time spent on routine operations. The principles of IaC allow you not to focus on the routine, but to deal with more important tasks. Infrastructure automation makes better use of existing resources. Automation also minimizes the risk of human error. All of this is part of the DevOps culture.
There are two approaches to Iac - Declarative vs Imperative
- Declarative: This IaC approach keeps a list of the current state of your objects which makes taking down the infrastructure simpler to manage
- Imperative: Instead of the former, this approach defines specific commands needed to achieve the desired configuration and those commands then need to be executed in the correct order.
Many IaC tools use a declarative approach and will automatically provision the desired infrastructure. If you make changes to the desired state, a declarative IaC tool will apply those changes for you. An imperative tool will require you to figure out how those changes should be applied.
IaC tools are often able to operate in both approaches, but tend to prefer 1 approach over the other. Before proceeding further its worth it to explain the concept of state as this is the core and part of the most important concepts of IaC.
Concept of states in IaC
The state is simply the details / record of all configs made to your infrastructure. Every time you or a member of your team makes a change to your infrastructure using IaC, this is recorded in a state file. Every IaC has a different way of handling state / state files but most importantly, they hold a list of your system objects and the current representation in the real world. Ideally, a state file is suppose to show the current config of our infra and that is why it is important to have it up to date and in sync with out infra. Working with state & state files is one of the most important skills to master when choosing IaC.
Benefits of IaC
Using IaC to provision our infrastructure comes with lots of benefits which includes the below:
- More Productivity via Automation: Administrators and operators no longer must perform manual configuration steps for data centre infrastructure changes. By applying some level of automation, teams can save plenty of time and effort for quick provisioning and scaling of their infrastructure.
- Reliability: Teams that don’t utilise Infrastructure as Code need to properly maintain the settings of different deployment environments. However, when resources start to eventually increase due to the fact that every environment makes a one-of-a-kind configuration that can’t be automatically reproduced, it gets exceedingly difficult to deal with it manually. As a result, might appear some divergences between environments, which leads to deployment problems. In fact, this problem was directly connected with introducing IaC.
- Improved Reusability: Older infrastructers didn’t provide the reusing of codified elements across various environments. That is why teams had to create a new one over and over. Infrastructure as Code eliminates this problem as it enables you to utilise the same resource many times.
- Price Optimisation: Finally, it’s a no-brainer that setting up each IT environment manually can be rather costly. You need not only dedicated teams of engineers who are responsible for setting up the hardware and software: there also arises the need for supervisors and your own data centres, which dramatically increases costs. By using Infrastructure as Code, you have a centrally managed tool that sets up an environment. As a result, you pay only for the resources.
Drawbacks of IaC
- Configuration Mismatch: This is often referred to as configuration drift and happens when there are differences between the infrastructure as code configuration and the actual infrastructure, such as manual or external updates to security patches. This can lead to non-compliance or even service failure over time. This can lead to unexpected behaviour and can be difficult to debug. The solution to this is to use infrastructure as code tooling that can help identify and prevent configuration drift.
- Managing RBAC: Due to the fact that infrastructure as code often needs to be stored in a central repository such as GitHub, without proper RBAC(Role-Based Access Control) management, this can lead to security issues.
- Complexity, Logic, Conventions, and Lack of Skills: One of the challenges of infrastructure as code is that it can be complex to define infrastructure configurations. This complexity can make it difficult for businesses to understand and maintain their infrastructure as code.
On the other hand, defining Infrastructure as Code requires following some strict standards, which makes them more complex. In addition, skill staffers can be challenging to find. Businesses that do not have experience with IaC may not even know where to start and how to interview. Enterprises can remedy this by investing in IaC training and implementing continuous training programs for their staff.
- When execution fails somewhere, it may not be as easy to restart from the exact same point, and re-executing from scratch may take a long time.
- Tooling Gaps and Feature Lag: One of the challenges of infrastructure as code is that there are often tooling gaps and feature lag. This means that there are often infrastructure as code tools that do not have all the features that businesses need. Infrastructure as code tooling can lag in terms of new features and functionality. Therefore, you have no choice but to wait for the vendor to provide coverage; otherwise, you have to extend the functionality yourself or introduce new dependencies. The solution to this is investing in infrastructure as code tooling that is constantly updated and improved.
Overview of the most used IaC tools
- Terraform: Another product created by Hashicorp is Terraform - an open-source infrastructure as code tool that’s used in DevOps practices to define cloud and on-prem infrastructure resources to version, reuse, and share them. Terraform workflow consists of three stages:
Write - defining provision resources that might be based in various clouds or services
Plan - creating the plan of infrastructure provisioning with a description and what will happen to the other infrastructure
Apply - after developer’s accept Terraform starts to implement suggested operations in the correct order and with respect to infrastructure resources’ dependencies.
What’s more, Terraform creates and manages provision resources via API which means that it can work with many platforms and services that also use API.
- Terragrunt: Terragrunt was produced in 2016 by Gruntwork and is called “a thin wrapper”, which means extra IaC tools to supplement Terraform. It’s used for managing remote state, working with multiple modules and reducing repetitions. Everything to keep the TerraForm code DRY (Don’t Repeat Yourself).
- Pulumi: Similar to Terraform, Pulumi is an open source IaC tool to create, deploy, and manage infrastructure. It uses the most popular programming languages to simplify the processes of provisioning cloud infrastructure and managing cloud resources. Presented in 2017 Pulumi was a kind of revolution in DevOps practices and the approach to IaC tools. Instead of domain-specific languages, it enables the team to use real programming languages in cloud-native infrastructure provisioning. It means that a user doesn’t have to learn a new language only for infrastructure management.
- CloudFormation: CloudFormation is an AWS infrastructure as code tool for creation, provision and management of collections of Amazon cloud service and other resources in a textfile. Just like Pulumi, the main aim of CloudFormation is simplifying the mentioned processes. It collects AWS resources to tight them together into infrastructure stacks. Thanks to them, users can delete or modify dependencies in bulk. When they delete the application, CloudFormation will also delete the stack. When they manage the stack state, provision resources can be also modified, but without a total rebuild.
- CDK: CDK is another tool from the team at AWS that is open-source. CDK is a development framework that’s allows you to define your cloud application resources while using familiar programming languages. AWS CDK uses the familiarity and expressive power of programming languages for modeling your applications. It provides high-level components called constructs that preconfigure cloud resources with proven defaults, so you can build cloud applications with ease.
Choosing an IaC tool for your project
With an immense choice of tools in existence, it’s absolutely impossible to give one all-purpose solution. However, when contemplating your alternatives, evaluate these simple facts, and you’ll get the answers.
- Is your solution simple and particularly serverless — AWS CloudFormation to help you (notably AWS SAM).
- Is AWS your final choice and will you remain on AWS — CloudFormation / CDK.
- Do you want to vertically distribute best practices and orchestration — Terraform / CDK.
- Do you want to orchestrate some resources outside AWS — Terraform / CDK for Terraform.
- Do you plan to have a multi-cloud environment — Terraform.
One way or another, choosing the right IaC tool is a quite demanding process involving plenty of thinking. However, no matter what you choose, the only truly wrong decision is not to use tools designed to streamline your software development and delivery processes at most.
What is containerization? Essential DevOps Tools for container management
Why use containers and container tools? Container engines
What’s the goal of DevOps methodology?