Maybe your baby is a mainframe: a hulking, brobdingnagian incarnation of ancient victories over mechanics, electrical engineering, and heat. Or maybe your baby is a farmette of Metaframe XP servers on Windows 2000 Server Advanced, erstwhile wonder of desktop abstraction and application management. But for many readers of this blog, your baby is vSphere.
vSphere disrupted the mid 2000's data center in ways we couldn't compare to other technologies at the time. Now, we'd likely call vSphere the Uber of the data center, or the Airbnb of the infrastructure. (Don't get lost in those examples and align them in the VM vs. container holy war). Or drop the metaphor entirely, and close your eyes and remember the last time you were as excited as when you vMotioned your first server.
Many of us saw virtualization for what it was: an opportunity to revolutionize the server delivery infrastructure. But let's be honest: it was also an opportunity to re-invent ourselves in the process. Personally, I went from being an Exchange and Windows geek to a vSphere geek nearly overnight. And the pride associated with building an agency's first vSphere cluster permanently attached a modicum of emotion to an otherwise apathetic project. Eight years ago, my baby was vSphere.
But in the immortal lifespan of IT, no single technology lasts long. The mainframe drove the need to create data centers half a century ago, cavernous, cold rooms which IBM ruled unopposed for decades. But when the microprocessor pushed the mainframe out, server sprawl consumed every bit of floor and rack space in the data center, and facilities managers world-wide rushed to send all of their idling big iron to the great surplus room in the sky (well, maybe they were just turned into razorblades, like battleships years after their violent tendencies succumbed to old age). In any event, revolutions occur in the data center seemingly overnight, and all it takes is one motivated engineer with an idea.
Once you've lived through a tech revolution, you acquire a new perspective on the rate of change in the modern data center. And you subconsciously carry that knowledge forward into every project you complete. You proceed to build sandcastles on the shore, knowing very well that one day a wave will break just right, swallow your castle, and carry it back into the ocean. If you're lucky, you'll get five years of usefulness out of your work.
This rate of change all but ensures that, in IT, nostalgia is irrelevant. IT serves the business, and when better, faster, more efficient methods of serving the business arrive, the instantly-obsolete method is decommissioned, surplussed, and forgotten. Mike Colson, currently with AWS but formerly with Solidfire, made this point in a Twitter thread two months ago:
Colson's correct; there's no room for nostalgia in IT.. @_stump as physical servers, Solaris, DEC VAX, and mainframes were before. IT isn't about nostalgia.— Mike Colson (@Mike_Colson) September 1, 2016
Our industry thrives on what's next, what's ahead. The past is only relevant as a defense of the future state; because the past is old and dated, the future will be new and disruptive.
But there's a major flaw in this line of thinking: IT may principally serve business, but IT is built by people. And people are nothing if not nostalgic.
Over the next several days, I'll be posting vignettes on the people who were tasked with powering down and packing up various technologies that fell victim to extinction-level events in the contemporary data center. And maybe the next time we're ready to post another snarky tweet about the death of a vendor, or the passing of a product, we'll stop, take a deep breath, and remember that behind every product, there's a cluster of humans who poured the measure of their professional worth into that product's success.