More Lefthanded Opinion On The HP Acquisition

Well, I've read most of the industry's take on this, and most of it is decidedly different than mine. 

I guess that's a good thing?

But, in addition to the VMware rationale from yesterday, I think there's another angle that many folks might be overlooking -- and, going forward, I think we're going to be hearing more about it.

The Coverage So Far

Many people rationalize this move in terms of iSCSI presence. 

They point to Dell's ginormous EquaLogic acquisition ($1.3b?) and say HP got in cheap.  They point to HP's lack of any substantive iSCSI offer.  They point to the usual sophistry about the emergence and eventual dominance of iSCSI.

Fine.  I'll agree that HP gets an iSCSI offer -- sort of.  Yes, iSCSI is very important in these smaller environments -- no question whatsover.

And the "deal" HP paid for LHN only makes sense if you think that the Dell acquisition made any sort of financial or strategic sense -- and there are decidedly more people these days who are now wondering about the logic of this particular transaction.

If all HP wanted was a dandy iSCSI array to pop into their low-end lineup, there are many, many cheaper ways to get there, aren't there? 

The Siren Song Of Servers As Storage

No, I think there's an angle on this that you can only fully appreciate if you've ever worked for a server vendor -- the insatiable siren song of using servers as storage. 

Sun has succumbed to this with Thumper and similar.  IBM has succumbed to this with the XIV.  Witness HP's previous announcement with Oracle on "data warehousing engines" (which Oracle positioned as storage, something I found a bit bizarre).

There seems to be something that makes server guys really really excited about using their servers as storage.  It's something that they can't just resist.

I've got to believe that this was just part of the appeal to HP -- to have software that would help them leverage their prowess in servers into the storage domain.  I can't wait for Dell to try something similar at some point.

From one point of view, there's nothing really new here -- take any standard server, plop a special version of Windows on it, and you've got yourself a dandy file sharing and iSCSI target, complete with all sorts of useful features.

There's only one tiny problem with this. 

From a storage person's perspective, servers don't make particularly good storage devices for many use typical cases (more on this later) -- they do make sense for a few, however -- and the reasons are pretty fundamental, and have little to do with bias or vendor religion.

And it might be interesting as to why this is the case ...

Going A Bit Deeper

Take a close look at something like a modern CX4. 

Most of the controller parts and components should look pretty familiar, as they come from the same server parts bin that most of us use.  Sure, there are a few custom pieces here and there in key places, but -- generally speaking -- most of the parts are the same, so no real signficant cost savings here.

The disks?  We all pretty much buy the same disks from the same manufacturers.  Volume is the name of the game, and all the larger players have pretty decent volume.  So no real cost advantage here for anyone.

Write-intensive environments like to have nonvolatile cache to write to.  To take ordinary server DRAM and make it nonvolatile (and, hopefully, redundant) takes more parts and a bit more design work.  Whether a storage controller does this, or a server is modified to do this -- it's pretty much the same cost for both parties.

Most environments like a decent amount of high availability.  That means that you have at least two paths to your data.  For most storage arrays, this means a minimum of two controllers, and the ability for each of them to get at any disk if needed, as well as some sort of logic to synchronize state between them in the event of a failover.

But for server-based approaches, this gets a bit harder.  Servers are used to owning the storage within their enclosure -- they don't know how to share internal storage, and they don't know how to share state for failover purposes. 

So this usually results in schemes where there are two copies of the data, one on each server node.  Not a bad thing in smaller environments, but this can get expensive as volumes grow -- not only in terms of disks, but server (controlllers) to support them.

All of this stuff adds costs to server-based approaches as capacity grows and people start wanting some sort of HA, and decent write performance. 

Don't believe me?  Just run usable capacity numbers on any of these server-based approaches when we're talking 20, 30 or 100 disks worth of usable capacity.

Which is why we have a marketplace full of purpose-built storage devices, and very little presence of server-pressed-into-storage-duty approaches.

Keep in mind, there's encroachment from below as well.  All sorts of cute little NAS devices springing up that are ostensibly cheaper, easier to manage and perhaps faster than server-based designs.  And it probably won't be too long before we see them sporting iSCSI targets as well :-) 

Now these server vendors are in an uncomfortable position, strategically speaking.  If it's all about cheap and cheerful, they don't play particularly well.  And if it's all about fast and HA and being capacity efficient -- well -- that's what the storage arrays do.

