Key considerations for DevOps teams when adopting Infrastructure as Code

Like many of you, I love Infrastructure as Code.

The flexibility and maintainability that comes with defining and managing your infrastructure in a comprehensive, central, and sustainable way can be life changing for those who have come from the ClickOps world. Infrastructure as Code has been established as best practice for running infrastructure, with many tools having been developed over the years (such as Terraform and Cloudformation).

This post won’t be rehashing why Infrastructure as Code is good—hopefully you all know why it is better to have things as code rather than doing the “clicky pointy” to manage production infrastructure. Instead, I will be looking at how to make decisions around what tooling and approaches your DevOps and Platform Engineering teams should take when adopting Infrastructure as Code.

Cases for adopting Infrastructure of Code tools

As an engineer, most of the organisations I have worked with have had some sort of Infrastructure as Code tooling in place, however, there have been varying levels of adoption and maturity. There are many reasons for this, and mostly it’s not because people are passionate about continuing to use ClickOps. It’s usually due to a mountain of tech debt and a lack of investment in evolution. 

In one particular organisation I worked with, teams were using a combination of three different Infrastructure as Code tools (all with slightly different deployment and management approaches), which were remnants of a previous DevOps team structure. A team restructure later on, involving the team being pulled back to a centralised model, meant that no one person had a complete understanding of all the Infrastructure as Code patterns. Then, as people resigned and left the organisation, along with the skills they had built in managing the infrastructure, the remaining team really struggled. What was once Infrastructure as Code, turned into ClickOps to get things done. People were frustrated; it became a mess of config files and resentment every time an update needed to be made.

This scenario above isn’t unusual; most organisations on the way to reaching Infrastructure as Code maturity will hit some snags and “learning opportunities” along the way. I believe that many of these snags could be overcome with a little more forethought from the teams adopting these new tools.

I commonly see three types of scenarios where a team will be adopting a new infrastructure as code tool:

1. They have no tools currently to manage Infrastructure as Code
   

2. They have an existing tool, but need to migrate to a new one
   

3. Their organisation is encouraging adoption of a supported Infrastructure as Code tool
   

While these scenarios are similar, your team’s considerations will be slightly different in each case.

4 considerations before adopting a new Infrastructure as Code tool

If your team is not currently using any tools to manage infrastructure you will need to consider:

1. What is the existing skills set of the team?
   Determine and evaluate whether anyone has previous experience with Infrastructure as Code tools? If not, are there others within the business who can assist with the project? Another consideration might be the team’s background, i.e. if they are developers, something like AWS' CDK (Cloud Development Kit) might be easier to adopt.
   

2. Who will be developing/maintaining the infrastructure long term?
   In a true DevOps model, the team manages the Dev and the Ops. However, in practice, this isn’t always the case. It’s important to have an understanding, before you embark, whether the adoption of Infrastructure as Code will impact the ownership and support model of the infrastructure, i.e. if AWS has an outage, will your team be responsible for helping to get your infrastructure back up and running?
   

3. Has this been done before in your organisation?
   If your organisation has a decent sized technology function, there is a high chance that a team is either using, or has given Infrastructure as Code a go. Dig around before you embark to make sure you start from the most informed place.
   

4. What cloud platform do you use?
   Do you expect this to change any time soon? Some tools are platform specific, i.e. Cloudformation only works on AWS, but others are more flexible. 
   

3 considerations before switching to a new Infrastructure as Code tool or moving to a single existing one

If you are looking at switching to a new tool (which is less common), or standardising teams into using a single tool, consider:

1. What are you trying to achieve by making this change?
   Are you influenced to switch or move because your team has experience with this tool? Do you believe that the tooling has significant feature-based benefits over your current Infrastructure as Code tool? Do you need to standardise to make management of infrastructure easier? There are no right answers, but these questions should be considered, and the tradeoffs balanced.
   

2. What is the effort involved and who will be responsible?
   Just like any technology update, it will take time and skill from your team to adopt the tool. The change will also impact your production infrastructure at some stage.
   

3. Is there a timeline?
   What is your deadline for switching over to a new infrastructure as Code tool? Is it possible to switch or move in the identified timeframe? What are the impacts if delays occur?
   

Final thoughts

If your organisation has invested time and effort in building up a central platform for teams, there will be inherent resources available to them while they are adopting tooling patterns to deploy the infrastructure. This is the dream for all teams, but a lot of organisations aren’t at this maturity level yet.

Having Infrastructure as Code doesn’t inherently make infrastructure any easier to manage. Without considering the existing skills in the team, the maintenance model, and what you aim to achieve by adopting Infrastructure as Code, it can actually make your environment more complex and difficult to manage. 

The scenarios discussed here aren’t exhaustive; they are designed as high level considerations to help you start to think about where your technology organisation is at in terms of Infrastructure as Code. The goal is for all of us to ensure our DevOps and Platform Engineering teams make informed, sustainable Infrastructure as Code tooling decisions into the future.