----
DBaaS Service Delivery Options for Cloud Providers
// Build AWS-compatible Private Clouds with CumuLogic
Service providers have a challenge: How do they provide the right cloud experience to their customers? Are they focused on providing a shared multi-tenant public cloud? Do they create private clouds for each of their customers? Are they looking to offer a blend of public and private cloud options? And most importantly, how do they provide value above the provisioning of virtual infrastructure?
At CumuLogic, we believe that Database-as-a-Service (DBaaS) has become one of the most critical components to a compelling cloud offering, alongside compute, storage and networking. It's a rapidly growing market, and those providers that have the foresight to include database services will reap the benefits of this market demand.
CumuLogic's DBaaS software platform gives cloud providers a wide variety of options for delivering DBaaS to their customers, options that support any infrastructure model that fits their customer's needs. Our software allows each provider to taylor their service delivery model to best fit their customer-base, including deployment options like an integrated experience with your existing cloud, an appliance-based deployment of DBaaS per tenant, integrated private cloud experience, multi-cloud hybrid scenarios, and even bare metal DBaaS.
In this post, we'll review the basics of the CumuLogic DBaaS Platform's features and architecture, and then delve into the variety of DBaaS delivery models that CumuLogic makes possible.
If you want to hear more about the architectural flexibility of the CumuLogic DBaaS Platform, we are hosting a Live 30-Minute Webinar: A Multitude of DBaaS Delivery Options on Thursday, November 6, 2014 from 9:00 AM to 9:30 AM PST. We promise it will be fast and informative!
Basic Architectural Components
In order to understand how the CumuLogic DBaaS Platform is able to provide this flexibility, it's important to start with a basic understanding of our architecture. The architecture is made up of two main components: the controller and the deployed instances.
First, let's discuss our controller software. The CumuLogic controller (sometimes referred to as management server) is a stateless Java-based software package that exposes both a web-based user interface (for both admins and end users) and a RESTful API (again, with both administrative and user-centric functions). The controller is designed to work as a single instance, perfect for POC or appliance-based delivery, and scales horizontally to provide both higher availability and additional capacity. The controller nodes are connected to a MySQL (or compatible) database to store both configuration metadata and deployed instance monitoring data.
In order to provide maximum flexibility, the controller has been designed to support up to 20 distinct "target clouds" (more on this in a bit). A single moderately sized controller (usually deployed as a virtual machine) is capable of supporting up to 1,000 user-deployed database nodes. Critically, our controller does not sit in the data path between applications and the managed database instances that it's managing for users.
This leads us to the deployed instances portion of the architecture. Instances are the virtual (or bare-metal) systems that are given a roll within a deployed database cluster. In the case of an IaaS-based infrastructure, deployed instances are created on-demand as users request database services. In another model, the controller is able to allocate nodes of a pre-provisioned pool of systems to receive the appropriate software required to play it's part in a new database environment. Each deployed instance runs a basic configuration of the CentOS operating system, the specific database software required for it to play its role (MySQL, MongoDB, etc…), and a small CumuLogic software agent that serves as our controller's touchpoint on that instance.
We mentioned that the controller is able to support up to 20 "target clouds", and this is an important part of the flexibility of the platform. Our system is able to provision virtual infrastructure on any cloud environment that supports the AWS EC2/EBS, OpenStack, CloudStack or vCloud APIs. Any specific API endpoint represents a single target cloud (regardless of the size of the target). We also include support for bare-metal servers (or even pools of pre-provisioned virtual machines) as a "target cloud" that can receive the database application payloads.
So to simplify: The CumuLogic DBaaS controller uses any number of options to get the required infrastructure, and then manages deployed instances via a lightweight agent.
Integrated Public Cloud Experience
The most common approach the cloud providers take with our software is to provide a DBaaS experience that is integrated into their larger cloud service environment. In this scenario, the controller is deployed along-side the IaaS control software. End users are given access to the DBaaS functionality through either the provider's own UI (communicating with our controller via its APIs) or linked to the CumuLogic web-based UI via the provider's selected SSO protocol. Also typical to these installations, providers will use the CumuLogic admin APIs to automatically push tenant identities to our controller.
Single Tenant Private Cloud
The private cloud option is really a variation on the "Integrated Public Cloud" model, but the deployment(s) are done per-customer as part of their private cloud environments. This obviously provides for customer-level tenancy to be isolated to that particular IaaS environment, with multi-tenancy at the user / department level happening within the private cloud.
DBaaS On Another Provider's Cloud
This is one of the more novel cloud provider use-cases, given that it relies on a third party's IaaS cloud as the underlying infrastructure for the database deployments. Since the CumuLogic controller is able to communicate with a number of different APIs to build the virtual infrastructure necessary to host the database instances, a provider has the option of offering their end users DBaaS on external public clouds.
Single Tenant Appliances on Your Cloud
CumuLogic offers its controller in a virtual appliance form-factor, which could easily be added to a cloud provider's service catalog of available templates. In this model, the user would choose to deploy CumuLogic from the catalog, and be given administrative control of that system in order to allow them to self-manage the DBaaS experience within your IaaS environment.
Bare Metal DBaaS
For some customers, there is still a strong draw to provision databases on bare-metal servers. CumuLogic supports this model, allowing a provider to provide the controller with a pool of pre-provisioned systems that only have to be on the network (and accessible by the controller) in order to be allocated for user DB requests. The pre-provisioned systems don't have to have database software on them ahead of time, since the CumuLogic controller will deploy the appropriate application payload (the correct database software) when the system is allocated to play a role in a user's DB cluster.
Hybrid Offering Across Clouds
In reality, all of the options above can be combined into numerous combinations. One of the most obvious models is for the provider to offer both a shared multi-tenant IaaS cloud, alongside per-customer private clouds. CumuLogic can let your customers use DBaaS across both environments, using the same controller, giving a consistent experience regardless of the infrastructure selected by the users for each database instance.
Wrapping Up
The architectural flexibility of the CumuLogic DBaaS Platform's software gives cloud providers quite a few deployment options, allowing you to taylor your DBaaS services to the infrastructure demands of your unique customer-base.
Please join us for our Live 30-Minute Webinar: A Multitude of DBaaS Delivery Options on Thursday, November 6, 2014 from 9:00 AM to 9:30 AM PST, or feel free to get in touch to schedule a meeting with our team!
----
Shared via my feedly reader
No comments:
Post a Comment