Psst, wanna reduce database sprawl, enable self-service deployment, and support elastic computing capacity? More IT blah-blah? Not if you believe the market forecasts, which project that Database as a Service (DBaaS) is about to hit the knee of the hockey stick curve growth curve.
Indeed, 451 Research sees revenues accrued by DBaaS providers rising 86% annually, from $150 million in 2012 to $1.8 billion by 2016. Here are the bullet points driving the DBaaS frenzy:
- DBaaS reduces database sprawl. DBaaS lets you shift your organization from administering a complex collection of silos—each requiring their own care, feeding, and patching—to a business powered by an agile and flexible database cloud.
- DBaaS supports rapid provisioning. Need to spin up a new database real quick? No problem. In fact, if you happen to be using Oracle Database 12c, you can clone an existing database in minutes.
- DBaaS enhances security. Maintaining each database in a separate container creates a kind of virtual moat, which is an impediment for the bad guys.
- Automation enables centralized management of all your databases. This is a key feature that isn't universally available in the DBaaS world. But you get it as part of the package if you're using Oracle Database 12c. (More about this later.)
And, hey, you don't have to take my word for it. Even though I've seeded the above highlights with an Oracle mention (or two), there's industrywide consensus on the core points, and I can refer you to examples ranging from this VMware blog to this TechTarget article to prove it.
In many ways, DBaaS exemplifies the benefits of the "as a Service" philosophy that's arisen alongside cloud computing. (Just don't try saying IaaS, PaaS, and SaaS three times fast.) Interestingly, those advantages—nearly all of which fall under the broad heading of an IT culture that's more responsive to business needs—are achievable whether you're accessing your DBaaS through a cloud provider, or implementing it in on-premise in your datacenter. The latter would essentially be a kind of private-cloud version of DBaaS, and it's certainly highly amenable to systems purpose-built with database chops.
I like to sum up the flexibility inherent in the DBaaS model by apply the "Burger King" analogy: DBaaS lets you have it your way. (Substitute "it" with the acronym "IT" and this comparison makes even more sense.) Let's say you're a typical mid- to large-sized organization running vast estates of databases. Perhaps you're hosting a couple of dozen variations, each of which require special expertise, care, and feeding.
Wouldn't it be easier to consolidate all those instances? That'd certainly facilitate their management. Easier still, your cloud provider could co-manage the software, or even take on most of the operational heavy lifting.
With ramping DBaaS demand and so much revenue there for the taking, customers now have a dizzying array of choices. However, to paraphrase "Animal Farm" author George Orwell, some DBaaS offerings provide a lot more services than others. Oracle's skin in this game is the new Oracle Database 12c, released last summer. Optimization for DBaaS operation comes from the Oracle Multitenant option available with 12c's enterprise edition.
Multitenant is a canonical win-win in that it's both a consolidation and a simplification play. In this architectural model, a multitenant container database can hold multiple, individual—we call the "pluggable"—databases. The line marketing uses is "managing many databases as one." You can see the illustration accompanying this article to get a visual on how the multitenant model obviates a whole lotta messing with a bunch of individual DB instances. It sidesteps a significant amount of virtual-machine management, too.
Did I mush too much together? Here are some bullets to clarify the advantages of multitenancy:
- Multitenancy allows you to rapidly provision pluggable databases (aka the "tenants") from a single database container.
- Multitenant gives you the agility to clone copies of databases in minutes.
- It allows true isolation between database tenants.
- Provides high availability, disaster recovery and security for each tenant database.
- As mentioned before, it enables significant reduction in database sprawl.
- Multitenancy's container approach facilitates not just deployment, but also testing.
I've spent most of this post explaining DBaaS, via explicit or implicit comparison to the legacy, run-it-yourself model. While my juxtapositions are all valid, it strikes me that I'm missing an important "thought leadership" point, which Robert Sheldon captured nicely in his TechTarget piece. "DBaaS is a different animal from the on-premises database," Sheldon wrote.
I wouldn't agree as regards functionality. Cloud is just a delivery mechanism. A database is supposed to, uh, base data—you know what I mean—regardless of where it's running. However, conceptually speaking, I'd posit that DBaaS is as big a shift from on-premise (or, more strictly, non-cloud) operation as Facebook is from a Rolodex-based contact list.
Us folks over 30 (those of us you can trust, anyway) tend to see cloud as an evolutionary step in computing. It's not. It's a step-function break with old ways of thinking and doing. I expect that the Millennials who've so avidly brought smartphones and tablets into the workplace will soon assume that you're able to Bring Your Own Cloud (BYOC) to the office.
If we explain to them that DBaaS is already up and running as part our organization's secure, licensed, inventoried, and proven cloud portfolio, perhaps they'll even thank us.