2013 has become the year where discussions around software-defined data centers, networking and storage have gone mainstream. But when I talk with end-users from a number of organizations, they are somewhat scratching their head over why there is so much buzz over this technology. Most are looking to acquire and deploy technologies in their environments that are simpler to deploy and manage – not harder. As such, they sense these new software-defined solutions may only take them back in time to a place they do not want to be.
I get why organizations may express interest to vendors in technologies like software-defined networking (SDN), software-defined storage (SDS) and software-defined data centers (SDDC). Organizations potentially get enterprise level software, run it on off-the-shelf hardware and save boatloads of money in the process.
More importantly, software tends to have a longer shelf life than hardware (10-15 years for software versus 3-5 years for hardware.) As such, once this software is setup and running, the real savings show up over time when companies can acquire more hardware without having to necessarily acquire new software to run it. That aspect of SDDC, SDN and SDS clearly has appeal to organizations.
Yet there are enough drawbacks associated with these software-defined solutions that most organizations will conclude this is not the right course of action for them to pursue. Software-defined solutions that are software only and not accompanied by any hardware solution are probably destined for niche deployments that are used by a limited number of companies at best. Here is why:
- Companies buy hardware, not software. This mentality is probably best summed up by a past experience that I had when I used to work as a storage engineer. At the time, I was looking to implement storage virtualization in my company’s data center but it was only available as software. When I presented this idea to my Senior VP who was over the data center, he jokingly told me, “I only pay for hardware. Software is free.”
While he made the comment to me in jest, it revealed a mindset that is more prevalent than not in enterprise IT data center shops. Companies are NOT inclined to pay for software alone and then let their IT staff buy all the needed hardware pieces and parts, assemble and configure the solution and then support it and make it work. They know from experience this approach is fraught with risk. As such, the overwhelming number of companies prefers to buy preconfigured, ready-to-run solutions.
- Vendors routinely overstate their ability to manage everything in the datacenter. This past spring when I was attending EMC World it was rolling out and demonstrating the virtues of its new release of ViPR. Of course, on stage it looked great and performed flawlessly as one would expect (and hope.) But for the most part it was only managing the latest and greatest EMC technologies.
This is great for those organizations that only run the newest EMC gear (in a green field deployment.) Yet what about the organization that may still have an EMC Symmetrix 8830 faithfully chugging away? Or that still runs multiple EMC Clarrion arrays (the predecessor to the VNX)? Or have storage and networking gear from competitors that is not on the supported list for ViPR? When and how will ViPR support them? My guess is never.
Now you end up with an IT data center that is partially managed by ViPR and partially not managed by ViPR. In common IT vernacular, this is (in polite terms) called a mess. Further, is this software-defined solution really any better than what most organizations have now? I would argue no.
- Who gets blamed when things go south? This is the million dollar question for which any IT manager or director worth his salt better be able to answer as every solution goes south at some point. In today’s world, if you buy all of your hardware and software from one vendor who provided a solution based on specifications you provided and it does not work, you may at least have the option of blaming the vendor, removing their gear and bringing in a new solution. Software-defined technologies running atop hardware from multiple vendors that you have configured yourself removes that option. If it goes south and your organization opts to play the blame game, odds are it is YOU who gets blamed.
- Who do you call? Even before the blame game begins after an application goes south, organizations want someone to call to help them resolve whatever issue they are having. But who do you call and how qualified are they to resolve the issue? The software-defined solution provider may know its software but may have no exposure, understanding or ability to diagnose the underlying hardware on which it is running. Most companies and certainly most enterprises are accustomed to having 1, 2 and even 3 levels of support. Having no one to call to ensure the solution is configured correctly–much less when things go wrong–is not a solution most organizations want deployed anywhere.
Software-defined technologies have their place in organizations but organizations really need to closely examine how to best deploy and implement them or if they should do so at all. Based on what DCIG and its analysts have seen to date, the best way for most companies to take advantage of any form of software-defined solution is to either buy it when it is included with a converged infrastructure or datacenter-in-a-box solution or as part of a private cloud reference architecture solution. This is why DCIG is currently developing Buyer’s Guides on these two topics and not on any software-defined solution that is solely software.
The only organizations who may want to take advantage of software-defined technologies that use hardware from multiple providers are those organizations where IT is their business and who can internally support what they build such as cloud service providers.
Most organizations should largely steer clear of this technology or only acquire it when it is part of another solution. In this way they can remain focused on their core competency (serving hamburgers, delivering boxes, making pudding cups, whatever.) Software-defined solutions that are solely software only stand to waste precious time and resources while taking most organizations back to a place in time that they do not want to be.