Should be interesting to see how this plays out, no?

Comments

[Martin G]

Actually there's argument to suggest that IBM started down this road long ago with Shark. I don't think there's anything inherently wrong with the approach, personally I think it's more bizarre what IBM didn't do with Shark as opposed to what they did do.

I would argue that HP and Sun are in an especially uncomfortable position with regards to storage; I think HP know it and are trying to do things to rectify their situation. But Sun seem to be working as hard as possible to annoy the enterprise Storagetek customers and seem to flounder about.

I think IBM have a storage strategy, unfortunately in their own inimitable style, they actually have several. So not for the first time in IBM's history, they will end up competing with themselves.

And as for EMC, just waiting for you guys to go and buy a server vendor (oh right, you did....you just killed the server side). Isn't it about time you bought someone big again??

[Chuck Hollis]

Interesting thoughts as always, Martin.

Anyone in particular you'd have in mind? I mean, we all have our personal lists -- what's yours?

[Martin G]

Who would I buy? Not sure there are any server companies I'd touch at the moment.

Now storage companies and it's a whilst since EMC did. Atrato and Xiotech both have some interesting stuff. I'm surprised EMC haven't picked up ibrix or perhaps even Exanet.

And I keep half-expecting the marriage made in hell and you buy/merge with NetApp. However, that's probably just me being wicked.

[Chuck Hollis]

Having been a close bystander for many years and many acquisitions, I'd offer that you don't really buy a company, you buy a corporate culture.

And, on that basis, I'd demur from your final proposal.

[Ahmad]

My favorite is SUN? Isn't interesting?
good in Software development, brilliant in OS, and some good hardware, ZFS ;), Symantec/Sun marketshare, but the burden of a big organization

[Tom]

Buy a corporate culture?? Please.

You buy technology or you buy Intellectual Property or you buy a customer base. And in doing so you likely crush a corporate culture.

[Steven Schwartz - The SAN Technologist]

In some respects I agree, and in some respects I disagree with you thought on iSCSI. I think people thought the same about NAS 10 years ago, and clearly NAS has firmly found its place in the enterprise.

As for iSCSI, I've said it before, not all iSCSI implementations are created equal, just as not all FC is created equal.

One of my greatest joys in being at Dell, is that for block level storage, we have the best of all worlds.

PS-series, MD, AX, CX, Symm, DMX, etc. all have a good place in storage solutions, none are a silver bullet.

The only thing in storage trends that I don't agree with, are the unified storage platforms, they typically are a Swiss Army knife, not really great at any one thing, even though they can "do" everything.

Only really good thing on my knife?

toothpick and tweezers

[Chuck Hollis]

Hi Ahmad -- yes, there's some interesting pieces at Sun, but without the ability to put it all together and actually make some money, I don't think it will be around in its present form for too long ...

[Mike Dutch]

Your article brings back some IBM memories...

Remember the RAMAC Array Subsystem? It had subsystem and drawer level cache. The cost structure was a killer because when a customer added a new drawer to add capacity they got the electronics too. Kind of like using servers with internal disk to build a storage system, only even more expensive.

The Shark comment reminded me how it started out as a physical machine then morphed into a personality running in a logical partition on an RS/6000 cluster. Again, kind of like using servers with internal disk to build a storage system. Only this time with some server virtualization thrown in.

So yes, this is a very familiar story but after all, isn't everything a bit of a server these days? A common parts strategy isn't so bad as long as it doesn't succumb to greatest common denominator thinking(like using a hugely expensive power supply for both mainframe servers and open system disks).

So what has this got to do with HP/LHN? Perhaps your earlier blog about VMware redefining storage virtualization might have hit upon HP's thinking. VMware adoption seems to be an accelerator for iSCSI. "As server virtualization's fortunes go, there go iSCSI"

[Barry Whyte]

Its working for us in SVC land. The initial code research project was known as COMPASS, Commodity Parts Storage Subsystem. Thats why we can piggy-back on the Intel gaming community and double our bandwidth and IOPs every couple of years....

Shark itself started life as CPSS, Common Parts Storage Subsystem.

There is much to be said for using technology that has already had the cost burden taken by another group, and with the speed of evolution much faster than the ASIC design process, its always going to evolve faster...