So, who drives an Alfa? I love them but I don't own one. Why? Well, I have no dealer near me. Now, what if I owned a taxi service and loved Alfas AND had a nearby dealer - would I run my taxi fleet on them? Probably not because my profit would depend on a mix of dealer costs, fuel economy, reliability, resale value, etc. Ford, Mercedes and Skoda win out based on what I see at the rank. If an Alfa was cheaper than a Ford, more reliable than a Ford, had better physical security than a Ford, had a better dealer network than Ford, had strong resale value, then we would all drive them over a boring Ford / VW / Skoka, etc because they are absolutely gorgeous. However, the answer to most of these points is in the negative. Net, you drive an Alfa because you love it, not because it makes economic sense...
In EXACTLY the same way Enterprise customers look at infrastructure vendors. Their vendor decision is based on product functionality, purchase & 5 year maint costs, geographic data centre distribution, stack support, company stability, performance and RTO/RPO requirements, etc. In the end, the enterprise storage decision is based on delivering a service and not just cool technology, although sometimes (mercifully) that comes into play. Sorry if that offends the propeller heads and university students.
So many new vendors can't sell their great technology to the enterprise because:
1. They are more expensive than the incumbent. Yes folks, when you have a 5+PB estate, in most cases the new guy with the cool new features costs more than the established stuff. So, we make an assessment of the benefits of the new functionality vs the cost saved and effort to deploy. In most cases the new stuff fails to deliver on this and hence does not get purchased. Every now and again something great happens, eg DataDomain before EMC purchased, FusionIO, 3PAR for some customers, etc, but generally new products fail on cost. Maybe that’s what Mike means on the ‘loss leader’ comment.
2. They don't have support coverage. Yes folks, I need to put storage in all kinds of places in addition to main hubs. Most new guys can't support a global model and hence, regrettably, don't make it. Please come back later when you've built out.
3. They are not secure. Sorry, but if you release a great product on a non-locked down version of Fedora then don't expect many enterprise customers. The pen test will find a heap of holes. Understandably VCs don't think about this stuff when investing in a new company but if it's going to make it to production this is mandatory. Come back when you’ve built in security. Maybe I’ll help you with identifying your gaps if your new technology is good enough.
4. They are not manageable. If I select a vendor I'll be buying tens (possibly hundreds) of devices and/or deploying your software widely. That means I need centralised management, reporting, patching, etc. A basic CLI doesn’t cut it. Again, if there is core value I may help you define the enterprise management requirements.
5. They are on a shaky financial footing. For anyone who nearly bought Neoscale or CreekPath a few years back you'll know what I'm talking about.
6. They have no global account management. If I commit to a vendor then I expect professional pre- and post-sales support. I also expect time-to-fix SLAs. Don't expect to sell to the enterprise without it.
7. They are a one trick pony. If you have great in-line de-dupe but lack some other key stuff (could be effective controller clustering, reporting, etc) then you won't cut it.
8. They don't support all my OSs. I have a heap of OSs. Solaris, SUSE & RedHat, HPUX, VMS, AIX, Windows. And then I have all kinds of databases and apps on top. Not only does the storage vendor need to support the stack but I ALSO need the HBA vendor, server, OS and DB vendor to support the storage. I get that from IBM, EMC, NetApp, HDS and believe me it is EXPENSIVE to maintain for the storage vendor. Most small guys focus on just a few which stops the enterprise customer from deploying widely. Maybe if the technology is good enough we'll work on a plan to support my other OSs.
9. Reliability - and evidence of it. ‘nuff said.
All of this is intensely frustrating. I would have loved to see some of the great block virtualistion / in line de-dupe / compression / tiering / bla bla bolted into VMAX, USP, DS8000 sooner (heck, VMAX now has what 3PAR had 6 years ago) but it takes years for the big guys to implement this stuff because they have such a substantial legacy tail to support in their code..
So, here is the dilemma and the key pivot point. Do deploy a few highly specialised devices as an exception just for maybe one application? If there is genuine benefit AND I can support it AND it is secure AND I can put it into all the necessary DataCenters, then the answer will be ‘yes’. But there had better be a damn good reason because it increases my operational disk, makes my environment more complex, adds another vendor to negotiate with, etc. The pivot point is this: I run a business service and not a technology research lab. All my decisions revolve around that and it is the reason why enterprises tend to buy well rounded established products rather than start up kit because it lowers my overall cost AND risk. Meanwhile, we constantly review the newcomers, investigate, test, etc. We use that information to push the small guys to build in enterprise features so that we can actually buy it and push the big guys to either buy the small guys or introduce equivalent technology. And we always negotiate the heck out of every deal to get lowest possible purchase price.
Maybe some of the posters on here are pure-play engineers who don’t care about TCO and service: you have my sympathy but you are not seeing the big enterprise picture.
I drove to work today: I saw no Alfas. Shame, I love them.