The ease of managing cloud environments has matured along with the growth of cloud computing, to where an entire environment can now be set up with templates.
When companies first went to the cloud, engineers built and managed cloud environments manually with consoles or command lines, without much advance thought of how they would manage the environments or how to make incremental improvements to the environments in a controlled manner.
Manually setting up environments often led to major pain. The reliance on engineers’ tribal knowledge of the environments repeatedly meant not having an audit trail or even a synopsis of how resources were deployed. And the pain increased whenever an engineer with that knowledge left an organization.
But over the last several years a practice called Infrastructure as Code (IaC) has taken hold within the industry. IaC allows engineers to declare environments through templates containing configuration files, which an orchestration service reads and then deploys resources based on the configurations. These environments have often been configured as virtual machines or networks.
IaC has rapidly matured to provide greater end-to-end coverage for environments, filling in the gaps from the cloud’s Stone Age when storage, firewalls and other security items could not be included in deployments. The maturation has resulted in rising acceptance and enthusiasm for the use of IaC in organizations.
The Advantages of IaC
IaC provides several significant advantages to organizations:
- Elimination of tribal knowledge: IaC templates turn tribal knowledge into organizational assets. Configurations are treated as software and serve as a deployment playbook and record with version controls, backup, and rapid rollback capabilities.
- Speed of setting up environments: To build an entire environment in IaC templates from scratch might take a week or two depending on the level of technical complexity within an organization. But once the templates are in place, additional environments can be set up and deployed in a matter of days or hours, depending on how many IaC files are reused. In pre-IaC times, engineers basically had to reinvent the wheel every time they set up a new environment.
- Flexibility for testing and prototyping: Instead of building tests and prototypes from scratch, IaC templates can be leveraged to quickly create a wide variety of models.
- Accuracy: Manual environment setup, requiring deep knowledge of systems and applications, is very error-prone and risk-laden. IaC practices allow engineers to iterate and track lessons learned and apply them in the form of adjustments or updates to IaC files, increasing future accuracy. For example, mistakes encountered in setting up a development environment can be eliminated when setting up integration, pre-stage and production environments.
Comparing the Major IaC Providers
The four main IaC providers today are Amazon AWS Cloudformation, Azure Resource Manager (ARM) from Microsoft Azure, Google Cloud Deployment Manager, and Terraform from Hashicorp.
The first three are considered native IaC providers, and their offerings work best within their own clouds. For example, ARM templates work very smoothly with Microsoft’s deployment implementation tool, Azure DevOps (formerly Visual Studio Team Services). The native IaC providers hold a distinct advantage over Terraform because new features are released in those platforms several months before similar features appear in Terraform.
IaC templates from all four providers can be written in JavaScript Object Notation (JSON) format, but JSON syntax can be tricky to understand, and it’s also error prone. For this reason, three of the four IaC providers have enabled the use of YAML (which humorously stands for Yet Another Markup Language), which is far easier to use and read and incorporates the ability to add annotations to the script. However, at this time Azure’s ARM templates do not leverage YAML.
Azure environments may hold one additional drawback: Some legacy (pre-ARM) resources are not accessible from ARM templates. While this is becoming less and less of an issue, if an organization has an environment that was deployed in Azure in the legacy model era, that instance might need to go through a migration process to upgrade it to ARM. All new ARM deployments, however, are sourced to current resources and do not access the legacy resources mentioned above.
The only collective drawback for Cloudformation, ARM and Google Cloud Deployment Manager is they’re more suitable for their own clouds and not for organizations wishing to leverage multi-cloud environments.
However, this is where Terraform shines. Terraform is a unified orchestration IaC process that encapsulates for all three major clouds in one offering. For example, you can use Terraform IaC templates to run applications in Azure, data lakes in AWS and advanced data analytics in the Google cloud if you wish. If organizations have the need to leverage specific resources in different clouds, then Terraform represents the best solution in those scenarios.
IaC Best Practices and Recommendations
With the pros and cons of each provider in mind, here are a few IaC best practices to consider:
Go native whenever possible: Because of the delay in feature releases in Terraform, organizations can deploy richer environments sooner with the native IaC Cloudformation, ARM or Google Cloud Deployment Manager solutions.
But consider multi-cloud: Look at your business requirements and the business threshold where multi-cloud might make sense for your organization. This can be accomplished with a SWOT analysis pitting multi-cloud against native cloud vendors, determining where each vendor matches up with the value that the business is looking to achieve.
Also consider vendor lock-in: Historically, organizations have been wary of getting locked in to a single vendor for too many of their enterprise solutions. The same notion can apply to cloud vendors’ IaC solutions, where an organization might become too reliant on just one vendor’s offerings. Your organization will ultimately need to decide how much risk it is willing to take by relying on a single vendor. At the present, however, it appears to be a more expensive proposition for organizations to leverage multiple cloud vendors, and they’re more likely to be all-in on a single vendor.
Leverage Kubernetes: One way of being cross-platform regardless of your IaC solution is to leverage Kubernetes container orchestration, a non-platform-specific solution for Docker containers that is open-sourced by Google and leveraged by all four major IaC providers. As the industry moves more toward containerization and away from the use of web servers configured on virtual machines, leveraging Kubernetes is a smart decision that allows flexibility to incorporate future innovation from any cloud vendor.
The Future of IaC
All four major IaC providers are pouring major resources into their solutions and seem to be innovating and maturing at similar levels. AWS is ahead at the moment in terms of extensibility, offering more programmatic approaches with the ability to run macros in Cloudformation templates. But the other providers will surely compete by becoming more diverse with their own programmatic IaC offerings.
ARM and Google Cloud Deployment Manager should gain some market share as they extend their coverage, but it will be difficult to cut into Cloudformation’s lead. Terraform, as the main cross-platform offering, should retain its market share as companies seek to reduce risk.
Organizations will certainly continue to receive enormous benefits not only from implementing IaC solutions, but from the maturation process of these solutions moving forward.
Are you interested in learning more about Infrastructure as Code? Tell us about your challenge.
