Technology integration makes computing products much easier to use and significantly drives down the cost and effort of owning it. For instance, technologies such as WiFi that were recently beyond the grasp of most people are now inexpensively integrated into PCs and usable by almost anyone.
The trick with integration is understanding what variables should be exposed - or as my friend Rick Vanover likes to say - how many knobs there are to turn. End user and infrastructure provider requirements differ considerably when it comes to knobs. For instance, Apple computers are great end user machines because they lack knobs, but are not always loved by technology professionals for the same reason. Data center operators need products with knobs in order to accommodate all the cross-purposed requirements that stretch beyond a one-size-fits-all design.
So knobs are generally good - but like so many things - their usefulness depends on how effective they are and their station in FARLEY'S HIERARCHY OF KNOBS, which includes the following levels:
Suicide Knobs: knobs that delete data and make things blow up. A good example of a Suicide Knob is something that formats storage.
Prison Knobs: knobs that make changes that are very difficult or impossible to reverse. Many storage provisioning knobs fall into this category. Once you provision and reserve storage with most storage arrays today you are stuck with that decision until the array's EOL.
Faux Knobs: knobs that never seem to do anything, no matter how far you turn them. For features past and future, but not now.
Random Knobs: knobs that produce unanticipated results that can go unnoticed for years. These are the knobs that fuel the technical publishing industry.
Slippery Slope Knobs: knobs that start you down a path to ruin through a chain of system dependencies. These are the knobs you spend a lot of money to learn about in vendor classes.
Dumb Ass Knobs: knobs that do things, but not anything useful. Granted there is a LOT of subjectivity in making a call on a dumb ass knob - but we all agree they exist.
Honest Knobs: knobs that actually do something you need them to without having to plan for weeks on how to use them. Most knobs should fall into this category, but alas!
Magic Knobs: knobs that do things so useful it makes you wonder how anybody thought of a knob like that. Most of these knobs are actually Honest Knobs, but we are so accustomed to seeing Suicide, Prison, Faux, Random, Slippery Slope and Dumb Ass knobs that we are blown away by a truly great Honest Knob.
Which brings me indirectly to the discussion of STACK WARS, which, have been centered around the announcement of VCE (VMware\Cisco\EMC) and their vBlock concept last November.
I'd like to say I was surprised yesterday when graphically-challenged Hitachi announced their intention to sell their own Unified Cloud Graphic, (complete with Hitachi compute servers!). But it wasn't a big shock considering their marketing strategy of "just copy it".
I really don't know how they expect their graphic to compete with vBlock's graphic, with all the color, multiple font sizes and graphics within graphics.
What's missing from the both stack graphics are the knobs that administrators use to get real work done. Yes, knobs tend to be part of the underlying details, but to anybody that actually uses a product, they are very important details. The detail that C-level executives need to understand is that the stack does not have nearly the automation that is being promised today and that administrators will be doing a lot of work, turning the knobs that the stack provides. Again, it's not the number of knobs that matters, as much as it is the quality of those knobs.
Some people have speculated that the vBlock was a knob-less invention that originated in the board rooms of the VCE companies. Some have even suggested that it was the fallout after a failed acquisition bid by Cisco to acquire EMC. I don't know if THAT's true, but there is some evidence that the engineering groups in the companies involved have been scrambling to put meat on the bone.
Maybe someday stacks will be the next big thing, but I don't see it playing out that way unless an awful lot changes in the underlying products that make up the stack. Here's my take on STACK WARS:
STACK WARS give everybody something to write about- me included, right now!
Bloggers that write about stacks have a chance of getting jobs with stack vendors. If you are out of a job, start a stack blog today and twitter your back-stack off!
Stacks are all about packaging. Stacks will be assembled and shipped together (presumably), which could make things easier if your goal is to streamline receiving.
Stack products, are actually more services than products. However, if you ever want to make configuration changes in your stack it might not be economically feasible. (Think gigantic FRUs) For example, there is not a lot of flexibility in vBlock's configurations.
Due to the limited configuration options, stack resources are not likely to be used very efficiently and the economic return on the investment will lag. However, EMC customers are already accustomed to low storage utilization levels - so poor utilization might not be THAT big a deal. Definitely a weird way to win a point, but I 'll concede it grudgingly.
The business advantage of integration should be much lower costs. However, the VCE companies all need to maintain their margins if they want to satisfy investors. It's not clear how they will be able to leverage the integration effort to reduce the cost of vBlock, but then again if STACK WARS turn into PRICING WARS for STACKS, things could get very interesting. IBM must be STACKING up something - after all Hitachi already beat them to the punch.
The C level view of stacks are that they smooth out purchasing and operations expenses by providing a smaller number of Purchasing Knobs (that would be a Faux Knob). John Nash posted in his blog last week,"The Case for the vBlock":
What is interesting is that, usually, the higher up in an organization you are communicating the better the Vblock conversation goes. Remove the detailed technical questions and the value of the Vblock idea really shines. You get a known “product” from trusted sources. You get known costs today as well as known costs for future expansion. It greatly removes the risk from the organization with unknown infrastructure expenses.
There you have it, vBlocks will be sold from the top down by Cisco and EMC - companies that are good at selling from the top down, which will make it somewhat easier for the VCE companies to justify their price tag. But that won't make the price any easier to swallow.
As Nash wrote, "remove the detailed technical questions and the value of the Vblock idea really shines." That's like saying chapulines (fried grasshoppers) might appeal if Anthony Bourdain is talking about them on TV, but your own personal experience chewing and swallowing them might be different. I'm not talking about price here, I'm referring to the experience of running the vBlock. There is going to be a lot more involved than the knob-less graphics portray.The weakest link in the vBlock chain today is EMC's contribution. There are far too many Prison (provisioning) and Slippery Slope Knobs in EMC storage. They aren't the only vendor with this problem, but they are the E in VCE. Provisioning storage with a v-Max is the about the same as it was with a DMX - despite what EMC employees would have you believe.
Prison Knob provisioning creates a lot of problems for customers as storage ages and as demands shift. Once storage has been reserved for usage in an EMC system, it is pretty much bound to that purpose.
My advice is to buy the products with the most Magic Knobs and avoid those with the most Prison provisioning Knobs. If you have ever felt trapped by a storage configuration that you couldn't live with or afford, you know what I'm talking about. Magic Knobs are those that reduce the effort to manage and change storage, increase the efficiency of storage and provide the most versatility for all applications, workloads and multi-tenancy.
"You get known costs today as well as known costs for future expansion."
Yeah, known costs so you know it won't be cost effective really at any scale.
If it costs $2M to deploy for example, and you know it will cost another $1M to upgrade, compared to another better/faster/cheaper $600k system which you know you can double in capacity for at worst another $600k...
I went through this recently with cloud players, one of them wanted to charge $3M for installation on their UCS platform. I could literally build four full sites before I got close to their $3M number. And still save tons of money on the hosting fees.
Using superior equipment at the same time. It's not like I was building the cheapest of the cheap boxes. But I wasn't stupid to fork out $100,000 in memory for a dual socket server.
People kept bringing up "well is your organization able to handle managing that much equipment". And I would say - DUDE it's ONE storage array, and its EIGHT servers(very powerful ones), the entire thing fits in less than TWO RACKS. ITS NOT THAT COMPLICATED.
And when it comes down to it in a lot of cases the "stack" really doesn't seem to mean much once you get into the hypervisor at that point it seems most things are managed by that.
At least that company had the balls to quote us, three others declined to even quote because they ran the numbers and knew they were not cost effective. I had a good conversation with one of the company's lead engineers, very honest and nice person, he knew what I was talking about.
Posted by: nate | April 21, 2010 at 12:35 AM
love this article - its oh so true... Stackwars have been going on for ages, just a little more primitive... now the vendors have now started to put together their *own* stacks - it gets even more intersting (or confusing?) to watch...
There are those that believe the end-to-end stacks in high up management places
There are those that can see beyond the idle promise and see what it really takes to make things work and the real cost of ownership / change etc...
One other point.. TCO for these *stacks* has anyone ever seen a *real* one??? i just have never a model that actually proves that this lot of hype has any mileage in it. I am not saying it doesnt, i just need to see proof.
Be it VCE, VCN, Hitachi, Oracle etc etc etc... its got a long way to go to prove any of the hype
Intresting that all these "Cloud" ideas presume that cloud services should always be based on hypervisor technologies also... Still dont get that (guess I am going into a different rant now!)
Laters!
Posted by: Stuart Savill | April 21, 2010 at 05:27 PM
Nate, you certainly have a very direct way of shedding light on things otherwise obscured by the cloud!
Stuart, great point about the commonality of the hypervisor.... Hmmmm.... Can a stack survive in a hypervisor-free universe? If the hypervisor actually makes the stack work, why would anybody pay more for a stack or not try to put together the best possible solution for their needs.
As Nate put it: "DUDE it's ONE storage array, and its EIGHT servers(very powerful ones), the entire thing fits in less than TWO RACKS. ITS NOT THAT COMPLICATED."
Do the people running technology really want to abdicate their responsibility by buying stacks? I doubt it.
Posted by: marc farley | April 22, 2010 at 10:02 AM