The Growing Appeal Of Compatible Infrastructure

The seductive logic of a hybrid cloud approach to infrastructure is becoming more apparent to IT organizations everywhere.

Build an internal private cloud for the pieces you want to keep inside.  And turn to external service providers for the bits that are done better by someone else.

And the advent of highly compatible infrastructure at both ends of that conceptual wire is turning out to make the hybrid proposition even *more* attractive.

Leveraging The Growing Ecosystem Of Compatible Service Providers

Let's assume, for the moment, that you're building a fully virtualized private cloud behind your firewall.  A Vblock-type approach has its merits, of course, but there's a bigger picture than just what you're doing inside the data center.

As more and more service providers are deploying Vblocks, an interesting option manifests itself -- the ability to rent the exact same infrastructure from a compatible service provider vs. using internal resources.

And that's turning out to be darn attractive in a way I hadn't fully understood until recently.

It's More Than Just The Technology Components

I'm sure a lot of people reading this will say "sure, but as long as both sides are running VMware, isn't that all you need?".  Well, yes and no.

If both enterprise customer and compatible service provider are using a Vblock, performance expectations are roughly similar.  An arbitrary virtual machine (two cores, 16GB of RAM, 100GB of disk) will perform the same on an "owned" Vblock vs. a "rented" portion of a Vblock. 

Very convenient when doing sizing back and forth.  

You really can't make the same claim if that arbitrary virtual machine is moved to, say, a different server architecture and a different storage array an a different I/O subsystem.  The standardization inherent in a Vblock means that you'll get largely the same performance experience wherever the workload goes.

Consider second-level support for just a moment.  An "owned" Vblock is supported by VCE, which is in turn supported by the parent companies.  A "rented" Vblock is supported in the exact same manner.  Put differently, both ends of the wire are supported by the exact same support structure.

Another benefit, if you're trying to make your life more simple …

There's more.  For example, the ability to use GRC frameworks like Archer to provide the same controls on both sides of the wire.  Portals like Data Protection Advisor to ensure that all data is being protected, regardless of whether it's here or there.  UIM for infrastructure provisioning.  And so on.

Depending on the service provider and your particular choices, it's highly likely that the management and orchestration layers will be highly compatible with your internal choices as well.

And that's *before* we start moving workloads back and forth non-disruptively with VPLEX :)

Flexible Consumption Options Proving To Be A Boon For Customers

This "flexibility of consumption option" is proving to be extremely useful in a variety of pragmatic customer situations.

Here's one: customer wants to run a Vblock internally, but has to wait until the next budget cycle to pay for it.  No need to wait; get a head start on the environment by simply renting compatible assets from any one of a number of compatible VCE-based service providers.

When the budget for the "owned" Vblock eventually shows up, workloads can easily be moved back from the service provider with a minimum of hassle.

Here's another: customer sizing estimates for their new Vblock are varying all over the place, since future workload requirements are basically an educated guess.  The logical answer?  Simply buy a modest Vblock for the workloads that are well-understood, and use compatible service provider infrastructure for any potential overage.

No need to super-size your Vblock when there are plenty of external options.  Unless you want to, that is :)

Here's yet another: a company with global operations wants to shed the expense of operating multiple data centers around the world, yet is concerned that applications need to be close to the people who use them.  The approach?  Consolidate and centralize the workloads that are amenable to doing so; use rented Vblock infrastructure where a small footprint is needed to keep the application close to users.

Same infrastructure, same management, same expectations, same support, etc. on both sides of the wire.  How convenient!

Here's The Point

Infrastructure traditionalists often bristle a bit at the Vblock approach with its strict approach to design and configuration.  However, the structured approach is turning out to pay back even more benefits that we originally surmised.

• Sizing, configuration, order and delivery takes less time
• Getting the system into production takes far less time
• Performance and related characteristics are well defined and well understood
• Multi-level support comes from a single, integrated source.
• Releases and patches for the entire infrastructure are pre-integrated and pre-tested

