----
Bringing RDS Simplicity to Any Infrastructure
// Build AWS-compatible Private Clouds with CumuLogic
(For those of you that read our previous post, DBaaS Service Delivery Options for Cloud Providers, this will be a similar discussion about the architectural options available to CumuLogic customers, but with an enterprise IT focus.)
There's no questioning the adoption of DBaaS within the enterprise. It's becoming more and more prevalent to find that at least one application team within a company is using Amazon's RDS capability, or other DBaaS offerings from AWS and elsewhere. The fact is that the manual efforts required to properly deploy and manage a database is much greater than it needs to be. It's also simply not adding any value to your company to spend time dealing with technology management tasks that are easily abstracted. Application teams know this (they want to focus on the valuable coding activities), and they see how easy it is to get backend data services from external providers.
The challenge for IT departments is that they need to find a way to bring some level of order to this DBaaS adoption trend. But, IT should never seek to halt progress and technology adoption. Instead, IT needs to accept change the focus on finding ways to actually embrace and extend the technologies and services that the rest of their organization are adopting. IT's role is a dual focus on business enablement and organizational risk mitigation.
With that in mind, CumuLogic's DBaaS software platform was designed to help IT meet that dual purpose for data services. Our software gives the enterprise IT teams a wide variety of options for how DBaaS can be employed to balance the unique risk / reward structure that's unique to every company (and every application). This includes DBaaS deployment options like an integrated experience with your existing private cloud, an appliance-based deployment of DBaaS per application team, enterprise-controlled DBaaS on a public cloud, 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 for the enterprise.
If you want to hear more about the architectural flexibility of the CumuLogic DBaaS Platform, and it's benefits for the enterprise, we're hosting a Amazon RDS-Like Simplicity on ANY Infrastructure tomorrow (Thursday November 13) 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 it's 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 DBaaS / IaaS Experience for Private Clouds
The most common approach for enterprise use of CumuLogic is to provide a DBaaS experience that is integrated into their larger private cloud 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 it's APIs) or linked to the CumuLogic web-based UI via enterprise's preferred SSO protocol. Also typical to these installations, enterprises will use the CumuLogic admin APIs to automatically push tenant identities to our controller. CumuLogic can also link into an Active Directory or other directory system that supports LDAP.
DBaaS on a Public Cloud
The second most common enterprise use-case for CumuLogic's software is to use the platform to manage their own DBaaS capability on top of a public IaaS provider's cloud. 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, the enterprise gets to take advantage of the scale and diversity of the public cloud market while controlling the "higher level" database services.
DBaaS Appliance in Service Catalog for App Teams
CumuLogic offers it's controller in a virtual appliance form-factor, which could easily be added to an enterprise service catalog. In this model, each application team 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. The benefit here is very low support costs for IT, but powerful DBaaS capabilities being offered directly to the application teams that want them.
DBaaS on Bare Metal or Virtual Infrastructure
Every single enterprise that we have spoken with deals with the reality of existing infrastructure capital investments. That means that there are huge amounts of physical and virtual infrastructure capacity in place, often under-utilized. There's also a strong desire to provision databases on bare-metal servers. CumuLogic helps here by letting pools of pre-provisioned systems act as target infrastructure pools for DBaaS services. These systems really 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 need database software on them ahead of time (and actually shouldn't), 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 Public + Private
Each of the previous options were focused on a single "type" of infrastructure, but enterprise adoption of cloud is clearly headed to a hybrid model. With that in mind, CumuLogic is easily able to let an enterprise use a mix of public an private clouds as infrastructure options for DBaaS deployments. Using the same DBaaS controller, application teams can have a consistent DBaaS experience almost anywhere. They can easily place their dev / test instances on a public cloud and have production in the private cloud environment.
DBaaS Across Multiple Public Clouds
For those enterprises that are moving to a model of only deploying new systems into public clouds, we also offer a compelling deployment option. With a public "only" approach, it's easy to get pulled into the higher level services (beyond the more commoditized virtual infrastructure) of any particular public cloud. This leads to a high degree of lock-in. CumuLogic can help by acting as the DBaaS controller, but letting the enterprise use any number of different public cloud partners for the underlying infrastructure. Databases can be deployed into either (or all), and the application teams will know that they will be getting a consistent service experience across the board.
Wrapping Up
The architectural flexibility of the CumuLogic DBaaS Platform's software gives the enterprise quite a few deployment options, allowing you to embrace the DBaaS demands of your business while easily balancing the risks and rewards inherent in any new technology decision.
Please join us for our 30 minute webinar Amazon RDS-Like Simplicity on ANY Infrastructure on Thursday, November 13, 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
Sent from my iPhone
No comments:
Post a Comment