Cloud Computing: Revolutionary Innovation

Cloud computing was, and is revolutionary for a lot of organizations. It enables virtually infinite scalability, spending on IT infrastructure on a pay-as-you-go basis, and abstracts away the need to manage physical servers (land, electricity, cooling, physical security, etc.). Furthermore, many cloud providers have specialized offerings that make it easier to build applications quickly and efficiently (see Platform-as-a-Service). The true value is that it lets engineering teams focus more on what their customers care about (the application’s functionality) and less on the foundational requirements that customer does not care about – namely IT infrastructure.

Cloud Computing: Challenges Encountered

As cloud computing became more heavily used by engineering teams everywhere, and the services available across major cloud providers multiplied, problems began to emerge. The challenges can best be expressed as questions engineers would frequently ask when their cloud computing resources were provisioned by clicking through the AWS Console or running gcloud CLI commands. The answers to these questions pre-infrastructure as code were not exactly inspiring.

• How can we ensure that our development and production environments are consistent? We can go through the cloud console or CLI print outs and review the respective resources used within each environment. Hopefully we don’t forget to click into a particular cloud service and miss any differences. Every check requires another manual review.
• Hey Engineer XYZ, how did you configure that EC2 instance? We can look at the specific resource through the cloud console or a CLI print out, but hopefully we don’t miss anything. Assuming we get everything right, however, and then want to create an identical version of that EC2 instance, we have to hope that we will not make a fat-fingered error when configuring the new resource manually.
• What cloud resources do we currently have provisioned in this AWS Account? Again, we must rely on CLI print outs, or detailed, manual, cloud console traversals. Everytime we want a fresh update, the entire manual process gets kicked off again.
• How can we review engineer XYZ’s requested infrastructure to ensure that they meet design and security standards? We can either greatly restrict engineers’ abilities to create infrastructure, funneling everything through a dedicated cloud team, or manually review their resources after they have created them. Either way, not ideal!
  
• How can we roll back cloud infrastructure to a prior state? If new infrastructure changes lead to production problems, we will have to hope that an engineer has a detailed and accurate memory of what the prior infrastructure state was for a particular resource, or comb through cloud logs. Then they can make the correcting change manually via the Cloud Console or the CLI.
  

The Solution: Representing Infrastructure as Code (IaC)

If we can represent our cloud Infrastructure as Code, then we suddenly have automated and stable solutions to all of the pain points mentioned above.

• Consistent deployments across environments: Robust Infrastructure as Code tools allow code components to be bundled and configured with input variables. This allows for consistent infrastructure deployed across multiple environments with ease by leveraging the same code bundles.
• Documented resources: When infrastructure is code, the code serves as readable documentation on the state of your cloud.
• Natural infrastructure review process: When an engineer wants to make an infrastructure change, they are free to do so, but it must be done via the chosen IaC tool. When that code is submitted, automated policy and security checks can be run within a CI pipeline, in addition to Senior Engineers performing code reviews.
• Quick rollbacks: With our infrastructure as code, rollbacks become as straightforward as reversing a commit and re-deploying your infrastructure through a CD pipeline.

One thing to note is that your cloud must be is fully and accurately represented as code. If infrastructure drift happens, these benefits arode.

Why Cloud Computing Infrastructure Should Be Managed by IaC Tools: The Business Case

The problems solved by using Infrastructure as Code are not just nice-to-have enhancements to engineers’ workdays. There is tangible business value to unlock from having a cloud footprint controlled by code.

IaC makes stable infrastructure deployments across multiple environments faster to release. Faster deployments equal newer features more quickly and more revenue as result. Documented, reviewable cloud resources declared via IaC correspond to more secure infrastructure and lower security and compliance costs. Quicker rollbacks enabled by IaC mean less application downtime, less SLA costs, and higher customer satisfaction.

Leading IaC Tools to Get Started

Convinced that an IaC tool would be helpful within your organization? Unsure of which IaC to use? Here are the leading Infrastructure as Code tools from which you can choose:

1. Terraform (Multi-cloud, Open-Source)
2. Pulumi (Multi-cloud, Open-Source)
3. AWS Cloud Formation (AWS Only, Proprietary)
4. Azure Resource Manager (ARM) Templates (Azure Only, Proprietary)

Unsure of which to choose? We have built a flow chart to help you choose the right IaC for your organization here.

–