Why open stack database as a service offerings are doomed
Download as PPTX, PDF0 likes526 views
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.
Why open stack database as a service offerings are doomed
- 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