The document discusses two Database as a Service (DBaaS) offerings in OpenStack: Trove and MagnetoDB. Trove aims to provide relational databases but suffers from a large feature gap compared to other DBaaS providers and lacks a clear plan for scalability and availability across its supported databases. MagnetoDB aims to provide a key-value API but its use of multiple backends prevents a unified approach to scalability and availability. The document argues both offerings are flawed and doomed unless their scopes are narrowed.

1. Why OpenStack
Database as a Service
offerings are doomed
SHASHANK CHAKELAM

2. Introduction
 Focusing on two Database as a Service (DBaaS) offerings that
OpenStack provides:
 Trove (https://wiki.openstack.org/wiki/Trove)
 MagnetoDB (https://wiki.openstack.org/wiki/MagnetoDB)
 Trove started off as a Relational Database as a Service offering. It is
currently a first class project in the OpenStack community
 MagnetoDB aims to provide a key-value store API layer. It is currently
not a first class project in the OpenStack community but is backed
by one of its bigger players – Mirantis
 There are two fundamental problems with these services right now:
 Huge feature gap
 Wrong future direction

3. Trove
 Started off as a Relational Database as a Service offering
 The base design seems so similar to AWS RDS that I wouldn’t be
surprised if one of the initial guys worked there before :)
 Community participation seems low for the past couple of months
 Tesora is a commercial DBaaS provider that uses Trove as the
backend

4. Trove – feature gap
 There are a number of features that customers implicitly expect to be a
part of a DBaaS offering because of AWS RDS and Microsoft Azure but
are missing from Trove:
 Mechanisms for Database Upgrade
 Mechanisms to apply security patches to the database, OS, libraries, etc.
 Mechanisms for updating service without causing downtime
 Automated recovery mechanisms
 High Availability
 Scalability
 Data encryption
 User management
 Standards compliance
 And many, many more!

5. Trove – future direction
 Trove has started branching out to support non-relational databases
too such as Cassandra, MongoDB and Redis. This causes the base
framework to become extremely thin and lose value. Essentially,
Trove is moving towards becoming nothing more than a simple
database provisioning service
 There is no concrete plan on scalability. With so many relational and
non-relational databases supported, it’s highly unlikely that a unified
scalability model can be created
 There is no concrete plan on availability. The only offering right now
is MySQL read replicas. Again, with so many databases supported,
it’s unlikely that a unified availability model can be created. Also,
there is no modelling around regions/data centers for MultiAZ type
of offerings

6. MagnetoDB
 Tries to be a key-value API layer that you can plug a variety of
backends to use. The default one used for development is
Cassandra
 The fundamental problem with this too is scalability and availability.
A key-value store interface on it’s own is not useful if you don’t have
the service be scalable and available. Given the variety of
pluggable backends that you can use, there is no unified way of
ensuring these characteristics
 MagnetoDB should just stick to a single backend and create a
useful service using it. Else, simply build a key-value store from
scratch and not just the API layer

7. Thanks! Questions?