Is the Vblock a Monolithic Stack?
This question has come up several times over the past week, and most recently on Kendrick Coleman’s “Finding the True Value in Vblock” post with Duncan Epping of Yellow Bricks asking some great questions. I commented on the post, but I felt this discussion was also worthy of a blog post as the topic is likely to be brought up again.
One observation is that storage I/O patterns will be very different from VDI versus SAP for example. And where I/O patterns are different, there will be opportunities to optimize for that workload. The VCE coalition (VMware/ Cisco/ EMC) has appeared to validate this by releasing special “VDI” and “SAP” editions of the Vblock.
Does this mean we’ll see many different Vblocks for different enterprise applications? Does this mean the Vblock is not quite so universal?
I had wanted to re-word this but in the interest of time, I’m going to just repost the comments I made on Kendrick’s post:
…the type of storage I/O patterns in VDI versus SAP for example will be very different. Right now there are different SKUs for the SAP and VDI configurations.
The concern was raised with at what point do make a new SKU for other enterprise apps and risk fragmentation which would dilute some of the value proposition of the Vblock?
As was pointed out in the conversation, the Vblock is very well tuned for most workloads, but if you are looking at a very specific role, there may be opportunities to customize.
At the very least two things must be true before a SKU/config can be justified:
1) Significant Market demand for the application
2) A significant differentiation from “normal” workload patterns that enables significant optimizations.
A part of #1 I believe is marketing. Customers want to know that their Vblock is certified for x VDI seats or x SAP instances, so that’s a factor in creating a new SKU as well.
When you look at these two things, VDI and OLTP stand out for me and those are basically the 2 variations that exist today (OLTP = SAP). I think these are the big two areas you would want to call out with custom tuning, while the “generic” Vblock still does an excellent job at servicing general/mixed workloads.
So Vblock may not be quite a one size fits all static block, but I don’t think it’s terribly fragmented either (if that makes sense). Excluding the OLTP and VDI workloads, I think the Vblock can be looked at more as a monolithic all-purpose stack.
As always these are just my thoughts as an outside observer and I welcome any other thoughts on this topic.
So while there are different editions of the Vblock, there are reasons behind them and I don’t expect to see many additional editions. It seems that while the Vblock delivers excellent performance with mixed workloads, there are opportunities for optimization in specific scenarios, and this along with marketing reasons is I think why we are seeing different editions.
For a slightly different angle on the Vblock’s value proposition, be sure to read our prior post, “Let Your Fast Zebras Run Free (with a Vblock)”.