Technical debt in system administration

Most discussions of “technical debt” understand it as something that afflicts software developers. As automation extends to system administrators, “devops”, and network managers, though, I’ve argued that they, too, will learn how technical debt feels. Here’s a simple “Puppetization” example:

The curse of software: it does what it’s told, not what was intended

An information technology (IT) department has successfully brought its server provisioning under control with Puppet, the popular declarative open-source configuration management tool. “Success” here means that the devops team has confidence its Puppet recipes maintain servers in desired states, with software at specified versions, the ability to roll changes back or forward readily and consistently, the capacity to simulate configuration changes without performing them, and so on. These are all positive qualities, and the team rightly feels pride in the security this infrastructure provides.

Yet technical debt lurks within. The Puppet recipes duplicate information, including SSH authorized keys, lists of related servers, and locations of sources for various resource. The inevitable result: occasionally, when a configuration is updated–for example, a new server is introduced in the pool of licensed file converters for a particular bottleneck–one of the lists is left un-updated. At that point, definitions that were supposed to be copies of each other become near-copies. The consequence: it’s only weeks or months later that someone notices the organization is paying for under-utilized (or even inactive!) resources.

No harsh criticism is intended. Programmers know that even the best practitioners are prone to such mishaps. As discussed before, technical debt is not all bad. What’s new now, though, is that a cohort of sysads and network managers have just begun with software-defined configurations, and they have little background in use of variables, conditionals, and other technical devices to bring technical debt under control.

That’s the message, then, for this wave of virtualizers, infrastructure-as-a-service consumers, and datacenter automators: recognize that professionalism requires not only careful configuration so that systems work correctly. Beyond that, the configurations also demand on-going maintenance, adjustment, and refinement. That unglamorous follow-up pays the technical debt unavoidable when systems are first designed and implemented.

Leave a Reply

Your email address will not be published. Required fields are marked *