The Computer Weekly Developer Network (CWDN) continues its Infrastructure-as-Code (IaC) series of technical analysis discussions to uncover what this layer of the global IT fabric really means, how it integrates with the current push to orchestrate increasingly cloud-native systems more efficiently and what it means for software application development professionals now looking to take advantage of its core technology proposition.
This post is written by Scott McAllister in his capacity as developer advocate at PagerDuty — the company is known for its digital operations management technology that helps businesses across keep their infrastructure and applications running smoothly.
McAllister writes as follows…
Think back to a time when you adopted a new product or tool as part of your infrastructure, the process may have gone something like this…
You test the product with your small team and make sure it provides the value you were looking for. You report your findings back to your organisation and a short time later your boss shares the news that your company has decided to adopt the service and roll it out to the whole company!
As your boss keeps smiling at you expectantly, the reality of the news sinks in i.e. you are the most experienced person in the whole company with this new product.
That means it’s up to you and your small team to onboard everyone else in the company. The thought of repeatedly filling out all those web forms gives you a headache. And that’s just onboarding everyone. After all that work, how are you going to manage, control and track changes made to your configuration?
We’ve been here before
Luckily, this problem isn’t new nor specific to a single software product or platform.
As IT infrastructure has progressively decoupled from physical machines we can touch, managing and provisioning that infrastructure has moved to software services in the cloud. Those services are built with robust user interfaces for manual configuration. However, as discussed earlier, handling those configurations at scale is tedious and can lead to system fragility. Out of this dilemma the concept of infrastructure as code was born.
Infrastructure-as-Code is an approach for automating the management of infrastructure configuration by utilising the APIs of software services and allowing those services to be configured with code.
Infrastructure-as-Code is a practice; not a product. There are several products that implement infrastructure as code, such as OpenStack Heat, CloudFormation from AWS, Pulumi and HashiCorp’s Terraform. Each of these tools has their own approach and caters to different audiences and needs. For instance, Terraform takes a declarative approach where you state your system definitions in a proprietary configuration language known as HashiCorp Configuration Language (HCL). While tools like Pulumi allow users to define their systems using their programming language of choice in a more imperative fashion.
There are several benefits or promises to using Infrastructure-as-Code. For this article we’re going to focus on four key benefits, namely that Infrastructure-as-Code is fast, consistent, reduces errors, is self-documenting and did I mention it’s fast?
Four key IaC benefits
The first point we want to talk about is how Infrastructure-as-Code is fast. Specifically, it’s very fast to create new resources. As an example, we have a customer at PagerDuty who used Terraform to provision over 2,000 users. Using the HashiCorp Infrastructure-as-Code tool they were able to add those users in just about 67 minutes. Doing some quick mathematics, that’s creating about 2 users per second! During that same rollout the customer was also able to provision over 6,000 other new objects in PagerDuty using Terraform in just 90 minutes.
Not only is it faster to provision the resources using Infrastructure-as-Code, but with your settings defined in code, now you and the rest of your team can more easily see how your resources are configured. At a glance you can see the patterns you’re using and can make sure they are consistent with the conventions adopted by your organization. Below is a small example of a couple PagerDuty services defined in Terraform.
Looking at this code you can see how each PagerDuty service is named and their settings for escalating and alerting, making sure the settings are consistent with the rest of the configuration.
Provisioning and management is also key in the Infrastructure-as-Code universe.
Practicing infrastructure as code also provides stability to your provisioning and management processes. Just like with your application code – where there are proven principles to ensure code quality and reduce errors, defining your Infrastructure-as-Code gives you all the same benefits. When making changes to your infrastructure settings your infrastructure code can be checked into a version control system (VCS) like Git. Git allows you to implement code reviews to verify changes before pushing to production. You can also implement automated testing on your infrastructure code to provide an additional assurance of quality. Plus, with each infrastructure change recorded in the Git commit history you now have an audit trail of all modifications and who made each change.
Defining your infrastructure through code also documents the current state of your configuration. Rather than wondering if the changes you requested have been fully implemented you can look at the infrastructure code and see the exact state of what your infrastructure looks like.
The benefit of speed is so important we listed it twice on purpose. Not only is it fast to initially create objects. But, once you have a pattern of resources that you like–say for your teams, services and schedules–you can use those definitions as a template for scaling your infrastructure as your organisation grows.
Organisations of all sizes and industries are managing their Infrastructure-as-Code. If speed and stability are things you’re looking to improve with your infrastructure management, implementing infrastructure as code may be the solution for you.