I've written before that I believe that virtualization changes everything. The idea of wrapping up environments that used to require a dedicated server or desktop isn't just limited to user applications.
A significant part of the IT landscape consists of infrastructure software -- and it's fair game for being virtualized as well.
Infrastructure Software?
By infrastructure software, I'm referring to applications that users don't see, and provide services for others.
If you run a large environment, think for a moment of all the management and monitoring servers that you've got sprinkled across the landscape.
They're candidates to be virtualized.
And, when we consider the storage domain, there's more: file services, backup engines, archiving software, replication thingies -- it can be quite a long list, in addition to storage management and monitoring.
Each of these usually requires a dedicated appliance or server. And I think many of these are candidates to be virtualized.
Why Would You Virtualize Infrastructure Software?
For many of the same reasons you'd virtualize application software -- consolidation, for example. I think it's a safe bet that many of these servers that are running infrastructure software are lightly used at best.
But when you look closer, there's more. Infrastructure software usually requires dual servers for redundancy, which leads to a "Noah's ark" landscape where there's two of everything.
But, in a VMware farm, there's the option of N+1 redundancy, provided transparently courtesy of DRS.
And, of course, there's the ability to easily try out new versions of infrastructure software, and to roll back quickly if needed.
Scaling becomes somewhat easier as well -- if your needs start small, an infrastructure service can share a server with other services or applications. If needs grow, simply add more server resources for VMware to use, or fire up additional instances of the service when needed.
No need to precisely size server requirements for infrastructure software ahead of time; simply dial pooled server resources up or down as things change.
There's also the advantage of breaking the "hardware dependency vapor lock". Infrastructure software vendors usually qualify a limited number of server configurations to provide better supportability to their customers -- however, this may lead to having to use server platforms that aren't convenient or cost effective for larger environments.
As an example, if you wanted to use an older, spare server (or perhaps
a blade on your newer farm), and the vendor hadn't qualified it, you'd
be in an interesting position, support-wise.
When you talk to the vendors who provide infrastructure software, you'll hear some interesting objections. I'm always amused by these, since engineers are supposed to be adept in dealing with facts, rather than hearsay.
One red herring you'll hear is "virtualization impacts performance".
I can't speak for other hypervisors, but EMC's experience to date running infrastructure software on virtual machines comes under the category of "impacts too small to matter" -- if at all.
Now, of course, if you're sharing an ESX server with other tasks, you've got to keep an eye on required resources in a way that you probably didn't have to when running on a dedicated server, but that can be simply handled by configuring the virtual machines with sufficient dedicated processor and memory.
Another objection you'll hear from software vendors is "too much effort for us to support virtual machines".
Again, our experience is that it's actually easier to support infrastructure software running in VMs -- you've got a predictable, stable environment that's a known quantity, regardless of what hardware platform you're running on.
That is, once a vendor makes the decision to support their infrastructure software running in virtual machines ...
The Key Issue From A Vendor Perspective?
So, here's the core of the problem from a vendor viewpoint: what's in it for me and my company?
At one cynical level, they're being asked to do additional work (e.g. invest in understanding virtual environments, adapting their software to run in virtual machines, enhancing their support processes, etc.) without corresponding incremental revenue.
These are not insignificant investments, and there are opportunity costs associated with doing this work as opposed to adding more features, for example.
And, let's be honest, I don't know any customers who'd pay *more* for the privilege of running a given piece of infrastructure software in a virtual machine.
Another barrier is pricing models -- many of them use "cores", "processors" or "servers" as their underlying scaling metric for pricing -- and, in a virtual world, these are all very fuzzy concepts.
EMC's Perspective?
Well, no surprise, we've got a fair amount of infrastructure software in our portfolio. If you know our expanded product line, it's not hard to come up with a dozen or more products that currently are deployed on a dedicated server or appliance.
But we've started to make the investment. We think that giving customers -- especially larger ones -- the option of having functionality run in a virtual machine is an important one, and this needs to happen sooner than later.
One of our first forays into this space -- Avamar -- has turned out to be a very positive experience.
If you're not familiar with Avamar, it's a backup product that does client-side 3D (data deduplication), reducing the amount of data that gets sent over the network, unlike many other 3D approaches.
There's a cool "virtual edition" of Avamar where the target backup device runs in one or more VMware instances rather than requiring dedicated server(s).
Customers can get started with Avamar on whatever (virtual) servers and storage they're using, and either add more virtualized resources, or move to dedicated servers as their needs grow.
It's turned out to be a very useful option for many of our customers. And I don't think that the thinking should be limited to one product in our portfolio.
Virtualization Changes Everything
Even infrastructure software, I'd wager.
And I don't think it'll be too long before we'll see pools of servers and storage running infrastructure software, rather than multiple dedicated (and HA) servers scattered across the landscape.
It's not hard to see how customers would benefit: less hardware, simpler environments to manage, easier to introduce new functionality and new version, easier to scale resources up and down as things change, and so on.
And, if infrastructure vendors think about it long enough, they'll probably come to the same conclusion we have.
Comments