Zachary Nickens

Site Reliability Engineer at Woolpert

Infrastructure is important. Infrastructure and application code are equally critical to success as a cloud engineer. Most engineers either choose the correct runtime environment, or iterate through runtime environments until they find the appropriate one for their application. How you provision, deploy, and recover whatever infrastructure you use is critical to choosing the appropriate runtime. Most cloud engineers love designing, architecting, developing, and deploying applications. Error reporting, debugging, logging and log aggregation, and alerting generally are easily baked in when working on a major cloud platform or working with common toolsets.

One of the greatest advantages to working in the cloud is the plethora of managed services and tools readily available to meet those challenges. Cloud is awesome! That’s a knife that cuts both ways, however. Managed services that are easily turned on can be easily and accidentally turned off. A managed database or a function running on serverless compute can be inadvertently dropped. And if you are provisioning and deploying those resources by hand or via shell scripts, they can introduce unnecessary toil into your downtime recovery and remediation strategies. And nobody wants toil.

Using managed services is a great strategy. Treating managed services as infrastructure and defining them using declarative and idempotent tools is an even better strategy. Define and declare your infrastructure as code, check that code into your version control system of choice, and peer review that code before changes make it into your live systems. This will save you downtime, heartburn, and headaches.

There are a wide variety of infrastructure-as-code patterns and tools. The most basic form of IaC is to simply write shell scripts to create your infrastructure. This method is not optimal. Scripting infrastructure provisioning is imperative and lacks the benefits of parallelized execution and dependency management—it’s just a scripted version of manual provisioning/deployment. Maintaining and debugging scripts introduces unnecessary toil into infrastructure. To avoid introducing all that potential toil, we can use IaC tools and methods that are declarative and idempotent.

Each of the major public clouds offers its own IaC tooling. Amazon provides AWS CloudFormation, Google has Cloud Deployment Manager, and Microsoft has Azure Resource Manager. These IaC tools offer degrees of declaration and idempotency, but they all work only in their respective public clouds. As multicloud and hybrid cloud approaches become more common in the industry, this isn’t the direction we want engineers and SREs moving in.

Good IaC uses idempotency to compare your code (desired state) and your current state and to identify drift. Tools like Terraform present this comparison and then give you a ready-to-go remediation plan to bring your current state back into harmony with your desired state. Automating away infrastructure drift with IaC tools is essentially a superpower for cloud engineers. Cloud engineers who design, provision, deploy, and remediate efficiently and effectively build reputations as reliable and capable of delivering.