Implementing Sovereign DBaaS using ClusterControl and Conductor – Part I

Part I of this Severalnines blog series will cover one possible mechanism that’s available to materialize the notion of Sovereign DBaaS using Severalnines’ ClusterControl.

In this blog, we will discuss high-level concepts around implementing Sovereign DBaaS (Database-as-a-Service) spanning cloud infrastructure, public cloud, or a mix of private and public clouds, also known as hybrid cloud.

This post will discuss implementing Sovereign DBaaS using Netflix Conductor and Severalnines’ ClusterControl, and offer it to internal customers in your organization to consume via an internal service portal such as ServiceNow. 

Before we get into it, let’s get some terminology out of the way.

What is Sovereign DBaaS?

Sovereign DBaaS is a service that provides access to a database management system in a dedicated tenant in any location that meets data privacy, latency, and cost goals. It enables cloud vendor-neutral and environment agnostic deployment of open-source databases with complete control. 

What is Conductor? 

Conductor is an open-source workflow orchestration from Netflix. Conductor itself has an API that is used to create workflows, which are a sequence of tasks chained together that can interact with multiple systems. 

In our case, you can envision a database deployment workflow whose first task is to provision one or more virtual machines from the infrastructure component (AWS, VMware, OpenStack, etc.), and the second is to deploy a database cluster on those VMs. 

What is ClusterControl?

ClusterControl is an AI-powered database orchestration platform that supports full database lifecycle management in private cloud, public cloud, or hybrid cloud. Specifically, ClusterControl will be used in the database deployment (Conductor) workflow to deploy database clusters.

What are we trying to address?

Large enterprises today use computing infrastructure from a mix of public cloud (namely, the hyperscalers: AWS, Google Cloud, Azure) and their own private cloud infrastructure to deploy mission-critical application workloads. The exact make up depends on a variety of enterprise and application-specific KPIs. Most of these applications need reliable and fault-tolerant databases to store their data. 

Since databases will be located in multiple environments, the question is how to best manage these databases.

Each hyperscaler provides its own DBaaS service. However, the services are unique to the hyperscalers and only available from them. The public DBaaS services from different hyperscalers have different operating models and use different nomenclature. 

As for databases running on-premises, these are typically managed by the enterprise. So the challenge is to come up with a sensible way of managing the entire database infrastructure that avoids multiple operating models for the same database. 

ClusterControl provides a means to set up and manage different types of databases, namely MySQL, MariaDB, PostgreSQL, MongoDB, Redis, Elasticsearch, and MS SQL on public cloud, private, and hybrid cloud infrastructures. The infrastructure on which the databases are set up needs to be provisioned ahead of time and provided to ClusterControl. 

This is where Conductor comes in. With Conductor workflows, you can: 

1. Create a task to set up infrastructure on VMware, Nutanix, OpenStack, AWS, Google Cloud, Azure, etc.
2. Create another task to deploy databases on the infrastructure using ClusterControl to achieve seamless, fully-functional end-to-end database (+) infrastructure deployment and lifecycle management.

Let’s break it down… 

The heart of the coordination and orchestration is a Conductor workflow, as shown in the diagram above. A workflow consists of multiple tasks; and each task has something specific to do.

For example, in our case, the first task when deploying a database cluster is to provision one or more virtual machines on which the databases will run. Therefore, you can envision this task to interact with the infrastructure provider’s API to provision virtual machines. 

The second task in the workflow will be to deploy a database cluster on the virtual machines provisioned from the previous task.

For the sake of simplicity, we can ignore error conditions in each task. However, Conductor workflows can check for error conditions (and return codes) in each task and take appropriate actions, such as choosing one path in the workflow vs. another.

At the end of the execution of our workflow, a database cluster will be successfully deployed and under ClusterControl’s management purview.

Next part of this blog series

In Part II of this blog series on implementing Sovereign DBaaS using ClusterControl and Conductor, we will show how to create a workflow in Conductor with tasks to provision one or more virtual machines and finally deploy a database cluster using ClusterControl.

To learn more about Sovereign DBaaS and its key features and characteristics, be sure to check out our white paper.

Stay tuned for Part II by subscribing to our newsletter and following us on LinkedIn and Twitter.