This post was authored by Maksim Malygin, Global Solutions Architect Nutanix

Almost every application that you are interacting with through the day, from your company’s CRM to the game that you are playing on your phone, and self-service POS at the grocery shop is supported by a database, either cloud-based, on-premises, and, possibly, delivered as a service. These databases are used by the applications to operate and process the data and directly impact how applications scale and perform; making database platform a keystone for business success. With the rapidly growing number of applications, the database market grows as well and is expected to reach USD 155.50 Billion by 2026 (link).

At the same time, DBaaS (database-as-a-service) is shaking the way how databases are used by the developers, by removing the need for them to manage complex databases or deal with DBA and infrastructure teams so that they could focus on the application development instead. Let’s take a closer look at the modus operandi that makes it possible.

If you have spent some time in the enterprise IT world, you have probably heard about the “Everything-as-a-service” (XaaS) approach. And most likely, you have asked yourself why an IT organization should provide something as-a-service to the enterprise when the traditional approach seems to work fine? In a few words, a customers’ view on how IT should be consumed and accessed changed during the last decade. In a world where we have Uber, Airbnb and Public Cloud, consumption models with instant availability and pay-per-use became a new standard. The same applies to enterprise IT – internal customers want quick and easy access to predictive, outcome-based, adjusted to business needs services that they do not have to fund, wait to be built, and worry about support.

The as-a-service approach streamlines IT relationships with business users, helping an enterprise to create efficiencies, reduce transaction cost and transaction time. For the IT organization, XaaS means that it is not an “IT Operator” anymore, but a respected business partner that delivers a service and provides an easy and clean chargeback model.

DBaaS birth trauma and how to cure it

While most of IT made a move to the "service" model quite smoothly, database teams faced a few issues that made the transition hard to crack. However, this does not mean that building a DBaaS in a private enterprise cloud is impossible. Let’s dig into how these issues and how to solve them, making sure that DBaaS built is an enterprise-grade service.

Issue #1: Segregated compute, storage, and database

It's not easy to integrate provisioning of underlying compute and storage resources (even delivered as a service) into the DB provisioning workflow. Traditionally, DBA needs to request storage space to be allocated, compute to be provisioned and OS to be installed; often this has to be done by 3 separate teams. This could be partially solved with tools like ansible, but it’s still would not be an end-to-end automation.

To solve this issue once and for all, a single platform that combines compute, storage and virtualization is the best approach. Using a hyperconverged platform, we can achieve an easy, streamlined and consistent provisioning of the infrastructure services which (thanks to the Nutanix API!) can be done programmatically. Nutanix Era takes care of all steps required to provision a VM for the new DB server, combining the power of the hyperconverged platform and automation.

Issue #2: Database server configuration and security

Rolling out a new DB server (OS/DB) and applying enterprise configuration standards (from performance to security and backup) is another bottleneck that may affect a provisioning SLA.

Once we have a stable foundation, configuration standards (both for VM and DB) can be applied automatically, making sure that we will get consistent performance (again, this could be a challenge if DBA does not control the platform – or standards validation needs to be performed for each possible storage/compute variation). These optimized DB configurations are provided by Era and are proven to deliver maximum performance on the Nutanix cluster. Security (from the infrastructure point of view) becomes much easier with the automated STIG implementation that is built-in to the Nutanix AOS; security standards for DB are applied by Era on top of it.

Issue #3: How to meet SLA?

It could be a challenge for the DBA team to ensure that performance, availability and backup/recovery SLAs are met since they do not control most of these services.

Tight integration with the underlying platform is a key:

• A platform should meet the same (or even more strict) SLA to guarantee that DBaaS is capable to provide the level of availability required (provision clustered DB servers to add more nines). While Nutanix’s hyperconverged platform could be easily configured to meet the availability SLA, Era automates clustered DB server provisioning.
• DB performance heavily relies on compute and storage stability (no noisy neighbors) and correct sizing. Since the first one is virtually impossible on the Nutanix cluster, the only thing that needs to be done is the right sizing of the VM instance.
• Backup and recovery of the DB could be easy if integrated with the storage snapshots. However, in the 3-tier case a complex standalone “snapshot managers” need to be used, making configuration and operations very complex and time-consuming; while, in case of Nutanix Era such integration is almost invisible – there is no need to install, configure and maintain – it just works, providing a DB-consistent backups and “Time machine” capabilities.

Issue #4: How to keep it up to date

When you have a dynamic DB environment with a lot of database hosts/instances, database and OS patching may become an almost daily (nightly!) routine that affects security and availability SLAs.

To solve this issue, Era provides an automated, one-click DB server patching mechanism. It’s also possible to test DB patches before publishing it to minimize the possible impact on the production instance. 

Issue #5: Slow CDM process that blows up storage usage

Cloning DB from the production to the Dev/UAT environment requires a lot of data to be copied and masked, making DBAs to work over weekends non-stop and making storage vendors happy.

As we mentioned earlier, integration with the storage snapshots make backups easy and delivers huge storage savings. Combining this with the automated VM and DB provisioning plus a data masking solution provides an ability to perform CDM in a fast and resource-efficient manner. 

Issue #6: Big and dispersive database portfolio

An average enterprise may use 4-6 database types – from traditional like Oracle and MSSQL to the NoSQL DB; for DBA it means that all issues above need to be solved for each DB type.

As of today, Nutanix Era supports 5 database engines: Oracle, Postgres, MySQL, MSQL, and MariaDB, with more planned in future releases.

Now, let’s take a look at the few concepts and tools that could make DBaaS happen.

What it takes to run a service

ITIL (a bit boring reading, but very useful!) says that service definition should encompass a large number of elements  but we will focus on the most important, namely:

• Service and asset criticality
  • How critical could be a business service that will use this IT service
• Service level requirements/ targets
  • Provisioning time / Availability / Reliability / Performance / Capacity etc
• Service interface
  • How this service could be consumed
• Pricing model
  • Chargeback model for the service

All of the metrics above are easily measurable and create a strong foundation for the DBaaS (if you can’t measure it, you can’t manage it!):

Criticality is the first thing that needs to be verified to understand if the service could be used to support specific business requirements and it defines service level requirements (which reflect business SLA). Criticality is generally defined as one of the following categories:

Once we have identified a criticality, service level requirements could be defined as well:

Nutanix Era allows to create SLA profiles matching the service definition, and once all criticality levels and related SLAs have been identified, they can be translated to the Era configuration:

During the DB provisioning, a specific SLA would be applied to the database instance:

And last but not least, compute and DB sizes need to be defined in the service definition:

…and published in Era

Bringing it all together

Creating a new DBaaS offering can be a tough, challenging process; maintaining it in a healthy state could be even more challenging. Nutanix Era was purposely built to cure the DBaaS “birth trauma” – it not only relieves a lot of DBA pains; it also provides a capability to make DBaaS delivery fully aligned with the service design process.

2019 Nutanix, Inc.  All rights reserved. Nutanix, the Nutanix logo and the other Nutanix products and features mentioned herein are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s).