Infrastructure as Code – The Journey Begins

I’m sure there are many of you who will be familiar with the arduous nature of spinning up many new systems on a regular basis. There is certainly a lot which can be done to automate that process but once the server is running (let us assume it is a virtual machine) you still need to jump on and setup everything. Wouldn’t it be nice if we didn’t have to create folders, install packages and generally ‘make it so’?

Of course there are plenty of ways we can approach this but in this post I’m really focusing on the ‘Infrastructure as Code’ method leveraging tools like Microsoft Desired State Configuration (DSC), Chef, Puppet, Ansible… the list goes on. What we want to do is define our need in some sort of policy or manifest and allow the solution to go out and configure all those settings which make that server into what we need it to be. When you start to consider the possibilities it really does open up a whole new world (queue the music) which then frees you up to look at exciting new things or perhaps pictures of cats because why not?

Currently I am starting work on the deployment of Microsoft DSC in our environment with the goal to defining our infrastructure as code to enable easy deployment and management. If I need to spin up a replacement web server for application ‘x’ I don’t want to worry about getting the supplier involved or anyone else. I’ll just define what that server needs to be running, the files and folders and packages etc and then allow DSC to build it and remediate any configuration drift in future. If you are not familiar with the idea of config drift it is merely a way of describing the motion from a desired and known good to something else. This could be as simple as a service which we declare must be running has stopped or it might be that somebody uninstalled a key feature – either way technologies such as DSC can identify this drift from our ‘desired state’ (based on our policy) and course correct.

The choice of DSC over other options wasn’t for any reason other than we predominantly run Microsoft systems, though we do have a decent amount of *nix systems of some flavour or other in the mix. DSC is syntactically the same as PowerShell which means the team has transferable skills. I’m considering how we will approach the other systems in our environment and I don’t just mean the virtual machines or hosts – I see this extending to the network/fabric and storage. In fact I look forward to the day where most of my systems won’t have a backup because I won’t need one. I will have a well defined process which is capable of building exactly what I need on demand. The easy example is web servers sat behind a load balancer – in my case this would be an F5 but it could be any other hardware appliance or a software construct. Why would I bother to backup each of these web servers? If one of them has an issue that requires any amount of troubleshooting beyond the basics I’d rather just trash it and provision a new one. Backup licensing is rarely cheap so this becomes a quick win and not only that if I can easily deploy at any time then I gain the benefit of an elastic datacenter – one that can scale out and back on demand. DSC and whatever else we might implement is going to become a key enabler in our infrastructure design and while I do feel a little overwhelmed at the scope of work I have laid before me I know it will be an incredible journey and outcome.

Many times when  I am on my way in to work my mind is racing through the various visions I have for the business and how each will drive us forward. Of course I also take into consideration the scale of what I have dreamt up and just how interdependent many of these visions are. My hope is that I will have some time to document this journey, not only the technical ‘how to’ guides that I do but also covering lessons learnt and anything I feel may be a useful insight.

If you are reading this and would like to share your own experiences I’d love to hear from you.

Leave a Reply