And now, as more service providers are standing up Vblocks, there's a strong interest in flexible consumption options: buy, rent, or any combination at any time.

Few, if any, of these benefits result from the more common "reference architecture" approach.  The Vblock is a product; built and supported by VCE.  Its standardization is its strength.

The Service Provider Angle

A similar story plays out for the service providers who are using Vblocks to build their businesses.  Not only do they get a leg up on operational costs vs. traditional approaches, but they also get 'branded infrastructure" that's becoming well known to more and more sophisticated IT organizations.

Imagine you're a service provider, and a prospective customer asks you "what will my application be running on?".  If the answer is "a Vblock", it's likely to be a short and satisfactory conversation indeed. 

Otherwise, you'll have some lengthy explaining ahead of you ...

Kicking The "Build It Yourself" Habit

There are more than a few IT organizations that are capable of building their own Vblock-ish approach.  While I don't argue their capabilities, I do argue the rationale for doing so: wouldn't it be better for the IT team to work on things that deliver unique value vs. re-inventing the wheel?

To that argument, I can now add another powerful one: insisting on building and maintaining infrastructure using a traditional model will severely limit your consumption options.  There won't be a ready supply of service providers waiting in the wings who are running infrastructure just like yours.

And that's turning out to be a very big deal indeed, especially in the upper levels of IT management.  Having the option to rent vs. buy is tough one to give up.

The Power Of Standardization

Old habits die hard, and the practice of hand-crafting IT infrastructure will likely fall into this category.  We have an entire generation of IT professionals who've been taught how to select, integrate and support IT infrastructure components.

Vblocks (and their ilk) change this fundamental assumption.  Customers and service providers have seen the advantages of the integrated approach.  There's no turning back now.

Relatively quickly, the Vblock has become almost a unit of IT infrastructure currency: well understood, and generally accepted as proven and valid in most IT circles.

 

 

 

 

 

 

Comments

[Doug Hagerman]

Sure, but why then are there are different sorts of vBlocks?

My boss is pushing to deploy VNX-based vBlocks into our Symmetrix environment because they're cheaper, but it seems to me that if there is this standard unit of computing of 1 core and 1 TB of capacity (roughly), then it shouldn't matter to him whether it's made of VNX or Symmetrix components. But it does matter to me because my team knows about the DMX and VMAX products, and they leverage the bin file process to keep things more or less under control, and they want to do non-disruptive data migrations, all of which will be lost with the VNX-based approach. The vBlocks should be priced on the number of standard computing units they support, and nothing more.

[Chuck Hollis]

Hi Doug

I hear you.

If I was debating the point, I'd try and make a case to spring for the VMAX-based Vblocks.

Why?

I like the greater scale, I like the improved responsiveness to changing workloads (think FAST VP), and nothing beats the availability characteristics (think what happens when one of a dual-controller array fails, you're left with basically half the performance until the problem is corrected. For some folks that's acceptable, for others, not)

Again, you haven't told me anything about your environment and intended use case, so these are just theoretical arguments vs. practical ones for you. Lots of VNX-based Vblocks out there with extremely happy customers, so either way you win :)

Now that I think about it, the fact that you have Symm tech on the floor tells me a bit about your workloads and use cases. I suppose the reasons that led to choosing that platform previously might be the same reasons why to do it again. Again, I'm just speculating.

And, as you point out, you've got some expertise built up in the VMAX platform, which ought to count for something.

Best of luck!

-- Chuck

[IT infrasturcture]

I do agree with this post. We should emphasize on ecosystem compatible infrastructure services. Flexible consumption option will really help the customers. Thanks for sharing such a valuable post.

[IT infrasturcture]

I do agree with this post. We should emphasize on ecosystem compatible infrastructure services. Flexible consumption option will really help the customers. Thanks for sharing such a valuable post.