All databases are equal, but some databases are more equal than others

Building database services based on Exadata, Oracle Enterprise Manager and Oracle Database 12c is a powerful combination, especially if implemented properly and by skillful DBAs.

A recent article of Forbes Magazine explains why Database as a Service (DBaaS) will be the Breakaway Technology of 2014. The 451 research report estimated that DBaaS providers generated revenue of $150 million in 2012, but that revenue will grow at a compound annual growth rate of 86% to reach $1.8 billion by 2016.

By paraphrasing “Animal Farm” author George Orwell, Oracle’s Alexander Wolfe stated that some DBaaS offerings provide a lot more services than others. I would like to clarify why this is indeed so true.

What is DBaaS?

Kellyn Pot’vin from Enkitec says that Database as a Service (DBaaS) is an architectural and operational approach enabling DBAs to deliver database functionality as a service to internal and/or external customers.

According to scaledb.com, Database-as-a-Service (DBaaS) is a service that is managed by a cloud operator (public or private) that supports applications, without the application team assuming responsibility for traditional database administration functions.

Technopedia says that Database-as-a-service (DbaaS) is a cloud computing service model that provides users with some form of access to a database without the need for setting up physical hardware, installing software or configuring for performance.

Kellyn’s definition is the way I understand it based on my experience at least. The other two definitions makes me feel like one can also define easily Compression-as-a-service or Temporary-tablespace-as-a-service.

Regardless of how the essence of DbaaS is set with words, it is all about simplifying, enhancing and automating database provisioning, monitoring, administration, security and operational efficiency. In short, centralizing and harmonizing the database administration.

Although I wrote above simplifying, still it means more like reducing the complexity and having a simplification plan than ending with an elementary and transparent database environment. Though I have seen that this is doable but mostly in power point presentations.

Now, the reference architecture of “Databases as a Service” can be found here. But most of the white papers and reference notes that one can find on the web are made for decision makers, not for implementers. The really though is that DbaaS is DBA driven. Regardless of how cunning plan on how to implement DbaaS a company has, it is still very much up to the ones who implement the service: their skills, practical knowledge and experience. So, here is the DBA cookbook.

A very experienced DBA team can offer a much more services than another. Highly experienced Database Architects can enable businesses to deploy new databases quickly, securely, and cheaply. What is part of the service varies and business is often not even aware of what to request.

The long list of what can be included in the service and how the implementation is handled is not part of this blog post but all database experts know that if implemented properly, DbaaS will lead to:

Harmonized environment:
– Less time needed for database management
– Easier monitoring
– Less unexpected problems
– Stronger security
Less cost:
– Less databases licenses
– Less storage needed
– Less memory and CPU needed
Better performance
– Standard parameterization and settings
– Regular common reorganization

So, why do some DBaaS offerings provide a lot more services than others? The Forbes article sums up the flexibility inherent in the DBaaS model by apply the “Burger King” analogy: DBaaS lets you have it your way. And it comes up with its pros and cons. In order to always have the upper hand, I always try to follow some simple principles:

– not more than 2 database version including the patchset levels
– databases should not run on more than 2 different operating systems
– at least 2 environments for every database: never end up with just productions
– standby database/replica/ADG for every mission critical database
– 2 OEM environments: either PROD and non-PROD or primary and secondary data center
– 2 DBAs to verify every important DB change
– at minimum 2 RMAN catalogs: one for PROD and one for non-PROD
– do not mix 2 databases based on different COTS software (like SAP and Siebel for example)

In a DbaaS, all databases are equal, however for business some databases are often more important than the others. DBAs are aware of this and they know how to handle this nontrivial complexity.