IT Infrastructure.. love it or hate it, it forms the foundation of many companies operations. These days you are hard pushed to get a job anyway doing anything, that doesn’t require you to use a computer, mobile phone, email, websites, a word processor…. the list goes on. These front end devices all have to store their data somewhere though. Hidden away somewhere is an Infrastructure that is enabling these devices and tools to communicate with customers and peers anywhere in the world. A lot of companies have adopted the premise of ‘Cloud Computing’ but not many have fully outsourced their infrastructure into the public cloud, utilising Microsoft Azure or AWS to name but two of the market players. There are many companies however, that have adopted the hybrid approach, where part of their infrastructure is located on premises [read in the customers datacenters], with the rest hosted by a public cloud provider.

The days of frequent racking and stacking are more or less a thing of the past. With the adoption of virtualization your cloud environments can spin up a new virtual server in a matter of minutes. All in all, we are quite spoilt. However, what happens when you have to scale out a piece of infrastructure? What happens if your web application requires additional web servers and database servers to meet customer demands? Or maybe you need to deploy additional network ports on your virtual switches? Do you do this manually? No! You script it. But what happens if your script doesn’t work properly? Can you test the impact of executing your script in advance? Can you reuse your script later on without editing it? Unlikely. Do you have separate teams such as a network team and a storage team? Can they all script? Do they do it ‘their’ way? The more people involved the higher the risk that something is going to go wrong during application and even worse, heightens the risk that you will have a non standardised deployment of infrastructure components.  So, although we don’t have ‘some’ of the pain we have lived with for many years, we now have a new pain [editor comment: although it isn’t often yet recognised by IT managers]. So, having advanced from yesterday, what can we do today to continually evolve and improve our deployment operations?

 

Enter Infrastructure as Code

In a nutshell, Infrastructure as Code (IaC) allows you to provision, manage and monitor configuration of IT infrastructure components through code. I know.. you aren’t a developer, so you don’t code! Relax, there are multiple tools on the market that enable you to adopt IaC without having to become a programmer. But why bother? Why adopt IaC? I’m glad you asked!

 

Consistency

A consistent infrastructure is a happy infrastructure! Imagine two engineers deploying two servers, one each. Is each engineer going to take the same steps? You may have a process document that they both follow, so in theory it shouldn’t be a problem. But, mistakes happen and things get missed [editor comment: especially when the phone keeps ringing]. Even if the servers are deployed identically, will they be identical in a months time? If not, what has changed? What needs to happen to bring the configurations back in line? Does it matter? Yes, it does matter. If you have an issue on one of those servers you don’t want to be distracted by misconfiguration that isn’t related to the problem you are experiencing. Nor do you want misconfiguration causing issues! You have a documented standard after all! How do you proactively check for configuration drift? IaC can help you here. Your infrastructure is defined in code, therefore standardised. Each time you use the code to deploy or reconfigure infrastructure components you know it is consistent. And because your infrastructure components are driven through code, that code can be stored securely in a code repository solution, such as GitHub. You can even use a continuous delivery solution to drive your IaC deployments for you!

 

Centralised Control

Storing your IaC content in a solution such as GitHub ensures you can manage who can access, edit and deploy your code. If you have multiple teams editing IaC content (such as a network team or a storage team) you can use common developer [editor comment: yes, he said developer! But don’t run away just yet!] practices, having individuals or teams working on separate code branches. You can have a release branch which contains the code your production infrastructure is built from. New IaC content can be merged into a test branch and deployed elsewhere to ensure that it works properly before letting in loose into production. Structured access to your IaC content and common developer practices provide you centralised control over development, testing and release of your infrastructure.

 

Reusability

A major benefit of IaC is being able to reuse IaC content across different infrastructures and environments. If you have multiple environments (lets assume production, staging, test & development) you can use the same IaC content across all of them. For example, if all four environments are backed by VMware vSphere, you can use the same IaC content to deploy a distributed virtual switch, create portgroups, configure vLans and security. You don’t need to amend or change your code in anyway, you just supply different inputs containing the target vCenter server, datacenter & credentials. Furthermore, what stops you from taking the IaC content to your customers environments? Well, if they are VMware vSphere backed then nothing at all! If you have a service provider, deploying new customer environments, tearing them down, upgrading them, changing them, then IaC will be of even more benefit to you!

 

Speed

You won’t have to worry about waiting for that server build before you can deploy your database to it. All stages of the deployment can be contained within your IaC content. Think of all those individual touch points you or your team have when deploying a full web stack application or deploying new networking configurations. You can now do all of that by launching a single script.

 

Risk Reduction

Every business has that one IT hero that knows it all. Thank goodness as well, otherwise what would we do when that old, odd system over there goes down? What happens if he is sick or leaves the company? That knowledge leaves with him! With IaC you can codify that knowledge, protect yourself and the service from outages. You can easily reapply configuration or even redeploy the application if required. What if you need to know the specific configuration of infrastructure components? A benefit of the mature IaC solutions store a ‘state’ of the infrastructure as defined in the IaC content. This state is more often than not human readable. So? Well, every piece of infrastructure you have defined, deployed and configured through IaC will know be documented! If there is configuration drift your will quickly and easily be able to see what configuration items have wandered from what was originally defined.

 

Increased Efficiency

Since you deploy your IaC content to different environments, IT users such as developers and test engineers can benefit highly from its adoption. Replica environments of system infrastructure can be deployed into silo environments, speeding up testing and development activities. You can utilise developer techniques such as continual build and continuous delivery to redeploy these environments on a scheduled, using your specific chosen branch of code [editor comment: assuming you are using a code repository such as Github].

 

Cost Savings

If you are using IaC then you immediately have reduced manual effort from your staff. They can now concentrate on other areas such as future technology that will further enhance your business. Who doesn’t want to raise staff productivity, especially in more beneficial areas [editor note: i.e. not breakfix!]. You can utilise IaC to not only deploy environments but to also destroy them. The speed and efficiency you obtain through Iac for deployments and configuration is equal when destroying them. Since you can deploy your environments so quickly you don’t have to leave under utilised environments running. Tear it down and simply redeploy it when/if you need it again.

 

So, It’s All Good Then!

Well, yes and no. You never get anything in life for free. To be clear, there is a learning curve. Picking an IaC solution [editor comment: IaC technology vendor] and learning the descriptive language will require a moderate investment of time. There are commercial versions of IaC solutions out there (such as Terraform by Hashicorp) that provide add-on functionality to make life easier, so you may wish to spend money on licensing as well. You may be throwing away some investment in scripts that you already have in house. Changes to business processes are likely to be needed as well.

However, the benefits of adopting IaC far out-way the negatives [editor comment: in our opinion]. You may just find it is a matter of timing.