The Ins and Outs of Technology Currency

No, I’m not talking about Apple Pay, Google Wallet, Bitcoin, or even using technology as a payment option. I’m talking about keeping your technology up to date. Those of you that know me for my role in Fiber Channel storage, know that I am a real pain in the rear when it comes to keeping current on SAN fabric code levels, array microcode and when we have visibility to it, (this includes drive level firmware). My insistence on a regular cadence of planned upgrades for storage accomplishes some necessary fundamental objectives. 

It creates a regular audit point (much to the chagrin of others)

For technology currency actions that require path loss on a fabric/host/array, we require host teams to do an additional pre and post check prior to the maintenance event. This isn’t because we don’t trust automated systems to alert us. We want to make sure everything is working the way it is supposed to regardless of if you have received an alert/ticket. 

It Tests System Resiliency

When a host path does go down, and let’s be honest-one will go down somewhere/somehow. We have software and redundant discrete paths that should allow for no interruption in data availability. Keeping on target code (defined as N-1 where N is current Generally Available code level) helps not only to insure that you have as many known defects fixed as N-1 allows for, but also insulates you, the customer, from the ever infuriating vendor rhetoric: “You’re on an old version of code with known issues of which you are likely experiencing, please upgrade your code and then we can take fresh logs if the event occurs again.” 

Security

Code releases are just as likely to fix vulnerabilities (Denial of Service, arbitrary code execution, etc.) as they are to fix defects (memory leaks, CPU deadlocks, etc.). To keep your systems secure, you need to keep them on current levels of code.

These objectives in the storage infrastructure domain are obvious, however, they can also be applied to other infrastructure/systems.  I have expanded my scope of responsibility over the years which has offered me the opportunity to work with many customers, integrate with their teams, and be introduced to technologies that I knew of. When I retained responsibility leading the Ensono Middleware team, I added to my portfolio technologies including jBoss, Tomcat, Apache, WebSphere, SSL management, and BigIP (loadbalancers in general).  As I learned more about these technologies, it became apparent that they require the same care and feeding that storage did, maybe even more. This is due to their close integration with the applications that power the business as well as integration with the underlying Operating Systems.

So what does all this mean? In short, we can no longer live in the world of “If it ain’t broke don’t fix it”. We need to be proactive at making sure our systems are at current, supportable releases.  We need to do this not just because it is the right thing to do, but because it will iteratively make our systems more secure, resilient, and available in the long term. My personal opinion is that I would rather proactively execute a planned upgrade that introduces a new defect and have to roll back, remediate and reschedule. This is better than being exposed to an unplanned outage or security situation resulting in an emergency and unplanned code upgrade.