FOUR questions to ask if you are implementing DATABASE-AS-A-SERVICE
- by Sudip Datta
During my ongoing tenure at Oracle, I have met all types of DBAs. Happy DBAs, unhappy
DBAs, proud DBAs, risk-loving DBAs, cautious DBAs. These days, as
Database-as-a-Service (DBaaS) becomes more mainstream, I find some complacent DBAs
who are basking in their achievement of having implemented DBaaS. Some others, however, are not that happy.
They grudgingly complain that they did not have much of a say in the
implementation, they simply had to follow what their cloud architects (mostly infrastructure
admins) offered them. In most cases it would be a database wrapped inside a VM
that would be labeled as “Database as a Service”. In other cases, it would be
existing brute-force automation simply exposed in a portal. As much as I think that there is more to
DBaaS than those approaches and often get tempted to propose Enterprise Manager
12c, I try to be objective. Neither do I want to dampen the spirit of the happy
ones, nor do I want to stoke the pain of the unhappy ones. As I mentioned in my
previous post, I don’t deny vanilla automation
could be useful. I like virtualization too
for what it has helped us accomplish in terms of resource management, but we
need to scrutinize its merit on a case-by-case basis and apply it meaningfully.
For
DBAs who either claim to have implemented DBaaS or are planning to do so, I
simply want to provide four key questions to ponder about:
1. Does it make life easier for your end users?
Database-as-a-Service
can have several types of end users. Junior DBAs, QA Engineers, Developers- each
having their own skillset. The objective of DBaaS is to make their life simple,
so that they can focus on their core responsibilities without having to worry
about additional stuff. For example, if you are a Developer using Oracle
Application Express (APEX), you want to deal with schema, objects and PL/SQL
code and not with datafiles or listener configuration. If you are a QA Engineer
needing database copies for functional testing, you do not want to deal with
underlying operating system patching and compliance issues.
The
question to ask, therefore, is, whether DBaaS makes life easier for those
users. It is often convenient to give them VM shells to deal with a la Amazon EC2 IaaS, but is that what
they really want? Is it a productive use of a developer's time if he needs to
apply RPM errata to his Linux operating system. Asking him to keep the
underlying operating system current is like making a guest responsible for a
restaurant's decor.
2. Does it make life easier for your administrators?
Cloud,
in general, is supposed to free administrators from attending to mundane tasks
like provisioning services for every single end user request. It is supposed to
enable a readily consumable platform and enforce standardization in the
process. For example, if a Service Catalog exposes DBaaS of specific database versions
and configurations, it, by its very nature, enforces certain discipline and
standardization within the IT environment. What if, instead of specific
database configurations, cloud allowed each end user to create databases of
their liking resulting in hundreds of version and patch levels and thousands of
individual databases.
Therefore
the right question to ask is whether the unwanted consequence of DBaaS is OS
and database sprawl. And if so, who is responsible for tracking them, backing
them up, administering them? Studies have shown that these administrative
overheads increase exponentially with new targets, and it could result in a
management nightmare.
That
leads us to our next question.
3. Does it satisfy your Security Officers and Compliance
Auditors?
Compliance
Auditors need to know who did what and when. They also want the cloud platform
to be secure, so that end users have little freedom in tampering with it.
Dealing with VM sprawl is not the easiest of challenges, let alone dealing with
them as they keep getting reconfigured and moved around. This leads to the
proverbial needle in the haystack problem, and all it needs is one needle to
cause a serious compliance issue in the enterprise.
Bottomline
is, flexibility and agility should not come at the expense of compliance and it
is very important to get the balance right. Can we have security and isolation
without creating compliance challenges? Instead of a ‘one size fits all
approach’ i.e. OS level isolation, can we think smartly about database
isolation or schema based isolation? This is where the appropriate resource
modeling needs to be applied. The usual systems management vendors out there
with heterogeneous common-denominator approach have compromised on these
semantics.
If
you follow Enterprise Manager’s DBaaS solution, you will see that we have
considered different models, not precluding virtualization, for different
customer use cases. The judgment to use virtual assemblies versus databases on physical RAC versus
Schema-as-a-Service in a single database, should be governed by the need of the
applications and not by putting compliance considerations in the backburner.
4. Does it satisfy your CIO?
Finally,
does it satisfy your higher ups? As the sponsor of cloud initiative, the CIO is
expected to lead an IT transformation project, not merely a run-of-the-mill IT
operations. Simply virtualizing server resources and delivering them through
self-service is a good start, but hardly transformational. CIOs may appreciate the instant benefit from
server consolidation, but studies have revealed that the ROI from consolidation
would flatten out at 20-25%. The question would be: what next?
As
we go higher up in the stack, the need to virtualize, segregate and optimize
shifts to those layers that are more palpable to the business users. As Sushil Kumar
noted in his blog post, " the most important thing to
note here is the enterprise private cloud is not just an IT project, rather it
is a business initiative to create an IT setup that is more aligned with the
needs of today's dynamic and highly competitive business environment."
Business users could not care less about infrastructure consolidation or
virtualization - they care about business agility and service level assurance.
Last
but not the least, lot of CIOs get miffed if we ask them to throw away their
existing hardware investments for implementing DBaaS. In Oracle, we always
emphasize on freedom of choosing a platform; hence Enterprise Manager’s DBaaS
solution is platform neutral. It can work on any Operating System (that the
agent is certified on) Oracle’s hardware as well as 3rd party
hardware.
As
a parting note, I urge you to remember these 4 questions. Remember that your
satisfaction as an implementer lies in the satisfaction of others.
