We all think that we understand variables very well. After all, if you are a coder, a variable is something you create and use every day. But when it comes to DevOps the variable is the thing we seek to eliminate, but often neglect.
Before this post turns into the variables word game, let me clear up what I’m referring to: not the variables in your application’s code but the variables in your application’s infrastructure. In the “pipe” dream of scripted infrastructure, these variables model machines in which your application runs. When set up correctly, you can lay out fresh infrastructure in front of each deployment.
Ideally, what runs through the “pipe” are compartmentalized and fully-contained scripted environments. When done right, this means you can take your environment anywhere! However, when you start looking at nuances of your current infrastructure provider, you might be un-pleasantly surprised. Even the basics of handling IPs and connection strings can throw the whole “pipe” down the drain.
Even with a single provider, one small change – maybe the region changes or the ip of your backend server changes – can have cascading effects to your entire infrastructure, especially if it’s scripted. Why!?
Unlike best practices in your code, your infrastructure modeling scripts probably contain some pieces that are hard codded and static. So not only do you need to identify that they exists, but you also need to identify where they exist. And even in a moderately complex multi-tier script, finding these references can be a nightmare.
And of course it’s not just public IPs. As applications get more complex you’ll need to know internal private IPs, public IPs, host names, and MAC addresses. And ultimately you’ll need to manage some combination of these to build connections strings, webhooks, endpoints, etc.
The obvious solution is some friendly tooling to make variables easy to implement, locate and manipulate. One of the players in the space has made a specific effort to do just that: VisualOps.io is a nice WYSIWYG version of popular tools like Chef and Puppet. They focus on allowing you to define assets – such as IP, MAC, etc. – as variables in your scripts. Rather than dealing with hard coding, you can flexibly find, edit, and version changes at this crucial point in the pipe. It’s a very cool trend that I suspect will only continue.
While VisualOps.io currently only supports one cloud provider, you can see the power of such a template in multiple services or across hybrid and evaporating clouds: i.e. applications could move from one cloud to another seamlessly, or (even cooler) across clouds and PaaS services.
The other way to address this issue today with current configuration management and scripting tools is to be really smart and diligent about the location of the variables. This means practicing Isolating them to one area in the code, or even better yet to external reference files. If you were to put all static variables in one location, then you would have one location to update rather then hunting them down.
The downside is that most of the variable changes that happen to properties of assets will happen unknown to you, making them that much more disastrous. So this does not anticipate the problem like dynamic referencing; it just allows you to respond to it much faster. Regardless of your approach, you want to make sure you have really great monitoring tools and people and pagers at the ready.
The hard coded references in your infrastructure scripts can be a hidden threat – one that is often very painfully “solved”. So it’s a good idea to give consideration to it in new and existing deployments. The good news is that you’ve already learned the rocket science – the principles of good coding. It’s just a matter of tooling up and applying them to your infrastructure scripts.
