Thoughts from Couchbase Connect 2014 [feedly]

----
Thoughts from Couchbase Connect 2014
// Build AWS-compatible Private Clouds with CumuLogic

This week our CTO, Rajesh Ramchandani, was invited to participate in a "Cloud Panel" discussion at Couchbase Connect, along with representatives from CloudSoft (Alex Heneveld) and ElasticBox (Monish Sharma).

While much of the discussion was focused on how each company's products support rapid and easy provisioning of Couchbase Server environments, it was interesting to note how a Database-as-a-Service (DBaaS) model is distinct from more generalized provisioning automation. DBaaS (or really any "as a Service" solution) focuses on not just provisioning, but ongoing management and change activities for the deployed system. The intent of providing databases "as a Service" is to allow the consumer to work with higher level abstractions that imply management of the deployment by the service itself.

At CumuLogic, we view application deployment as a three layer model:

1. The application itself
2. Supporting back-end services
3. The underlying infrastructure

Each of these layers lends itself to taking a different approach.

At the top layer, applications (be they custom written or packaged) are best approached via a provisioning automation solution. Configuration management tools, application blueprinting or virtual appliances are all potentially appropriate for your needs. This is particularly true when dealing with custom applications, for which there really isn't an opportunity to create a utility-like service to deliver the code itself.

On the bottom layer you have the infrastructure requirements. This is a layer where we, as an industry, are closest to satisfying consumers via a utility-like approach. These days, an application's infrastructure needs are easily met via IaaS providers themselves, or by infrastructure orchestration software like OpenStack (or even Kubernetes+Docker). There are certainly differences between each public IaaS cloud, as well as between the various software that can be employed for private cloud environments, which is why we advocate that a multi-provider framework is a necessity for application owners.

Last, we get to the middle layer, the place where databases live. Databases (and other similar "software infrastructure services", like cache clusters and message brokers) are indeed applications that can be deployed similarly to custom application code. But is that the right approach today? We believe that this layer has evolved to the point where it needs to be consumed "as a service". This is a natural evolutionary step, and one that has been proven to be successful within the worlds largest public cloud providers. The deployment and management of a database isn't unique to you or your application. It's repetitive work, and best practices are well documented.

So while it's possible to deploy databases using the same techniques that you would for your application itself, DBaaS offers a way to skip that effort and offload both installation and management of the system to software designed for just that purpose. Application owners should focus on how they use the databases, not how they install and manage them.

We would love to hear your thoughts on this approach. Please get in touch, or feel free to request a sandbox environment to experience the simplicity for yourself.

----

Shared via my feedly reader

Sent from my iPhone