EMC World 2011, VCE Recap: It's All About the Vblocks, Baby...
I apologize that this post is so long in coming. Thanks to everyone who asked if I had more content coming, I’ll try and get everything dumped over the next couple days. I appreciate everyone’s patience!
-----
On a day that saw 13 different notices put out by the EMC PR team, of course the one that made me the most happy was the announcement of the 300-Series Vblock™ platform and the rebranding of the “Type 2” Vblocks™ as the 700-Series. On the face of it, the refresh from the Celerra/CLARiiON to the VNX is pretty logical, and is keeping the platforms up-to-date with the latest and greatest from the parent companies, and that’s certainly part of it. But what this also signifies is how VCE is learning from their customers and partners, and working to streamline the process for everyone involved. Ultimately this is a great thing for the customer, but it is also designed to be very good for partners and for the parent company sales teams as well. Want more details, read on…
Originally, there were four iterations of the Vblock™ platforms, and they looked something like this:
While the four models did present a continuum, and each represented the ability to run a set number of standard workloads, the challenge was that the “buckets” were pretty large, and customers didn’t always fit neatly into them. There were also some initial requirements that came along with the Vblock™ that gave people the impression that it wasn’t a “flexible” platform, something that certainly wasn’t true. For customers who had use cases that didn’t fit easily into one of the four models, a process of approving “exceptions” was put in place to allow customers the flexibility they needed. While the customers weren’t impacted by this exception approval process, it created a ton of overhead internally. Essentially, by creating a small number of large buckets, the majority of the customer designs that were coming through required an exception, and that situation needed streamlining.
The VCE Platform Engineering team sat down and tried to answer the question “How do we make it so that 80% of the customer requirements can be handled without any exceptions to the base model configuration, yet maintain the flexibility to accommodate the 20% of customers who’s use cases are outside the norm?” With the introduction of the 300-Series and rebranding of the 700-Series, the public is getting the first glimpse as to how VCE will handle that.
The first step was to expand the number of “buckets” in order to more closely match the real-world use cases that VCE was seeing from customers. Using the VNX-family of storage arrays, the Type 0 and Type1/1U models have been replaced by the 300-Series, so the whole lineup currently looks like this:
Within the 300-Series, there are four different models, matching up with four of the EMC VNX arrays, each of which allows for both a block-only or unified storage configuration. Kenny Coleman out together a good table of the different models here. Graphically, the 300-Series can be represented like this:
Along with the expanded number of models, and the simplified storage configurations, the 300-Series Vblock™ platforms will have a number of new features in the coming months, including:
- The new UIM 2.1 Provisioning/Operations tool, allowing for streamlined provisioning of the infrastructure, creation of hardware-based service catalogs, and deeper insight and correlation between the VMs and vApps and the infrastructure layers themselves.
- A new generation of drives, storage features and drive types, courtesy of the EMC VNX arrays, including
- Smaller base configurations for customers who want to start small and grow, including
- License-as-you-grow models for UCS chassis and related port licensing
- Smaller UCS blade packs, allowing customers to grow in smaller increments
- New RAID packs that simplify adding storage capacity
- New DAE packs that let customers add disk shelves as they need them, not all at once
- The 300EX model will support direct-attached storage, eliminating the need for additional switch gear for the smallest of environments
- Significantly more storage performance, allowing the 300-Series to scale up into environments where a VMAX-based Vblock™ was the only option
- All of the new and improved array features that the VNX introduces: FAST, FAST Cache, compression, Unisphere, the works...
- The ability to leverage up to 50% of the blades in the system in a non-virtualized fashion. Out commitment to VMware remains as strong as ever, but the reality is that customers still have workloads that need to be run directly on the blades. While this flexibility was always available by exception, it’s now a base feature of the platform.
- The new custom made Panduit racks are stunning (see the picture above), and (in my opinion) being able to remove the EMC-branded storage racks is a huge plus. Coming from a multi-tenant colocation environment, I was never happy with the exposed power switches or the security of the front cover plates. Of course some customers need to have the gear put into their own cabinets, and of course we can accommodate that as well…
The biggest question I’ve gotten so far is about the naming scheme. Obviously there are more changes coming to the full line of Vblocks™, and honestly the naming scheme itself should give you some insight into where we are going. While I can’t share any specifics without a VCE NDA in place, take a look at this, and draw your own conclusions…
If you ARE under a VCE NDA, please reach out to your sales team and ask for an updated roadmap presentation. Under NDA we can fill in a lot of the blanks that aren’t yet public, both on the infrastructure side as well as on the software and solutions side. There’s so much cool stuff happening, I wish I could share it all, but needless to say it’s going to be very good for both existing and new VCE customers, partners and parent company sales teams.
You may be asking, “Why are you spending so much energy on defining models and configurations?” The reason is because we firmly believe that there is incredible value in the product-ization of the infrastructure versus simply providing a reference architecture for customers and partners to build to. I saw someone on Twitter the other day comment that his company had used a reference design to build out an infrastructure design, and while the storage array had arrived he wasn’t expecting the rest for another month. In my experience, that isn’t how customers want to consume. They want to order, they want to know that their order is validated and that it’s going to work when it arrives and they want it to show up and be ready to use.
The only way to do this, and do it at scale, is to create “products” that companies can buy. Don’t get me wrong, this isn’t a lack of flexibility! In fact, being able to provide multiple models of Vblock platforms allows VCE to be able to standardize more of the delivery process while mapping directly to the customer’s requirements, and still retain the ability to approve non-standard configurations as always. This process also allows for a much better support process. There is a significant difference between a “one-call” support model and a “joint” support model. At VCE we have a support organization that is dedicated just to Vblock customers. Any issue, at any level of the infrastructure can be escalated directly and VCE will handle ticket creation, tracking, on-site tasking and further escalation, even if any of those require the involvement of one of the parent companies. We’ve also invested millions of dollars into a VCE-specific ticketing queue that is shared between the three companies. While this helps the parent companies to communicate directly with each other, it also ensures that VCE support is always aware of every ticket that has been opened involving a Vblock. Every serial number for every component in a Vblock that is sold to a customer is tagged within the parent companies ticketing system, and if any ticket is opened referencing one of those flagged serial numbers it will automatically put the ticket into the VCE queue. This means that customers who have a preference or process that would lead to them calling one of the parent companies directly, VCE will still always have visibility to the ticket, will always have the ability to get involved and help with escalation or dispatching and will always be able to provide informational updates on the status of that ticket. In addition to the support desk, we also have joint problem re-creation labs in multiple locations around the world, cooperative engineering groups, the ability to directly leverage the world-class field and support services organizations of EMC and Cisco and a full team of VCE employees to manage the process, including regional customer advocates that customers can interface directly with. Add in the strong and constantly growing partner ecosystem and you have an awful lot of resources that can be brought to bear.
This isn’t “joint” support enabled just because you have a support contract on the hardware, this is VCE Seamless Support that is only available for Vblock customers.
source: vmforsp.typepad.com
