Wednesday, July 7, 2010

Comparing NetApp SMT vs. VCE Vblock - Are you a PC or a Mac?

I have seen a nice uptick in interest from my customers in both NetApp's SMT (Secure Multi-Tenancy) and the VCE Coalition's (VMware, Cisco & EMC) Vblock solutions.  This has led me to do a lot of digging and I feel I'm now in the position to objectively compare and contrast them against each other.

How do the compare at a very high level?  

The NetApp's SMT solution has a very PC feel to it.  It feels like one of the fancy "rigs" that you would build yourself for playing high end PC games.  You take a blueprint (reference architecture), build it yourself, upgrade it over time, and turn the "nerd knobs" to suit your tastes. It also has a specific use case.  VCE's Vblock is akin to Macs.  It is an all in one solution that "just works".  It may not be as flexible at times but the idea is that you don't need the "nerd knobs" to do your work on a daily basis.  The approach to each architecture is very different and the best fit for you depends on what you are looking for.

Take Away #1: They are NOT the same solutions with different storage on the backend!

Both solutions attempt to solve customer pain points through the idea of "stacks".  By combining Servers, Network, Virtualization, and Storage into a single solution we are solving many customers Data Center problems in a way that is easier to digest.

Take Away #2: This is a new way to sell (as partners) and digest (as customers) the same technology!  As the solutions required in the Data Center gain complexity, we need a simplified way to tie all the technology together.

How about some more details?

Let's start with NetApp's SMT solution.  Here is a link to the SMT design document & implementation document for more information.  SMT is a reference architecture and framework that is very flexible and can be implemented into an environment in pieces using common technology.  You can't just purchase an SMT solution, you have to design it.  This is both SMT's greatest strength and weakness.  It is very flexible but it requires a team with the knowledge to put all the pieces together.
A second factor that comes into play is that SMT is designed with a specific solution in mind.  SMT provides the ability for multiple tenants to exist on the same set of infrastructure.  Many IT departments and sub organizations are a lot like my five year old, at times she just doesn't play well with others.  Customers historically don't like the idea of "sharing".    SMT is bit like carving up a pie, everybody gets a piece and you don't have to share (or don't know you're sharing!).
The last point to SMT is the ability to migrate your environment over to SMT as time permits.  Swap out the network piece at one point, swap out the servers another time, etc.  This is easier for individual departments to digest.

How does this compare to the VCE coalition's Vblock?

Just take the opposite of everything I just said!  (just kidding, but it is very true)
Vblock is a product, not an architecture.  It is purchased and delivered in a "box" that is configured and ready to go.  You choose the size you need (I have a comparison of the current models here) and you can order it with minimal customization.  It "just works".  There is a misconception that Vblock is a black box of VMs' that you have little or no control over. While it's true that VCE does put guidelines around what hardware is within a given Vblock, there are no limits placed on what can be configured at a software level.
Because Vblock is an orderable solution, there is no fitting this into your environment over time.  You buy, they ship it.  The key point here is the customer will not have to configure it because all implementation will be done up front.

The one big criticism of Vblock I have heard to date is what do you do with it?  SMT solves a technical problem with a solution; Vblock on the other hand provides preconfigured resources.  That is great if preconfigured resources is the problem you are trying to solve.
I would love to see the VCE coalition's message improve here.  Right now the message is "preconfigured resources" but I think it needs to be more than that; we need to use Vblock to provide solutions to customers, not just technology.

I have seen Vblock targeted at upper management (Director/C-Level) to date.  There is simply no other way to get all the departments on the same sales cycle and get them to agree on the solution so that it can be purchased at the same time.  Getting everyone in a circle holding hands and singing KumBaYa and agreeing to purchase a Vblock requires sponsorship.
Here is a summary of my points (again, sorry for the image as a table):

In summary, I love both solutions and I look forward to seeing both evolve over time.  I do believe the future of the Data Center revolves around this type of solution.  What do you think?


Riley said...

What if Vblock is just an interim solution for Cisco?

What happens when Cisco buys ______? <-- insert storage vendor here. Then it'll be a Cblock.

Jim Dowson said...

Interesting analogy, since Phil Harris & I are both Mac users...

Our intention was to make end-to-end reference architectures (i.e. application templates for Exchange, SAP, etc) based on generic building blocks that are differentiated by software functionality, not hardware. An example is the SAP announcement - see

We found that we were developing everything from the ground up - but in the end, it would be of greater value to abstract the foundational HW/SW layers, and concentrate on developing best practices for application deployment. That enables greater utilization of the data center, instead of optimizing a design that will have a lower utilization (e.g x% more efficient, but y% less utilized).

EMC & Cisco still support 'build your own' or 'a la carte' architectures with the same level of support and investment (e.g. eLab testing, and solutions designs with other vendors).

Our intention was for vBlock to be an additional offering (think of it as prix fixe option) that simplified application deployment, and improved solution time to value for our customers. We wanted to enable ISVs and partners to build on top of that foundation, instead of 'playing with plumbing'.

That's what customers were asking for, and we listened - it's where we get our best ideas ;-)

Vaughn Stewart said...

[NetApp employee - full disclosure]

Aaron - I think you;ve hit the nail on the head. Customers need to decide do they want to buy pods/blocks or build a flexible architecture.

One seems to say 'fit your business to the architecture' where the other is 'scale your architecture based on business needs'.

Did you know that SMT is fully supported with Catalyst core switches? Or that the majority of the SMT installs to date are with HP blade servers?

I share these two points to demonstrate the flexibility offered by Cisco NetApp and VMware via SMT.

Enabling customers to accelerate their adoption of virtualization technologies in the goal. Predictive and risk averse are the goals of both vblocks and SMT; however, SMT adds security and the flexibly to work with existing data center assets.

