Over recent years, Infrastructure as Code (IaC) has become sort of a utopian goal of many organizations looking to modernize their infrastructure. The benefits to IaC have been covered many times so I won’t go into too much detail, but the highlights include:

• Reproducibility of an environment
• Reduction in deployment time
• Linking infrastructure deployments with application deployments
• Source control for infrastructure items
• Reduction of misconfiguration

The reasoning behind storing all of your infrastructure as code is valid and a worthy goal. The agility, stability, and deployment speeds achieved through IaC can prove to have substantial benefits to the business as a whole.

IaC is a Commitment to the Process

Now for the bad news. If you’re going to set out on a path towards infrastructure as code, you can’t waiver on when you’ll be using it. You must commit to the use of IaC for your infrastructure tasks. Let me give you an example so that you understand why it’s important to always use IaC if the environment was created this way.

Assume you’ve built out a great Amazon Web Services environment through the use of CloudFormation (CFn) templates. These templates are either JSON or YAML documents that exist as a desired state for your deployment. Your environment includes, VPCs, subnets, encryption keys, logging standards, monitoring configurations, and several workloads. All of these items have been deployed through a CFn template and exist in your environment today. Now suppose that the application owners have identified a problem and need to make a change. Perhaps they found out that they need to have access to a server located in an ancillary data center some place to make their app work properly. Now this is an emergency request because [reasons] (There are always a list of reasons why these things are emergencies, even when they aren’t). So you deploy a VPN tunnel through the AWS console and get the application working again.

Everything in the environment is running as expected now, but there is a problem. We didn’t commit to IaC so our environment isn’t completely defined by code. You might think, big deal, but what if we need to re-deploy the environment? Assume that later we need to re-deploy the environment for a lab, or development environment. The new environment won’t have the VPN tunnel created earlier because it was done manually. So this would be a manual configuration change that would need to be made again if it wan’t added to your code. What’s worse is if you apply a change set later on to modify your configuration, you might find that it deletes your VPN tunnels because they were defined in the code. Note: this is unlikely to affect the VPN tunnel in this situation, but in other cases, it’s very likely to undo your manual configurations.

Observations

Over the past year I’ve seen companies set forth in new cloud initiatives and have a desire to do the right things like employing infrastructure as code for their deployments. But if this is the goal, team members should embrace the process of putting any configuration changes into the code base. This is a tough pill to swallow for some organizations because, just like in the situation described above, it may take longer to make a small configuration change to fix or improve a system. The benefits of having the changes committed to code are that, the system can be re-deployed from scratch very easily and version controlled if necessary.

Suggestions

First of all, decide on whether or not infrastructure as code is a worthy objective. Maybe your organization just isn’t ready to tackle this. Maybe you have a small infrastructure footprint or don’t deploy workloads very often, or maybe you just don’t have the coding skillsets yet. Maybe IaC just isn’t a good fit for you at this time.

Second, if you decide to go forward, commit to doing it for all aspects of that environment. Switching whole heartedly to IaC for everything is a pretty tough thing to do all at once, but you might have a cloud project coming up where you decide everything in that small environment will be IaC. That way you can slowly but whole heartedly commit to the concept for a smaller subset of the environment. Once you’re comfortable with that environment the coding experience you’ve gained will help with future environments and should ease the way for them.

Good luck with your coding! Thanks for reading.