Database as a Service: Agility vs. Control

Over the last few years there has been an increase in the number of database as a service (DBaaS) offerings that have entered the market place. IaaS providers like Amazon have released solutions such as RDS that automates database administration tasks in the area of scaling, replication, failover, backups, and more. There are a number of companies offering automation around NoSQL databases like Hadoop, MongoDB, Redis, Memcache, and numerous other database technologies. PaaS solutions like Heroku, Openshift, Azure, and others all offer database automation services so that developers can focus on business functionality and not database administration. Database as a Service promises agility in delivering software because it eliminates a large amount of engineering that goes into building scalable, reliable, and fault-tolerant databases.

Sounds too good to be true doesn’t it? In some cases it may be. There are tradeoffs that decision makers must understand before outsourcing the management of databases to a cloud vendor. The advantages are easy to point out.  Time to market is the biggest advantage. With a few clicks of a mouse, a database can be set up and deployed to an environment and be fully functional. Database administrators can quickly change various configurations from a console ,where in the past they had to spend a considerable amount of time performing these functions manually. But when it comes to the production environment, one must weigh the benefits of control versus the benefits of automation. Just today, AWS announced that RDS is no longer in beta and promises an SLA of 99.95, which equates to roughly 22 minutes of down time a month. For mission-critical applications, 22 minutes a month of down time can be a show stopper.

The agility versus control tradeoff is an important one. For a startup trying to get to market, the reward of agility might be worth the risk of an occasional outage. For established companies delivering enterprise services, this SLA might be totally unacceptable. Another consideration is the elasticity requirements of the cloud service itself. If the service expects unpredictable workloads with drastic peaks in transaction counts, a 99.95 SLA may be hard and expensive to manage internally. Highly elastic cloud services require an architectural approach that focuses on application independence and horizontal scaling across multiple datacenters. By application independence, I mean that a surge in traffic from one customer should not impact the performance of other customers, and a surge in traffic from one component of the application (let’s say it is a reporting portal) should not have an impact to other components of the application (for example, an order processing module). Architecting a highly scalable system with a high degree of independence requires multiple database server farms and possibly even multiple database technologies (e.g. relational databases for OLTP and NoSQL for analytics). An architecture like this requires a substantial amount of database administration and a high degree of complexity.

The decision to choose between leveraging a DBaaS versus doing it yourself (DIY) depends on many factors like time to market, skillsets of the team, resource constraints, budget constraints, desired SLA of the service, criticality of the service, complexity of the architecture, and others. IT often likes to be in control and may default to a DIY model without considering the benefits of DBaaS. A best practice is to list the pros and cons of DBaaS and match those up to the business priorities. If DIY is the selected approach, it should be noted that moving to a DBaaS provider at a later date is a much simpler task than choosing a DBaaS and deciding to move to a DIY approach later. I have seen organizations move from a DIY MySQL implementation to an RDS implementation in a week. I can’t imagine the same results for migrating off of a DBaaS because a team would have to build out all of the functionality that the DBaaS provides. It would likely take weeks to months to break the dependency on a DBaaS.

To summarize, understand the costs and benefits of DBaaS and understand the tradeoff between agility and control. With DBaaS one becomes much more dependent on a vendor for the success of the delivery of the cloud service. In return one gets improved speed to market, lower maintenance costs, and increased opportunity costs by reducing the amount of IT resources required to administer databases while increasing the amount of IT resources available to contribute to building more business functionality.