Learn the best practices to properly start an infrastructure as code project, from the source code to collaboration exercises and tools.
Join the DZone community and get the full member experience. Infrastructure as Code (IaC) has been a trend for many years. While some standards are being defined today, we continue to hear about new methods or tools to improve and make our lives easier by automating our daily tasks as much as possible. Fortunately or unfortunately, today, we have the choice between multiple automation tools like Ansible, Pulumi, Terraform, etc, each one having its own benefits and disadvantages. Thus, choosing the right tool is not the easiest part. It requires a team collaboration to identify, test, and define the right tool. This collaboration is the key to success, it is important to ensure the engagement of the other teams to the IaC project to properly automate the process of each team. Choosing the right tool is a challenge, but defining the architecture of the project is another one. Apart from the war of mono or multi-repository, the focus in the definition of an IaC project architecture should still be collaboration. The purpose should be to aim for simplicity to facilitate engagement. The purpose of this post is to present an opinionated infrastructure-as-code project architecture used multiple times with different automation tools in different environments. But, let’s start with a quick introduction to what an IaC project is. Infrastructure as Code represents the management of any infrastructure component (Cloud architecture, networks, virtual or physical servers, load balancers, etc) in a descriptive model. Based on the practices of software development, it emphasizes consistent, repeatable routines for provisioning and changing systems and their configuration. Similar to the principle that the same source code generates the same binary, an IaC model generates the same environment every time it is applied. IaC is a key DevOps practice. Basically, that means IaC is a methodology of provision, configuring, and managing an IT infrastructure through machine-readable definition files to easily version the state of an entire infrastructure. This methodology is not new, it has been improved over the years and continues to be improved today. An IaC project could potentially have no end since it is obviously linked to the business requirements of the company. There are multiple benefits of an IaC project. The main ones are: Based on this, IaC coupled with the right tool and an appropriate project architecture can be powerful for every engineer in a company. Automation (and IaC) is not reserved for the DevOps team, so when it is time for you to make some choice, have in mind the entire infrastructure to not only improve your daily tasks but also the tasks of your colleagues. Keep in mind that collaboration is the key to success! This is an opinionated architecture that proved its efficiency in multiple contexts. It has obviously been improved over iteration and can probably be improved again. Keep in mind that an IaC project cannot be defined correctly from the first time, it requires several iterations to adapt to the company’s work methodology. Here is a quick explanation of the directory architecture: This directory architecture can be used to logically separate the provisioning code from the configuration code without having to manage multiple repositories which, in some cases, can be a benefit. That way, full automation can be easily handled by the same project, like the provisioning of a virtual machine with Terraform and automatically configuring it with a local provisioner like Ansible. Collaboration is the key to success, like a great proverb says: “Alone we go faster, together we go further!” Developing an IaC project as a team avoids someone developing an architecture that nobody else can understand, and also avoids choosing the wrong automation tools. Keep in mind that an IaC project should be used by anyone in the engineering team of a company to automate its processes. The main goal of the DevOps methodology is to reduce the gap between the operation and the developers. IaC can help, but to achieve that, the project requires involvement from everybody. Obviously, an IaC developed with different teams requires project management to divide it into roadmap, tasks, sub-tasks, and to follow the progression over time. This post doesn’t aim to explain how a project should be managed, but what teams can do to collaborate easier. This step is often forgotten by the operation team, but keep in mind that an IaC project should be seen as any other software project. Version control is the practice of tracking and managing changes to source code over time to prevent concurrent work from conflicting. It also introduces release management to quickly roll back to a previous version when needed. A convention has to be defined and potentially managed automatically by a continuous delivery pipeline to automatically tag a repository, a state file, or a bucket. This convention can be as simple as: In other words, the convention for an IaC project could look like: Another best practice from the development side that an IaC project should follow, the usage of branches. Branches, in any source control software, allow people to diverge from the production version of code to fix a bug or add a feature.
