We all enjoy it when vendors face off on key technologies -- like next-generation server architectures.
Not only is it fun to watch, but intense competitive pressures are good for customers and good for the industry. And we've only seen the first few salvos in what should prove to be a sustained battle for data center supremacy
Now, my biases should be clear (rooting for Cisco!) -- but, with the latest round of HP announcements, you can begin to see some very distinct differences in architectural thinking between the two companies.
Two Views Of Management
Now, keep in mind that I'm reading the same public materials that you are, but one thing that jumped out at me was separate views regarding management at scale. HP seems to have one view, Cisco another.
Cisco is promoting the view that the fundamental paradigm of resource management needs to change. Rather than thinking about discrete resource management disciplines (server, network, storage, etc.), we'll all be far better off if we start thinking of every resource as a network service.
Now, if you've built your career on a different management paradigm, you may have an adverse reaction to this line of thinking, but it has a certain persuasiveness to it. The NOC is turning into a busy place indeed -- it's the first call when there's a service delivery problem, or there's a security problem, etc.
Why not extend this model to provisioning of resources? While you're provisioning connectivity between user and application, application and application, application and storage -- why not provision some compute, some storage and an applicationt template as well?
Another way of approaching this argument is to acknowledge that converged IT operations is inevitable -- but what discipline should be the core? Hard to dispute that the network people are best positioned to extend what they do into new areas.
And, finally, as we start thinking about private clouds, dynamically shifting workloads, federation, etc. -- it's hard to describe resources as anything other than a network service, if you think about it.
By comparison, HP is not attempting to debate the underlying resource management model. Servers are servers, storage is storage, network is network, etc. Their argument is that by creating an even-higher-level abstraction (templates), speed and scale of management can be achieved.
My counter to this is simple -- templated workflows are table stakes in any next-gen management model -- no new thinking here. The underlying model hasn't changed to allow better integration of core workflows.
I keep thinking of attempting to put nice wallpaper over something considerably less pretty.
Two Views Of Storage
Cisco has elected to partner with best-of-breed storage providers for UCS (think EMC!). I think they realized that storage and related information management disciplines are core to next-gen data center environments, and that it made sense to partner with industry leaders.
Smart strategic move, IMHO.
HP hasn't really figured out storage for these environments, IMHO. As an example, I'd point to HP's stated approach of 'blading everything' -- including storage. This is what happens when server guys get involved with storage -- everything has to be a server, even things that are better not being a server -- like storage.
If I followed the announcement material correctly, HP is now offering modest-capacity "storage blades", and repurposing LeftHand's software to cluster multiple images to create a "internal server SAN" or somesuch.
Definitely clever. But is it useful?
I would argue that -- not only is this a sub-optimal approach to storage design -- it will severely limit how and where the HP blade farm can be used to support real-world workloads.
Bad strategic move, IMHO.
I was quite intrigued with LH's approach a while back, but -- the more I thought about it -- I realized it had some pretty severe limitations. The larger your environment got, the more apparent these limitations became.
First, you might as well forget demanding OLTP. There's no support for non-volatile cache (either DRAM or flash) using this approach, so every write has to go safely to disk (actually, two disks). Right away, an entire chunk of the workload spectrum isn't up for consideration.
Second, this approach is very wasteful in storage capacity. Unless you don't care about losing access to your data due to server failure, each byte has to be written on two separate blades. That's a 100% penalty on top of any RAID processing that's local to the blade. Yuch.
Third, while it's true you can share storage within a blade rack, there's no sharing of storage across blade racks. That is, unless you decide to turn your HP blade rack into an NFS server, but that's another can of worms.
Fourth, there's a long list of advanced storage functionality found in most enterprise arrays that just isn't available with this approach. Hope you didn't want or need any of that.
Two Views Of Networking
A key proposition of Cisco's vision is unified data center networking -- the converged fabric. Regardless how you might feel about things like FCoE, there is no arguing that fewer, converged network pipes are better than many differentiated ones in terms of economics, operations, power and cooling, rack space, etc. etc. etc.
HP doesn't have much to say about this important development in data center networks. And, for really demanding workloads, trying to run everything through IP-based protocols iSCSI or NFS just won't cut it. And there's no amount of hand-waving that will convince large enterprises of this.
Re-packaging Vs. Re-engineering
If I had to share one important dynamic in all of this, it'd be my perception that HP is doing a lot of re-packaging to meet Cisco's onslaught.
By comparison, we're seeing Cisco do major re-engineering around how we think about data center architectures: unified computing, virtualization by default, unified networking, converged management models, etc.
From where I sit, the differences couldn't be clearer :-)