3 Things Companies Forget When Implementing DBaaS

Keeping databases up-to-date is difficult. Almost a third of Oracle DBAs run over 5 different set configurations across all of their environments. Obviously, we need automation to maintain consistency across all of our environments. Also, consider that the role of the DBA is not fading away with the advent of automation and cloud. In fact, demand for database administration skills is increasing.¹ This means that are DBAs are doing more and we need more of them.

This demand for DBAs is driven primarily by the enterprises’ need for highly responsive data environments. Frantic development cycles and accelerated pace of business innovation requires that data and insights be available at a moment’s notice. Taking a week or more to approve change requests or provision databases is not acceptable for the real-time enterprise.²

To address these challenges companies are choosing to adopt Database-as-a-Service, or DBaaS, from vendors like Oracle, Delphix, and Actifio. However, these are not panaceas and could potentially cause more pain than expected. Understanding the issues to watch out for will make for a smoother adoption process.

Your application output will increase

The number one reason we hear companies implement DBaaS is to create development and testing environments quickly. Just like we saw with the adoption of development and test environments in the cloud, we can expect the output to increase from development and testing teams. After all, we are removing a huge impediment to productivity by providing self-service database environments.

But, how will organizations consume this increase in velocity? If there is no DevOps strategy in place to consume database changes, there really is no point in creating them in the first place!

DB lifecycle management will challenge you

With self-service comes an expectation of self-management. But what happens when developers start “pack ratting” database environments? Knowing when to shutdown unused virtualized databases will be key to managing license cost and resource utilization. Companies need a strategy and tooling to identify change located in the virtualized database and capture it. The end goal is to retire unused environments to free resources for the next one.

DBaaS is one way

When a virtualized database environment is created using another database as a template an exact copy of that environment is delivered. All changes persisted to the source will be in the new environment. However, it is really important to understand that no DBaaS provider gives the ability to take change from the new environment and persist it to the source. This is a one-way street. Moreover, because databases have state, organizations run the risk of losing data if someone simply dumps and restores to the original source.

As DBaaS becomes commonplace, identifying change in the new environments to persist to other environments will be a huge challenge.

There is a solution

These problems are identical to ones that development teams faced when adopting virtualized and later cloud environments for development and test. The solution was to utilize sound application development practices and apply them to this new platform. The same can be done for Database as a Service. Visit www.datical.com to register for an upcoming expert brief on Thursday, 6/16 from 11:00 – 11:30 am CST to learn more about the 3 things organizations need to be aware of when implementing DBaaS and how you can bring DevOps to all of your database platforms, on-prem, cloud, or virtualized. “THE RAPIDLY ACCELERATING CLOUD-ENABLED ENTERPRISE: 2015 IOUG Survey on Database Manageability”, Unisphere Research