Blog

22 Nov, 2021

People and Tools
- A Love Story

Kirsty McDonald

6 min read

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 (Terraform, 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 teams should take when adopting Infrastructure as Code.

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, 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 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:

  • They have no tools currently to manage Infrastructure as Code

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

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

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

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

  • The existing skill set of the team.
    Does anyone have 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's CDK (Cloud Development Kit) might be easier to adopt.

  • Who will be developing/maintaining the infrastructure long term?
    In a true DevOps model, the teams manage 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 get your infrastructure back up and running?

  • 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.

  • 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. 

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

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

  • What are you trying to achieve by making this change?
    Is it 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.

  • What is the effort involved, and who will be responsible?
    Just like any technology update, it will take time and skill from your team, as well as impacting your production infrastructure at some stage.

  • Is there a timeline?
    What is your deadline for switching over to a new infrastructure as Code tool?

Finally, 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 your team’s 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 consider points like those raised here to make sure our teams make informed, sustainable Infrastructure as Code tooling decisions into the future.

Share

Connect with us

Your strategic
technology partner.

Find out more
Melbourne skyline