By Jess Males – Technical Consultant
Greybeard Sysadmin
If we give the developers root access,
we’re headed for a disaster of biblical proportions.
Director of IT
What do you mean, “biblical”?
Greybeard Sysadmin
Old Testament, real wrath of God type stuff:
Fire and brimstone coming down from the skies;
human sacrifice; dogs and cats living together; mass hysteria!
As system administrators, we consider ourselves agents of order. We’re charged to keep our systems free of phantoms and the paranormal. Should a forty-foot tall marshmallow man come strolling through our infrastructure, we gear up. In the quote above, developers, armed with root credentials, are one such monster. But we don’t have to fight them directly; infrastructure-as-code gives us better tactics.
One fear is that errant developers, equipped with root, could slime the system, making a mess of our well-ordered systems. But infrastructure-as-code directly combats these situations. Should the wrong directory be deleted then the automation code that built our system can just as easily rebuild that system; simply run the same chef or puppet script that initially configured the system to restore it to the correct state the damage that was done, is repaired.
The reverse of this scenario is that root-equipped developers could fix something, but those fixes never get committed to our infrastructure as code. While this specter may haunt us, it’s no nightmare scenario. Because our infrastructure-as-code is easily replaceable, we should regularly replace it. Having to fix the same problem multiple times should induce those developers into the open (if only to wail in frustration), and that will allow you to capture the changes into code.
Even with these poltergeists deflated, regulatory needs, or other requirements, may prevent us from opening this door to another realm. Consider though, the choices infrastructure-as-code grants us. If it can fight this deeply-held belief, what other options can it enable in your environment?