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 ProvidersBuild 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.
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
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.
By: Chuck Hollis