Whether you call it pervasive virtualization, private cloud, or whatever -- the boundaries between traditional disciplines are being redrawn, and -- as a result -- many of the words and concepts we're so familiar with take on very different meanings.
As IT professionals (whether customer, vendor or consultant), I would argue that we all need to be very congnizant of helping people migrate from traditional meanings to newer ones.
In this post, I wanted to share three personal examples of somewhat familiar concepts where I believe this is happening right now.
The original target market for storage virtualization was being able to put a device in front of legacy storage and teach it a few new tricks: pool it, migratre it, manage it a bit better perhaps, and add a bit of replication functionality perhaps not found in the underlying devices.
Now, just to be clear, I meet people all the time who've got a veritable zoo of different storage arrays, very limited capital budget, and are looking for a quick fix. And, in some cases, traditional storage virtualization may be an interesting approach, although I personally believe it creates more problems than it solves for most people.
But I will categorically state that traditional storage virtualization is tactical, and not strategic -- given what's going on elsewhere.
One example is VMware itself. Many of the functions traditional associated with storage virtualization are finding their way into VMware's product -- pooling, mobility, management, replication, etc. One might argue that using a dedicated storage virtualization appliance thingie might still be needed in some cases, but the vast majority of use cases tend to disappear into VMware's functionality.
We as storage vendors will need to rethink the concept going forward, and make it do useful things that can't be done in the hypervisor. That's a good thing, not a bad thing.
Storage and Multi-tenancyA few storage vendors are trying to emphasize their multi-tenancy capabilities as "essential for cloud". Good for them.
Now, one could make an argument that, when using traditional IT architectures, storage multi-tenancy could be somewhat important. I mean, you'd want to segment capacity, performance and the management domain, wouldn't you? And, not only provide consumption portals for individual users, but provide aggregate stats on how your "storage vending machine" is doing?
But, let's take a different world view, just for a moment.
First, let's just presume that everything is fully virtualized with VMware. And, let's assume that the operational model has moved away from traditional "horizontal" disciplines (i.e. storage, compute, network, etc.) and towards a vertically integrated model (provisioning applications and services).
Is the legacy concept of storage multi-tenancy really all that relevant any more?
Your "unit of encapsulation" is now the proverbial virtual machine, or -- more precisely -- the vApp. The virtual machine bounds compute, network and storage. Service level constructs (i.e. performance, availability, etc.) are likely expressed at the VM level, and implemented by the supporting infrastructure.
Let's see -- each tenant sees their storage and no other. They are free to reconfigure and repartition within their (virtualized) domain. QoS isolation is driven by something other than a storage manager. Individual VMs can be encrypted, if needed -- and their encryption follows them wherever they go. Same for authorization, access and auditing.
Put differently, storage multi-tenancy tends to disappear as a separate concept, and becomes simply an extension of a fully integrated virtualized environment.
I'm sure I'll get vigorous and passionate debate on this from the usual suspects, but -- in one sense -- the isolated infrastructure multi-tenancy discussions all become much less interesting, and all move to the virtual machine abstraction. It's already happened with servers and networks, why would storage be any different?
Several years ago, one of our competitors made a big deal about "unified" storage -- a single device that could do iSCSI, NAS and FC to a certain extent. Giving credit where credit is due, it turned out to be a popular concept in some market segments.
So much so that, yes, we started calling our similar devices "unified storage" as well, specifically EMC's Celerra. And customers had choices to make as to what flavor of unified storage worked best for them.Note: given the recent IDC and Gartner results, it looks like EMC is doing pretty well in that regard :-)
However, everything must change.
Consider a Vblock, or something that looks like a Vblock. The "unification" abstraction has moved way up the stack. One interpretation of a Vblock is that you've unified the provisioning and management of applications and services using virtualization.
Most of the time, you don't see the server, the fabric, the storage, etc. Actually, you don't really want to have to see those discrete entities. You want see applications running in virtual machines, and the plumbing that supports it.
What does "unified storage" mean in this context? Do you really care about protocols and physical network layers any more? Or that it is packaged in a single lump of hardware?
Certainly the term now means something very different -- storage has been "unified" with the layers above it to create a new abstraction of great value to the customer.
What Does All Of The Mean?
It's simple. We're at a time in the IT industry where things are moving *very* fast. And it needs to be said again: virtualization changes everything.
As the lines get redrawn, the ideal meaning of some of these concepts has to change. Many of us accept this as an article of faith.
But, as you listen to all the incessant vendor pitches from EMC and everyone else -- I'd encourage you to ask the question -- was there latest widget designed to fit into the old world?Or was it designed to fit in the new one?