3 Things Companies Forget When Implementing DBaaS
As cloud services become more commonplace, databases are increasingly moving to a service model. It's easier said than done, and here are a few things to keep in mind.
Join the DZone community and get the full member experience.Join For Free
Keeping databases up-to-date is difficult. Almost a third of Oracle DBAs run more than five 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, according to a 2015 Unisphere Research survey, 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 shut down 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 a 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.
Opinions expressed by DZone contributors are their own.