Solutions & Innovation Consultant
Part 2 of a 2-Part Series
In Part 1: Gaining Efficiency With Infrastructure As Code of this blog series, I discussed how Infrastructure as Code (IaC) helps organizations gain efficiency. In this second and final part of the series, I focus on five IaC best practices to help an organization be successful with IaC.
Taking full advantage of IAC requires two essential components: an automation platform and a DevOps culture. Selecting an IaC platform is critical to success. Each organization must define the selection criteria based on needs as there is no one-size-fits-all. While we at Axcelinno help customers select a platform, this blog doesn’t cover this topic.
However, it’s essential to think about the following items at a minimum:
- Will the platform support your hybrid multi-cloud architecture?
- Does the platform integrate with other platforms used to manage infrastructure?
- Does the platform enforce IaC best practices?
- Does the platform provide automation from 3rd party infrastructure vendors?
- Will the platform enable the organization to provide hybrid multi-cloud governance and security?
Regardless of the platform or platforms selected, there are notable best practices to adhere to when implementing IaC. The best practices are based on our expertise with IaC and DevOps and experience implementing IaC with customers.
#1: Be Practical When Introducing IaC Tools
IaC simplifies and streamlines configuring and deploying and infrastructure. However, the ability to quickly provision new infrastructure or apply changes must have guardrails and safeguards in place. I commonly observe organizations encounter an increased server count, zombie servers (spun-up and then forgotten), or larger-than-expected cloud bills. Why? Because now that it’s easier to get the infrastructure, end-users continue to operate under the “someone else is managing it” mentality. I always recommend that organizations have a decommissioning process and a mechanism to alert users when said process occurs.
#2: Use Version Control
Saving all artifacts, such as templates, configuration files, scripts, and other files, in version control is imperative. Version control becomes the source of truth for the infrastructure details. Version control systems like GIT also increase collaboration among teams by providing a centralized repository to locate infrastructure details. The benefits of leveraging a version control system to store the IaC artifacts are:
- Visibility: Every team member can see when changes are made and the author of the change.
- Rollback: If a change introduces an error, the previous configuration can be used by simply reverting the last working condition.
- Actionable: The version control system integrates with CI/CD delivery pipelines to perform actions upon a state change.
- Traceability: The version control system provides the history of changes made, including explaining the change.
- Proper Documentation: The files stored in the version control system become the documentation for the provisioning and configuration of infrastructure components.
I want to highlight the last item, ‘Proper Documentation,’ because it may be one of the most important and often overlooked. When working with a customer, it’s common for someone to log into a server to share the configuration with me. Typically, this has to be done multiple times due to differences between environments or the server’s applications. In essence, the “documentation” is what’s on each server and is distributed instead of being centralized.
#3: Code Everything
All infrastructure definitions and details should be in configuration files, often referred to as Configuration-As-Code (CaC). The files describe the infrastructure components’ end state and provide the ability to be run repeatedly — they are idempotent. Now changes are only applied when there is a delta between the described and actual end state, also known as configuration drift. Inherently, this also identifies where changes are made outside of the configuration process, thus representing manual intervention (what we are trying to reduce) and a security risk.
#4: Modularity
Reusing code should always be a top priority with IaC. Like software and many other things in life, when implementing IaC, organizations should follow the “Don’t Repeat Yourself” or DRY principle. To manage and scale the infrastructure automation, the items stored in version control (#2 above) should be modular. In other words, group like things together. For example, don’t combine the provisioning of a Linux server with the installation of an application and assigning a network IP address. Instead, each of those items should be a module to be used anywhere. Doing so will allow the implementation and management of each module to be independent of other changes.
There is another benefit of using modularity: creating technical stacks. Technical stacks are what I call the combination of modules to get to the desired end state. For instance, a technical stack may include three modules for provisioning a Windows Server, installing IIS, and configuring one or more websites.
Other advantages of leveraging modularity are:
- Faster and easier to make changes
- Super effective in validating changes work as expected
- Easy to identify the cause of the problem when looking for a small change compared to a large batch of changes
#5: Incorporate Security
By default, using IaC and CaC improves an organization’s security posture. Why? Because individuals no longer need access to servers to make changes, and source control tracks the changes.
There is also another way security will be involved in the configuration of infrastructure components. Instead of running scans after the provisioning or configuring of infrastructure, which often only happens with new infrastructure, a scan of the end-state configuration can occur. Therefore, an organization must have the mindset that using IaC and CaC establishes a baseline to measure infrastructure components to determine compliance. Baselines such as the Center for Internet Security’s CIS Benchmarks () and the US Department of Defense Systems Agency (DISA) Security Technical Implementation Guides (STIG) are references I recommend.
Implementing IaC is never a small amount of effort as groups such as Operations, Infrastructure (Windows, Linux, Networking, or Cloud), Development, and Security will be impacted. Therefore, all groups must be involved in a coordinated effort with clearly defined outcomes. The five best practices I have discussed in this post are what we at Axcelinno use to accelerate the adoption of IaC with our customers:
- Be practical when introducing IaC tools
- Use Version Control
- Code Everything
- Modularity
- Incorporate Security
The best practices provide core pillars to build your IaC roadmap to ensure a path to IaC nirvana.
Infrastructure as Code (IaC) can make impactful changes to an organization’s infrastructure, automating the infrastructure deployment makes compliance and security testing more important.
Below are some steps or phases that the organization can go through to ensure adequate security.
- Manual security assessment
This process involves a manual inspection of the production infrastructure after the deployments. Even if the DevOps team proficient in creating scripts like Terraform and AWS CloudFormation templates, most of the teams might still be practicing traditional approaches, and they might not be aware of these technologies. The process of examining the templates to configure our infrastructure can be a slow, labor-intensive process that may even require back and forth communication between the security and operations team, which can put a brake on CI/CD pipelines.
- Code analysis before deployment
Here, all the templates to configure our infrastructure as code and perform compliance and security unit testing are checked and tested thoroughly after committing the code. This process helps to bring security very close to the source, which can drastically reduce operational difficulties and increase time to identify security compliance.
- Testing and deploying in a sandbox environment
The repeatable principle of IaC makes it possible to deploy the templates into a sandbox environment. Before making any changes to the production environment, applications can be tested in the sandbox. Automated testing can validate that there was no security compliance violation before any changes can be pushed to a production environment. Although this strategy is super effective, it can incur additional costs.
- Continuous monitoring of the production environment
Here, the production environment is continuously monitored for security violations. This is usually achieved using a dedicated security solution that can provide continuous compliance and security testing. This form of monitoring covers both automated changes as well as manual changes.
To take full advantage of Infrastructure as Code, there needs to be three essential components working together: automation tools needed to write code, a well-established DevOps culture, and an Agile development process. DevOps and Agile go hand in hand, as they help to increase the development processes’ efficiency and effectiveness. A few notable best practices to adhere to when implementing IaC are:
- Be cautious when introducing IaC tools to beginners
IaC can make re-configuring and deploying and infrastructure very easy. Inexperienced users can spin up multiple instances within a few minutes, but they can also cause huge damage within a short period of time. It should always be a slow process when introducing IaC concepts to beginners and they should always have proper guidance when trying to achieve something new.
- Version control
All artifacts, such as templates, configuration files, and any automation scripts that have been developed, must be version controlled.
Version control systems like GIT can help us achieve this by allowing users to collaborate by offering a centralized repository where every configuration file or template can be found. The benefits of leveraging a version control system to store the IaC artifacts are:
- Visibility: Every team member can see when new changes have been made and who has made the changes.
- Rollback: If a change to any code has a defect, this can be easily fixed by rolling back to the previous working state.
- Actionable: Version control system can automatically initiate action after a state of code has been changed which enables CI/CD delivery pipelines.
- Traceability: The version control system provides us with a history of the changes made to the code and even provides information about why the code has been changed. This is very important when debugging any problems.
- Proper documentation
There should be a proper documentation system when implementing IaC in an organization. The documentation can include architectural diagrams or documentation regarding each and every detail of the architecture, as these documents are very essential for new employees to get acquainted with the system.
- Code everything
All the definitions for the infrastructure should be written in configuration files as code. The configuration files are responsible for defining our environment. Since most of the end state definitions are in code, it can simply run again and again which helps the organization to save human resources and manual interventions. This also reduces any errors which may occur when there is a possible human intervention on the system.
- Modularity
Reusing code that has already been created should always be a top priority when working with Infrastructure as Code. The code that has been developed must be scalable and reusable. IaC can apply the concept of “microservices”. Microservices are small and autonomous services that can be independently developed, deployed, and managed. In IaC, a similar concept can be used to break down the infrastructure into different stacks or modules and combine them in an automated fashion.
Some advantages of modularizing our architecture are:
- Faster to reverse or fix small changes
- Super effective when there is a need to validate a small change and make sure it is working properly.
- Easy to identify the cause of the problem (if any) when it is a small change rather than when it is a large batch of changes.
Red Hat® and Red Hat Ansible® are a trademark of Red Hat, Inc., registered in the United States and other countries.