The day before yesterday, VMware had their most-significant-ever product announcement.
The amount of technical goodness -- and what it means for the industry -- takes more than a little while to wrap your head around.
A bit of that awesomeness was overshadowed by reactions to VMware's new pricing scheme. I watched the vocal back-and-forth intently as it unfolded through Monday and into Tuesday. Wisely, I kept a safe distance from the fray.
But I did want to weigh in at some point. I think some people are missing a few key perspectives, and I'd like to take a shot at broadening the conversation.
Disclaimer: This is just plain old me talking. VMware, as an independent company, runs their own affairs. I am speaking strictly as an industry observer here, and not in any way communicating the official position of EMC, VMware, or anyone else for that matter :)
The VMware Technical Awesomeness
I think one of the best writeups I've seen came from our own Chad Sakac (aka The Virtual Geek). There's at least *five* useful and detailed posts here, all worth savoring in detail. I can't share it, but the internal briefing that Chad sent around was equally awesome.
In a nutshell, here's what we all can look forward to:
- far larger virtual machines (memory, CPU, disk space, I/O) -- enough to take on the scariest workloads
- far more robust virtual machines -- improved HA and DR capabilities -- again, enough to take on the scariest workloads
- a tightly integrated DLP (data loss prevention) capability that might take a while for some to fully appreciate
- truly unique and compelling storage integration extensions -- VAAI and VASA -- that you won't find anywhere else
- better and more integrated management tools in a few key areas
- and an interesting VSA (virtual storage appliance) that will undoubtedly find a home in smaller settings
Big news, indeed, with all this major new functionality -- especially if you've got that gleam in your eye of an environment that's 100% virtual, like so many of you do.
If you think back a few years to Paul Maritz' use of the term "software mainframe", well, that doesn't look quite so far-fetched anymore, does it?
And then there was that new licensing scheme that was announced ...
Few people really like structural changes in enterprise software licensing schemes. Whether they're good changes or otherwise, an amazing amount of organizational calculus and optimization results from how vendors charge for their wares. Change the assumptions, and a lot can be impacted elsewhere in an IT organization.
Those changes have to be assessed, analyzed, new recommendations made and communicated, procurement needs to get involved, more meetings, etc. etc. The larger your shop, the more work is required to do all of these things. And I think everyone should expect a certain amount of kvetching when changes are made.
If anything, the noise level says much about the strategic importance of VMware to so many IT organizations around the world.
But software licensing schemes are powerful tools as well: they provide clear signals on how the vendor would like people consume and deploy the technology. Change the licensing scheme, change how your software is used.
Yes, there's always some sort of revenue angle (these are businesses, after all) but -- when the discussion gets serious -- you're turing some pretty powerful knobs indeed when you sit down in internal product planning meetings to discuss these very weighty topics.
I have every confidence that the VMware senior management team thought long and hard about what they were doing. I, for one, am starting to appreciate the beauty of logic here; I can only hope that others will too over time.
Current State Vs. Future State
There must have been at least a dozen before-and-after comparisons that floated around on the interwebs where people shared their hardware configurations under the 4.x licensing scheme and their understanding of the 5.x scheme. Some people came out worse, some people came out better, some people didn't see a significant change.
While all of that is interesting and educational, I think it's more useful to think in terms of future state, and less about present state.
Every software licensing scheme needs at least one "price for value" metric. In this space, the choices are obvious: count servers, count sockets, count cores, count storage capacity, count number of VMs, etc. etc. Or arrive at a new pricing metric entirely: vRAM.
A fascinating choice, indeed.
What I think that some people might miss is that this choice implies that -- in VMware's envisioned state -- virtualized RAM is both pooled and dynamic. As I understand it, vRAM is the stuff that unique applications actually see and use, and does not include many forms of overhead: memory used by VMware itself, spare capacity for N+1 scenarios, pages reclaimed through sharing and/or compression schemes, etc.
Pooled, shareable and efficiently used resources are potentially *much* more valuable than the static, dedicated and overhead-burdened kind.
If you consider the storage domain, few would argue against the benefits of pooled, shareable storage resources -- although at one time (e.g. 1995) that was a dangerous and radical thought. In the storage world, people have become very comfortable with the idea that a pooled, dynamic resource is more valuable (and costs more!) than the static, dedicated kind.
My perception of vRAM is that it's an analagous concept -- to a degree.
But the analogy only goes so far, and there's an important difference: in VMware's near-future world, vRAM is a resource that is requested, used, and given back to the pool when no longer needed. By comparison, in the storage world, no one ever gives anything back. At least, not voluntarily :)
Look closely, and you'll see the underpinnings of a new world where applications (or management frameworks) can dynaimcally vary memory used over time -- expand and contract as needed. Fully realized, that makes vRAM an incredibly useful and powerful resource indeed vs. today's world of largely static and dedicated RAM allocations.
Amidst all the noise, this is what I see: strong economic encouragement for IT architects to start thinking in terms of vRAM as a shareable and dynamic resource, which many of them aren't doing today. Mainframe apps get dynamic control of memory; why not VMware apps? And, not surprsingly, there's now an additional economic incentive to create new shared-services apps using a thinner, more lightweight, more modern approach.
Not that VMware would have any ideas on what that might look like :)
And, let's not forget, those legacy apps that do require ginormous amounts of vRAM were previously running on decidedly more expensive and often less functional proprietary processor/OS combinations. Perhaps that might make a more useful before-and-after comparison for some?
I can't speak for everyone, but if I look at EMC IT's intended use of Vsphere 5.0 to bring over final round of ginormous mission-critical apps off the monsters they're currently running on, I don't think it'll be hard to make the case :)
For starters, I'm fully empathetic on the disruption casued by any significant change in enterprise software licensing. I get that, thanks. And, yes, perhaps the VMware crew might have communicated the changes differently -- some of the sting seemed to be a direct result of "how" rather than "what".
That being said, I'd challenge concerned IT professionals to take a moment and decide for themselves -- what is the future state environment is VMware envisioning with these changes?
Don't assume it's all about the money -- it's really about the outcome.
Courteous comments are welcome, as always :)