Suppose you have provisioned infrastructure using code or configuration files. In that case, you may also know that the development experience for IaC is different from that of developing applications and middleware.
There are three main aspects of building the infrastructure using IaC. Various IaC tools have different terminologies for the above concepts. However, the core of it can be safely summarized below.
- Source code or configuration files.
- Real-world infrastructure deployments.
- State file/database that stores the current status of deployments.
In addition, there are version control systems and team collaboration efforts that introduce some learning curve. The practices also differ for the organization-specific requirements, which often involve overarching security standards, regulatory adherence, network restrictions, etc.
Thankfully, some tools ease the IaC implementation in most areas discussed here. This post highlights some of the most useful IaC tools and services in no particular order of preference.
Terraform is a well-known IaC tool used by individual developers and organizations alike. It is possible to use Terraform locally as well as remotely. Every Terraform run (plan, apply, destroy commands) deals with two things:
- Querying of state file information – set up locally or remotely
- Modification of infrastructure components
A local execution can mean that the state file is managed locally or remotely, but the execution of the desired configuration using the cloud platform APIs strictly happens on the local machine. In the case of remote execution, the state files are always stored and managed remotely, as well as the cloud platform API calls are performed on the remote system.
Terraform Cloud provides a cloud-based platform for remote execution of the configuration, which is great support for large teams owing to its features. Apart from maintaining the state file information securely without getting corrupted, it also provides hosts to run the execution of the desired configuration. Some of the main features offered by Terraform cloud are described below.
1. Event-driven runs
Terraform Cloud recognizes the importance of integrating with VCS, where the versions of Terraform source code reside. It offers a way to trigger the deployment of the main branch or feature branch based on the commit or merge events.
2. State management
Since state file management cannot happen in VCS, and almost all the teams using Terraform require a remote backend with a locking mechanism, Terraform Cloud also helps easily manage the remote backend on their platform.
3. Remote execution environment
While using the Terraform CLI, it is possible to execute Terraform commands from the local terminal with validation from Terraform Cloud platform remote backend. It is preferred to run the execution commands from the Terraform Cloud platform itself. Terraform Cloud offers a consistent and stable platform to facilitate Terraform runs.
4. Workspaces
Terraform Cloud provides support for workspaces which is more in line with the multi-environment resource requirement. Every workspace has its own state data and variables.
5. Terraform Cloud Agents
For on-premise data centers managed by enterprise solutions like vSphere, Nutanix, or OpenStack, Terraform Cloud provides lightweight agents that enable communication between the private network and the Terraform Cloud for provisioning operations and management.
Terraform Cloud provides a UI experience around Terraform workflow which is helpful for understanding and taking quick actions on the infrastructure.
If you are looking for Terraform Cloud Alternatives, we recommend reading Terraform Cloud vs. Atlantis comparison blog post.
Pulumi Service is a web application that helps teams manage their IaC state and other organizational features. If you have been managing your infrastructure via Pulumi, chances are you are already familiar with Pulumi Service since it is the default option to manage the state backend.
Pulumi Service offers accounts and organizations features to manage appropriate access to the stacks. It is an in-depth offering where team members can be onboarded and assigned organization roles to carry out tasks and approvals assigned to them. Pulumi Service also supports Identity providers and SSO.
The infrastructure is managed using stacks. Each project is a group of stacks in Pulumi Service. Every isolated and independently configurable Pulumi program is a stack. The Stacks on Pulumi Service are a reflection of the same.
It must be noted that the Pulumi Service mainly acts as a backend for state files. It does not provide automation capabilities by itself or any runtime agents to carry out provisioning tasks. Instead, it offers integration capabilities with an array of well-known VCS providers to leverage their CI/CD capabilities.
More details about how Pulumi works are described in What is Pulumi? blog post.
As the name suggests, AWS CloudFormation is an IaC platform built by AWS to manage resources on their platform. The infrastructure is expressed in the YAML or JSON format. These configurations define the desired cloud resources to be provisioned or modified on a given AWS account.
The CloudFormation configurations can be created from scratch, or the existing templates provided by AWS can also be reused and repurposed. Unlike other IaC tools, with AWS CloudFormation, we do not have to worry about state management and backends since it is managed by AWS CloudFormation service. When a changed configuration is proposed via CloudFormation files, a change set is created, highlighting the proposed change’s impact.
AWS CloudFormation Designer offers a web-based UI where the required cloud resources can be dragged and dropped on the canvas to design an end-to-end architecture visually. This visual design is then used to generate the CloudFormation templates to provision those AWS resources. The Designer provides great help and saves a lot of time when creating any infrastructure design from scratch.
If developers want to use a familiar language to express infrastructure as code on AWS, then AWS also provides a Cloud Development Kit (CDK). AWS CDK is an IaC tool that provides great flexibility to developers by reducing the learning curve. AWS CDK uses well-known languages like .Net, Typescript, Python, and Java. Under the hood, infrastructure expressed using AWS CDK is converted to the corresponding CloudFormation templates.
Take a look at a detailed comparison between Terraform and AWS CloudFormation.
Azure Resource Manager (ARM) is a central management layer to manage any type of resource request on Microsoft Azure. The request may originate from the portal, APIs, SDKs, or IaC templates like ARM templates and Bicep files. Find out more about ARM templates and Bicep files here.
For organizations that use Microsoft Azure for their cloud resource requirements, ARM templates and Bicep files are the native IaC tools. ARM templates are expressed in JSON object format, where we declare all the Azure resources required to be provisioned in the appropriate subscription and resource groups.
Similarly, Bicep is a domain-specific language that is an alternative to JSON ARM templates that offers a programmatic development experience for IaC development. As against ARM templates, Bicep is an abstraction of ARM templates. Thus it is easier to create and navigate through the Bicep files to design infrastructure components.
Since Azure Resource Manager is a central management layer, it is designed for resiliency and continuous availability. ARM service is available globally. Thus it covers all the regions and availability zones. The service available for certain resources may be regional and limited, but ARM services also take the same into consideration. This enables a consistent experience across any resource provisioning.
Authentication and role-based authorization are inbuilt into the ARM service. Thus every resource request is authenticated and authorized by default.
As discussed in the Terraform alternatives blog post, Google Cloud Deployment Manager (CDM) may not be an exhaustive IaC solution for managing Google cloud deployments. However, it is a native IaC solution for infrastructure being managed on the Google Cloud Platform.
Unlike the ARM, Google CDM is not a central service serving requests in any form. Google CDM is built specifically to interpret deployment YAML templates for GCP.
A deployment in YAML templates consists of multiple primitive resource declarations. This YAML template acts as an input to Google CDM, which provisions the corresponding cloud resources on GCP. It is possible to create and use composite resource types that consist of multiple primitive resources. This promotes reusability in terms of modularity.
Register 3rd party resource APIs with Google CDM, as far as they satisfy the REST API requirements, is also possible. When a deployment YAML consisting of primitive, composite, and 3rd party resources is fed to Google CDM, the CDM expands the deployment YAML to include all the primitive resources in a single YAML file before deployment.
Google CDM might be a good option if all the cloud resources are limited to GCP for an organization. However, it would make more sense to consider other options before going multi-cloud.
The Red Hat Ansible Automation Platform is a complete automation suite mostly geared toward configuration management. It also has infrastructure provisioning capabilities. The Ansible Automation Platform aims to implement automation across the organization.
Since we are discussing useful IaC tools, we would focus on the virtual resource provisioning aspects of the Ansible Automation Platform. An agentless configuration management tool like Ansible is responsible for maintaining the latest and stable versions of OS and applications running on the infrastructure.
Ansible achieves this by using playbooks and inventory lists. Playbooks are a set of instructions that essentially provision and configure the infrastructure or just configure the existing resources. The inventory lists are crucial here for any Ansible operation.
When Ansible playbooks are also responsible for the lifecycle management of transient virtual resources, then updating the inventory list as soon as the resource is provisioned becomes an important task. This creates a dependency without which Ansible cannot carry on with the main purpose of configuration management of the target virtual machine.
To discover and update the inventory list with virtual resources, Ansible suggests three approaches described below.
- New resource provisioning may happen by baking in some information. This information can then be used by Ansible to connect to the VM and modify various aspects of it on the application layer for configuration management. This means regular images provided by the cloud provider platform may not be useful in the regular course as they do not have this information anticipated by Ansible.
- Another option is to execute certain boot scripts which give the callback to the Ansible host once the VMs are fully provisioned and ready to use. This requires the provisioning process to use attributes like user_data in AWS, which typically accepts a bash script that is executed once the instance is booted.
- The third option involves the Ansible Automation Platform and Satellite, where the virtual resources, once provisioned, are already configured with a systemctl service by Satellite hosts. When the machine boots for the first time, the service is invoked, which makes a call to the URL hosted by Ansible Automation Platform, which then instructs the Ansible host to trigger the configuration management playbooks for newly provisioned hosts.
All the options involve heavy automation for the provisioning of resources using playbooks but always involve a dependency to “know” when the resource is created. As compared to other IaC tools, which focus solely on the infrastructure provisioning aspect, this dependency can prove to be a fair trade-off if the configuration management is also considered to be part of the end-to-end workflow.
If you are interested in Ansible, here you will find useful Ansible content.
Spacelift is a platform to manage infrastructure provisioning workflows which also eases the developer experience to a vast extent. It is a very powerful platform as it works with cloud-agnostic IaC technologies like Terraform and Pulumi, as well as cloud-specific IaC features like AWS CloudFormation and Azure ARM templates. No matter which IaC technology is used, Spacelift provides a common interface to manage the automated provisioning of multiple stacks in multiple cloud platforms.
Spacelift integrates with several major VCS and cloud platforms, enabling teams to get up and running with cloud provisioning automation within minutes. It facilitates collaboration within infrastructure teams with much-needed uniformity and a sleek presentation interface.
Organizations struggling with multi-cloud deployment workflows and introducing flexibility in the infrastructure provisioning at lower levels of user experience find Spacelift to be the go-to solution. Automated workflows designed in Spacelift stream provisioning logs directly into the GitHub interface, thus introducing transparency in the system.
Spacelift offers drift detection and automatic reconciliation, which is a great feature for large organizations. Infrastructure drift is quite a common scenario that may be caused due to human intervention or overlapping automation practices. This external change introduced to the infrastructure managed by any IaC may go unnoticed and cause issues in the longer run.
By the time these changes in the form of “drifts” are noticed, it is usually too late to mitigate manually. Spacelift detects the changes in the infrastructure it manages at a set frequency and also runs reconciliation workflows automatically, thus saving potential costs.
Spacelift also implements the Open Policy Agent (OPA) framework to introduce guardrails in the form of policies to avoid unintentional changes to the workflow.
You will find more technical details about the Spacelift solution in the official docs.
Companies that implement Infrastructure as Code will have a competitive advantage in future years. If you are currently making the transition to IaC, understanding the right tools from the outset will make the move easier. Tools and services you utilize can remove a ton of friction from your workflows and prevent future headaches. Btw. If your favorite IaC tool isn’t mentioned here, drop a comment below and let us know.
Automation and Collaboration Tool for Infrastructure as Code
Spacelift is a flexible orchestration solution for IaC development. It delivers enhanced collaboration, automation and controls to simplify and accelerate the provisioning of cloud based infrastructures.
