I love this industry.
On one hand, you can clearly see the megatrends that are driving change. On the other hand, not every vendor reacts to these trends in the same way. That's what makes things so interesting.
Take virtualization -- as applied to servers. A powerful idea, but interpreted in different ways.
One camp saw the need for a new technology abstraction -- the hypervisor -- that encapsulated and extended the legacy approach. A second camp decided to add server virtualization features to their existing operating systems.
In this case, VMware is the best example of the first camp. Sun, IBM and Microsoft are probably good examples of the second camp. You're free to debate which one is theoretically "better", but there should be no argument whatsoever around market adoption of the former over the latter.
A similar divergence of approaches appears to be shaping up over networking technology.
The database world is not immune to this megatrend, either.
As part of Oracle Open World 2012, Oracle gave their first peek into how they're going to address what I would call "database virtualization concepts" (expressed in their terms as the need for multi-tenancy) in their core database products.
And, once again, we'll see a familiar argument play out: create a new abstraction, or simply extend existing database technology.
I know which one I'm betting on ...
You can get to the core discussion through any path of your choosing, but you'll end up in largely the same place. In today's world, the notion of one physical database / one physical server / one application is seriously outmoded for any number of reasons; efficiency, agility, you name it.
VMware has been quietly applying a small amount of pressure on Oracle database consumption and implementation habits -- not only with their core products, but more specifically via a recent release of vFabric Data Director.
If you're not well acquainted with what it does, in a nutshell it makes database instances far easier to instantiate, consume and manage for everyone involved -- simply by extended many of the capabilities found in vSphere.
If you're interested in my slightly longer treatise, here it is.
But no good deed goes unpunished in today's technology world, does it? Oracle's response appears to be in the form of pre-announcing new capabilities for Oracle 12c, namely "pluggable databases". The idea is conceptually simple: a "root" instance of Oracle can be used to instantiate "up to 250" user-specific sub-instances that are theoretically unrelated to (and isolated from) the root Oracle instance.
Specific details are scant (as you might expect at this stage), but you can see where they'd like to go: applying virtualization concepts to the database world by extending the features of the database itself.
So, what are we to think of all of this?
Stating The Obvious
Let's tackle the easy bits up front.
First, Oracle 12c isn't here yet, and won't be anytime soon. Any major architectural feature this substantial will take a non-trivial amount of calendar time to bring to market, more time to mature, and even more time for their users to migrate in sizable numbers. I'll leave it to Oracle to make specific statements in this regard, but past history (for any vendor) is hardly encouraging in terms of speedy access to the new capabilities.
Second, remember this is Oracle we're talking about. New functionality inevitably means new licensing terms, which isn't expected to be cheap -- unless there is a viable competitor in the market gnawing away at market share.
Case in point: Oracle's pricing on Linux and their versions of hypervisor technology.
Third, we're clearly talking about new skills and processes that the DBA will have to acquaint themselves with. These are some major new database concepts at hand; proficiency won't happen overnight -- and won't begin in earnest until the product is generally available.
If we compare these three attributes against VMware's vFabric Data Director, there are some clear differences.
First, vFabric Data Director has now been around for a while, and is now in its second major release. Its design goal is to be relatively DBMS-agnostic; limited by engineering bandwidth to support various popular flavors of database versions in use. You don't have to upgrade to a new version of the database just to get the capabilities you're looking for.
In general, vFabric Data Director does not appear to be tightly coupled to other parts of the VMware portfolio, either.
"Migration" in this case is really more "implementation": a semi-automated procedure to incorporate existing databases into vFabric Data Director vs. migrating to a new version of a database, sort of like how P2Vs work in the server world. The vFabric Data Director also supports an open source database variation that can be an attractive alternative to a licensed database product, e.g. Postgres.
You'll have to decide for yourself which vendor has the more attractive licensing terms -- VMware or Oracle. I'm not going to touch that one ...
More importantly, the DBA doesn't have to acquaint themselves with entirely new database concepts and practices. The goal of vFabric Data Director is to simply automate what's largely being done manually today, so the skill requirements are comparatively minimal.
Arguing The More Subtle Points
Harder to discern are the relative merits around performance, efficiency, security and isolation.
On paper, I could give Oracle a theoretical nod for performance, simply because there's no hypervisor acting as an intermediary. But, that being said, I don't think that will end up being a big deal.
Today's hypervisors are plenty fast for 99.99% of the workloads that are out there, and more performance is always available in the form of faster processors, use of intelligent flash, and so on. Besides, it's personally hard for me to see how a pluggable database could have the exact same performance profile as a non-plugged one. But I'm certainly no expert :)
Efficiency (CPU and memory) is also going to likely be a wash for most situations. Oracle may (rightly) claim that their approach can reuse memory pages, balance across available CPUs, etc. Well, the same is largely true for the VMware-based approach -- it just happens in the hypervisor vs. the database. And I'll have to give VMware substantial credit for continually improving their capabilities here over the last decade vs. what looks like a comparatively fresh start for the Oracle team.
When it comes to security, I'll give VMware big points: they've been enhancing the security of their virtual machine containers aggressively for many, many years -- not only with their own products, but partnering with folks like RSA. While Oracle is arguably very good at security as well, I do have to note that they'll be introducing an entirely new "container" to secure.
Ditto with multi-tenancy, especially the all-important performance isolation -- not an easy thing to address, and something the VMware team has been furiously focused on for many years.
Once again, these are only theoretical comparisons. We have a VMware-based product to evaluate, and we won't get a detailed look at Oracle's answer for quite some time yet.
How This Might All Play Out
I have no doubt that Oracle will be successful in bringing Oracle 12c to market when it's ready. I also believe that -- over time -- they'll find ways to get their installed base to migrate to the new version. But when it comes to adopting the proposed pluggable-database concept vs. other alternatives to achieve similar results, it's far less certain.
Frequently, these debates play out to the market power that's held by the respective vendors. As an example, an all-IBM shop is usually very comfortable with AIX virtualization as being a really good answer.
But we've got an interesting situation here -- overlapping power bases. Oracle is a key vendor for so many enterprise IT shops, but -- then again -- so is VMware. I'm sure this will lead to some heated internal discussions before long as this particular issue comes to a head.
One interesting preview exists, though -- there's decent interest from the VMware community in how to, for example, get much of the functionality found in Oracle RAC by instead using VMware's capabilities.
Maybe we'll see the same thing play out here.