Last week, CumuLogic launched a preview edition of its Database Service Broker for Cloud Foundry, a self-service managed SQL and NoSQL database service platform. Database Service Broker provides functionality equivalent to public Database as a Service (DBaaS) platforms such as Amazon Relational Database Service (for SQL) and Amazon DynamoDB (NoSQL), but with the database hosted on-premises.
We first came across CumuLogic in 2011, when it was a competitor of the then-nascent OpenShift and Cloud Foundry open source projects and of public PaaS from Heroku and others. Around a year or so ago, CumuLogic made a transition to focus not on the provision of the PaaS itself, but on database services to applications in either IaaS or PaaS deployments. This sector is sometimes referred to as Database as a Service (DBaaS), not to be confused with DaaS (Desktop as a Service). By concentrating on the database, the company is able to provide more focus to its development and go-to-market strategy.
It is worth stressing that CumuLogic does not provide a hosted Database as a Service solution like Amazon and many other standalone DBaaS vendors. CumuLogic is a software company. Its approach to the marketplace is twofold:
- To allow service providers to offer DBaaS functionality as part of a full-service IaaS, thereby increasing their margins over a standard hosting service model.
- To provide on-premises DBaaS for enterprises implementing on-premises IaaS and PaaS solutions.
In case one, the DBaaS has a per instance-hour pricing model to match a hosting company’s own pricing models. In case two, pricing is by annual fee based on deployed hardware specification.
CumuLogic’s Database Service Broker for Cloud Foundry relates primarily to case two and is targeted at enterprises deploying on-premises Cloud Foundry–based PaaS solutions from Pivotal (and others).
DBaaS provides a way of connecting to a database outside of the instance or container in which the application is running. The database is managed via a layer that provides:
- Service catalog, provisioning, binding, etc.
- Backup and restore
- Clustering and replication, sharding, etc.
- Failover and self-healing.
None of these functions come out of the box in the Cloud Foundry Services for either mySQL or NoSQL databases; they are provided via the service configuration and deployment capabilities that CumuLogic developed for its PaaS solutions. This means that in a combined CumuLogic–Cloud Foundry deployment, the database and the application are actually sitting inside different Platforms as a Service—slightly intellectually unsatisfactory, if perhaps of little practical concern. CumuLogic’s Database Service Broker for Cloud Foundry is open source and downloadable from GitHub; however, this is essentially just the front end and glues into its proprietary framework.
CumuLogic’s SQL database functionality is API-compatible with Amazon Relational Database Service (RDS), allowing scripts and tools to be reused. It provides a REST-based API for both SQL and NoSQL databases, both of which can be managed through the same “pane of glass.” If you are a service provider (or have internal accounting in place for an on-premises PaaS), it offers billing integration.
DBaaS provides a separation and an abstraction between the deployment of the application and the deployment of the databases with which it communicates. Clearly, communication between the database and the application can be critical to application performance in both SQL and NoSQL databases. While the separation between application and DBaaS is useful from a development and deployment perspective, it can’t be done in such a way that it introduces high (or variable) latency between application and database. For this reason, enterprises seeking on-premises IaaS and PaaS solutions are also likely to seek on-premises DBaaS solutions to go with them, particularly as the location of the data is, in any case, most often the driver toward use of on-premises rather than public clouds.
Furthermore, the failure of a hosted DBaaS vendor can be extremely inconvenient. (Users of the standalone hosted DBaaS vendor Xeround were given only fifteen days to remove all their data and find an alternative when that company failed last year.) With CumuLogic, the data is held on-premises, removing the risk that a vendor failure could suddenly make it unavailable.