January 15, 2014
One thing that I’ve learned about bandwagons is that, sometimes, they can run you over. Based on the some of the responses to my last blog on SDDC, there are more than a few of you out there who view my opinions on the subject as metaphorical road kill. Believe me, I understand. When someone says that the Holy Grail was really just a Dixie cup, someone’s feelings are going to get hurt. Hurt feelings aside, I stand by my concerns that SDDC is a whole lot more sizzle than steak.
First of all, I like my panaceas to be a little more defined. Right now, trying to find a clear definition of SDDC is the industry equivalent of nailing Jell-O to the wall. Most recently, SDDC advocates have expanded the purpose of SDDC to include power and space capacity. For those of you old enough to understand the reference, shouldn’t we insist that it also makes “wonderful julienne fries”? While this definitional “moving target” lets more people into the game, it doesn’t exactly specify the end product.
While being able to control and automate the operations of your data center from a single management console is a worthy goal, it just seems to me that there is still a lot of low hanging fruit out there that will deliver more immediate value. For example, since we all want to increase the efficiency of our operations, couldn’t we better achieve this through identifying the waste in our power and space usage? The development of tool sets that enable you to view your application resources in terms of power and space would seem to offer real near term value. Although some firms, like eBay, have developed their own, there is still no viable commercial “dashboard” that enables an end user to view the interaction of our data center software and hardware. In short, shouldn’t we focus on visibility first? Perhaps, the best way to ultimately arrive at a true SDDC solution is to start with making sure that the end user has visibility into every facet of their operations. It seems that the emphasis on SDDC is kind of like exploring the forest at night without a flashlight. Interesting, yes. Productive, not so much.
Certainly, companies are free to develop any products that they desire, and industry pundits can pontificate on any subject they wish, but customers should probably have a view of their environment before they define the SDDC. I’m sure that for many, being able to actually see and understand their software/hardware relationships will be seen as the logical precursor to identifying what they would like to automate. In a sense, isn’t focusing on SDDC a little like skipping to the end of a book? Sure, you find out who did it, but isn’t it just as important to know what they did?