Thank you for sharing your thoughts, it is very valuable to the readers to hear your impressions as one who works for a valued partner of both EMC & NetApp.

Texiwill said...


SMT is a 'stack' that is about carving up storage and paths to the storage. Not really about 'security' per say not anymore than a VBlock is btw. Neither provide Secure Multi Tenancy.

Edward Haletky aka Texiwill

Roger said...

Just a note - you linked to the CVD design guide for SMT. The CVD deployment guide can be found at

Roger said...

[Disclosure - NetApp employee]

Edward: I'm curious what your definition of secure multi-tenancy is.

Craig said...

By the way, for the experience users or architect, VCE may come in to the picture as for marketing and simplified the process of purchase, but in reality, I believe the sizing of each individual VM will be different from time to time. Example here as a vm can consume up to TB of storage, which the next VM can be only require 100GB of storage, vBlock had predefine the number of VM with the config which simplify for beginner to adopt the virtualization in 1 single order and part number, but it may not fit to the advance users. Again, it is depend what you want and you always purchase the right solution that will fit for your architecture blueprint and road map.

Aaron Delp said...

Thank you everyone for the great comments!

@Mr. Dowson, Thank you for taking the time to come by and leave a comment!

@Vaughn - I didn't know that, that you for adding the information

@Texiwill - Edward, I figured you'd be commenting on this one. Thank you! ;)

@Roger - Thank you, I was looking for that link when I wrote this but couldn't find it! I updated the article.

Again, thank you everyone!

Texiwill said...

Hello Roger,

Check out for what I have to say on the subject. The 2nd post I believe holds my current working definition...

Best regards,
Edward aka Texiwill

Brian Gracely said...

Aaron - Nice write-up as always. Couple points of clarification:

1 - It's not "EMC Vblock", it's "VCE Vblock". I understand that some people want to make the distinction about the storage component, but it's actually about the overall level of commitment to the entire solution. Ordering, support, 3rd-party integration, etc.

2 - Your comments about "how it's been positioned" are spot on. People might not believe this, since almost every data-center conversation I hear about or read about starts with VCE or Vblock, but I believe that we haven't done a good enough job yet of articulating the Vblock solution. Can it solve Multi-Tenancy, VDI, Tier-1 App migration, MS-Apps consolidation, IaaS problems - YES. Have we explained that well - NO.

3 - To my previous point, as much as some technical people have complained that Vblock restricts their technical choices, more have actually complained that we haven't been prescriptive enough about all those solutions above. We thought we were being flexible enough by positioning it as "preconfigured resources", but expect that to change rapidly based on market demand.

4 - You won't see Vblock solutions that include HP servers as we don't believe the value of the solution is still there for customers. It adds additional management layers (complexity) and support layers. That doesn't prevent a customer from wrapping V/C/E pieces around legacy HP servers that are still under maintenance agreements in the short-term, but we believe that Cisco UCS is seeing excellent traction in the marketplace going forward.

5 - There is this misperception that Vblock gets ordered and everything else in your data-center goes away. What we're seeing from customers is that Vblock gets ordered when the customer (a) has a greenfield opportunity, (b) an upgrade opportunity, (c) a new IT area rollout, or (d) management wants to "encourage" their IT staff to act more integrated (instead of silo'd). Vblock goes into the data-center and solves one or several of those problems, as a solution. Maybe someday there will be a 100% Vblock data-center, but not today. Plenty of legacy systems still existing around a Vblock.

Thanks for driving the conversations. Lots of good input here.

Aaron Delp said...

@Brian - All good points! I admit I took some "artistic liberty" with the name. If I call it a VCE Vblock many still don't know what they means per se. I call it an EMC Vblock and people notice on Twitter. Sorry, just wanted to drive SEO traffic to the site :)

When I first wrote the article I did reference it as an EMC Vblock and actually went back and changed everything to VCE.

I agree with you on all points! Thanks for the comment!

Andrew said...

I might make an actual technical point some day....but right now I almost consider my Mac more flexible/robust/deeper (take the whole unixy side) than Windows. I'd say what you might be looking more for is iPhone vs. Android (although the iPhone polish might not play in here as much).

Thomas Scheibe said...

(Cisco employee)
Vblock and SMT are two different pieces of the DC architecture. Vblock is an integrated compute stack (multiple options with associated scale ranges exist). Obviously, that stack needs to be connected to the rest of the world via some networking component. SMT is a reference architecture for a DC pod that uses an integrated compute stack (with NetApp storage and Vmware virtualization) and layers around the required networking components.

Russell said...

I'm not sure where you get the idea that the Vblock comes preconfigured and ready to go out of the box. That is definitely not the case in my experience. The Vblock is a BOM that you order yes, but then you have to put it all together. In reality, the SMT deployment guide could almost be used as a workbook for how to deploy a Vblock, with the exception of the storage of course. As I understand it, the alliance formed Acadia should offer the 'preconfigured' solution that you plug in and start using. In my experience with both the SMT guides and the Vblock hardware, I would lean more toward putting the 'Mac' designation on the SMT guides, even though they are just guides. The Vblock is more like that high-end PC you have to put together on your own. The only thing the vendors are saying is that "we've tested the parts in the BOM and we know they will work together".

versace said...

A fair question to ask, which it appears no one is willing to ask or answer here, is "Which is/or can be more secure - SMT with NetApp or a vBlock with security integration IP provided by Acadia? I would add the Oracle VM stack, though targeted to different workloads, to the comparison to make it interesting. To get to the answer, we need a feature/feature comparison and a risk profile, which usually requires assumptions about the application and operating environment.