How to make decisions about IaC projects

IaC is a set of best practices for developers to document and configure their software infrastructure in a repeatable way.

IaC is not just about configuration management and deployment; it also provides the ability to manage infrastructure with code. The code can be used to automate activities such as application deployment, configuration management, and continuous delivery.

Here are a few plus points to consider:

• It is easy for developers to get started with IaC because the documentation is available in a single place
• It allows for more efficient collaboration between development teams by providing an easy way to share configurations with other members of the team
• It reduces errors in configuration management by making them easier to reproduce

Let’s have a look at the decision points that will improve the maturity level of IaC projects.

The decision about where to store your code

Storing IaC files using a VCS is essential for tracking changes and collaboration. While any cloud storage system can be used, Git has become the de facto standard for IaC versioning. Originally designed for storing code, Git can be used as the primary source for deploying infrastructure code. Several solutions, such as GitHub, GitLab, and Bitbucket, offer free SaaS for public repositories, while community editions can be self-hosted. Using Git should be a basic skill set for any developer or cloud or DevOps engineer looking to start an IaC project successfully.

The decision about how to structure your code

Once you have chosen where to store your IaC code, the next step is deciding on how to structure it. The structure you choose will depend on the complexity of your organization and IT environment. There are several options, including using a mono-repo for all your IaC code, having a separate repository for each tool or language used, or having a repository for each application server or infrastructure type.

In addition, you need to determine a branching strategy that works well for your team. It’s essential to discuss and agree on this with your team to ensure everyone is on the same page.

It’s recommended to start with a simple structure and evolve it over time based on your needs. Alternatively, you can put more thought into the structure beforehand to prevent potential rework later. Whatever structure you choose, make sure it’s easily adoptable by all team members. Create clear documentation on the structure and decision-making process so that new team members can quickly understand and start contributing effectively.

The decision about how to run your code

To gain better control over your infrastructure, it is recommended to use a CI/CD tool such as Jenkins, GitLab CI, or GitHub Actions to run your IaC. With these tools, you can trigger jobs manually, via webhooks or on a schedule, and have a record of every job that has run. Additionally, the jobs run from an agent can be pre-configured with the necessary tools, reducing the chances of errors due to different tool versions. It is important to choose the right tool that fits your needs and configure it properly to ensure its effectiveness.

The decision about how to handle your secrets

When provisioning automated infrastructure, it is crucial to store secrets such as database passwords and logins securely. It is not advisable to store them in your repositories, even if the repository is only accessible within your own network and protected with multi-factor authentication.

When using Git tools, all the credentials are copied to your machines and the machines of your team members when they clone the repository, making them vulnerable to security breaches.

A better solution is to use a vault system that can encrypt your secrets and inject them as environment variables during the runtime of your pipeline. It is ideal to have security enabled on multiple layers, so even if one layer is breached, there is a second line of defense to protect your sensitive information.

The decision about a common set of tools

To kickstart IaC projects effectively, it’s important for the team to agree on a consistent set of tools. While there may be several ways to achieve the same objective, it’s beneficial to explore simpler, quicker, or more cost-effective methods. Using a common toolset makes it easier to share and reuse building blocks. Striking a balance between granting engineers the freedom to experiment with new tools and standardizing on a common set of tools is crucial. Certain tools work well in tandem, while others don’t, and paying for redundant licenses is generally not a good idea.

The decision about the level of pipelines

When using pipelines to run your IaC, there are various methods to achieve the same outcome. It’s essential to use a naming convention and provide clear descriptions to help others understand the purpose of a pipeline. You can consider dividing a pipeline into multiple stages, so you have the flexibility to rerun or skip a stage depending on the type of deployment. Then, decide whether you want to enforce mandatory reviews, require approval from a manager, or give developers the liberty to deploy themselves during go-live.

The decision about the life cycle of your infrastructure

The level of testing and validation required for a proof-of-concept script versus code developed for large-scale deployment is significantly different. Robust code requires more comprehensive testing and validation efforts, which requires additional time and resources.

In an ever-evolving world, infrastructure must also be adaptable to changes such as security updates, service improvements, and new service types. While using SaaS/PaaS services can reduce the maintenance workload, it comes at a cost. Furthermore, even these services will evolve over time, necessitating engineering efforts to keep up. There are various strategies and practices available to simplify this process, each with its own benefits and drawbacks. It’s important to determine the approach that works best for your specific situation.