Have you hugged your server today?

Disposable IT means never having to fix a broken server, and perhaps never having to know how to fix it

Every now and again I summon that IT veteran affect and harrumph about how today's techs are missing out due to the prevailing winds of newer equals better. Some measure of harrumphing is absolutely necessary from time to time, as it serves as a tether for newer folks to older ideas and foundations. But too much becomes self-serving and leads one to empty grousing among the derelict carcasses of AS/400s and VMS systems.

One recent phenomenon catches me up a bit, however, and definitely deserves an harrumph. That phenomenon is the advent of disposable IT.

As a culture, we frequently lament the times gone by when manufacturing was better, products were better designed, and products lasted longer. We eschew the plastic, modern world and shake our heads and sigh as we throw away yet another broken fixture, appliance, or tool, only to replace it with another of presumably equal shoddiness. “They sure don’t make 'em like they used to,” we say.

One curiosity about that mind set: It’s self-perpetuating. When we point to an old tool or device that’s still working properly decades later, we’re appreciating a durable product that has stood the test of time. That particular piece was designed and built properly, but what we fail to see is the assortment of competing products made at the same time that didn’t survive as long. High praise for longevity is deserved, but it's not indicative of everything built in the same era.

Since the very advent of IT, we have prized longevity. We absolutely rely on solid, uninterruptible design, stable code, and durable parts. Whether it’s a server, a switch, or a data center, it all needs to function as smoothly as possible for as long as possible. Until recently, that included general-purpose operating systems, but those days seem to be passing us by.

The rise of virtualization of every flavor has given us tremendous tools with which to increase reliability, stability, and scalability of every aspect of IT. We can do things now at a whim that previously may have taken weeks of prior planning and led to white-knuckle adventures that threatened us with the specter of hours or days of data restores from tape, all due to a single misstep. These days we simply revert to a snapshot in an instant and go on our way. But think about what we lose here: an entire level of experience, knowledge, and understanding. We don’t really fix things anymore. We simply revert back to a known-good state.

From an ops point of view, this may not seem like a big deal. In fact, it’s infinitely better than the alternative. If faced with one option that requires hours getting elbow deep in some operating system or database corruption problem, sussing out the root cause and actually fixing the issue, and a second option that is essentially a glorified undo button and exactly as speedy, those concerned with downtime will go for the latter at every opportunity. Those concerned with the overall health of their infrastructure will snapshot or clone the damaged system first, however, and spend some time digging through a root-cause analysis in order to figure out exactly what happened and how to prepare for the next time it occurs -- because it usually will.

Alas, not many of us have the time for such luxuries. We “fix” it as quickly as possible and move on to the next problem. We used to get attached to our servers, give them real names, and monitor their every move in order to maintain their health. We’d experience moments of reflection and nostalgia when they were retired in favor of bigger, faster hardware, then fixate on the new iron in the same way. Today we spin up and destroy VMs as needed -- anonymous, templated, soulless workhorses that don’t exist long enough to develop a personality.

Of course this isn’t a universal truth. Plenty of physical servers are still out there, cared for by attentive admins, as well as many virtual servers that are viewed as critical and as indispensable as their physical counterparts and treated accordingly.

Take this harrumph as it’s meant -- to both celebrate the tools we now enjoy and as a caution against getting too comfortable with the new concept of disposable IT.

Copyright © 2015 IDG Communications, Inc.

How to choose a low-code development platform