We’ve all been there. You have some build document or a guidebook for deploying your application or VM or a server of some kind. You’ve seen it so many times that you’re pretty sure that you’ve memorized it. The problem is threefold:
- Things change
- Your memory may not be as reliable as you think
- More people than just you do the process
If you don’t believe me, stop and think about each of these things briefly.
Is your guide document the same as it was last week? Last month? Six months ago? Probably not, and it probably shouldn’t be. Did you print a copy of it because you need it for readability? Are you sure you have the latest updated version?
The moment that you commit a document to paper, it starts to atrophy just like muscles at rest. There is a fairly solid chance that it may have changed (or should have) from when you printed it.
Your Memory Is not Reliable
I’m very proud of my memory. It’s pretty much the thing that lets me survive in the IT industry other than my hope that humor and good nature will make me someone worth working with. No matter how good my memory is, I can assure you that I may miss some steps in the multi-step process to deploy an app.
It’s even more challenging for us as the creators of the document to realize that we miss or skip steps. I’ve authored documents that I’m fairly sure I should know inside and out. The result when I perform the steps according to the document out of memory is that I inevitably skip small things (or big things) by accident. When we wrote the docs, we also may forget to include some subtle steps that’s end up as a little bit of tribal knowledge kept within our own personal process.
It’s Not About You
Unless you are the only person who does this process, which is not good, you must ensure that everyone who does the process follows a consistent method. Are you sure that Joanne does it the same way? I heard Pete has some hand-written notes on his build doc. Are they updates we all should have?
How can you ensure that a server, app, cloud instance, VPC, or any of an array of things are being configured the same way? How do we know it’s also the right way?
Composable Processes FTW!
Whether it is the “right” way or not, using a repeatable and composable process to deploy your infrastructure ensures consistency.
Even if your build document is 100% accurate at that particular moment, what happens when you realize that you need to change the process? How do you retrofit the existing environment?
If you’re using configuration management to do patching, you’re already closer to composable processes. Why wouldn’t you use the same system to do the initial deployments?
When you use a composable infrastructure mindset to do things it changes the game in the best ways. You get:
- scale potential
- continuous operations management
Rather than deploying something once by hand and then fixing it with a system (patch management, script deployments, or other), why not make that first step a composable process too?
Find me an “it’s just easier to do it by hand” process and I’ll find you someone that saved you that step some way in their infrastructure. I can tell you of literally hundreds of times in my career where I was told that scripting some process wasn’t necessary because it only needed to happen once. Then hours, days, or sometimes weeks later, it was discovered that the process needed to happen again, but on many instances.
It isn’t difficult to do the math on the value of automation and composable infrastructure. Even if it isn’t looking like it’s job-affecting for you now, remember that the next batch of sysadmins will have been trained on it out of the gate. Being able to be efficient, consistent, and tonscale your processes is a win for you and for your company.
And besides that, it saves some printer ink.