The Three Elements in an Enterprise Multi-Cloud and ON-Prem Relational Database Service (RDS)
Let's take a look at the three elements in an enterprise multi-cloud and on-premise relational database service (RDS).
Join the DZone community and get the full member experience.Join For Free
Over the past three years, Windocks has evolved into a multi-cloud and on-premise Relational Database Service (RDS), delivering secure production databases in seconds to any SQL Server environment, providing freedom and modernization of SQL Server data operations:
“Windocks is a multi-cloud and on-premise Relational Database Service (RDS) that utilizes any enterprise storage to provide secure data delivery to any SQL Server environment, using any on-premise infrastructure or public cloud.”
In this article, we'll take a look at the three elements involved for enterprises evaluating strategies for automated database delivery for DevOps and Cloud Native architectures. Full disclosure, I am a co-founder at Windocks, which is used as a reference for certain points in this article.
Database Cloning With “Any Source”
Enterprise storage is a diverse landscape composed of storage arrays, hyper-converged systems, secondary storage systems, and Windows and Linux file systems. A Relational Database Service (RDS) should work with any storage system, providing read/write supporting storage volume snapshots or Windows Virtual Hard Drives (VHDs). Both deliver database clones in seconds while consuming virtually no additional storage. The RDS must automate and manage the varied moving parts, providing complete lifecycle management of the storage, as well as provisioned containers and their mount points.
As production arrays are upgraded, it’s common for older storage arrays to be redeployed to support dev/test and other uses. Support for diverse storage systems is useful for organizations that have grown by acquisition.
Windows VHDs are growing in popularity by providing developers and DBAs the means to modernize data operations independently of storage admins. Full or differential backups are used to build VHD-based clonable images, which in turn, deliver clones in seconds. This approach is popular on public clouds. John Hancock uses backups from SQL Azure to build clonable images that serve cloned databases to SQL Server containers. Production data is masked and prepared for different groups, and TB class environments are served in seconds with very low storage usage.
Windocks is an example of an enterprise RDS that supports the delivery of database clones from any enterprise or cloud-based storage system.
Secure Data Delivery for Any SQL Server Target
While containers represent the future and are recommended for development and test, containers do not meet all use-cases. SQL Server replication is an example configuration not currently supported by SQL Server containers. Microsoft's very popular SQL Server 2017 Linux container support is also evolving over time and illustrates the importance of an RDS strategy that supports both containers and conventional instances. In addition to serving the full range of SQL Server targets, the RDS should also support both automated provisioning for Continuous Integration testing, as well as user provisioned environments.
RDS data images should be immutable and incorporate user/group privacy policies and role-based access. SQL Server images should support TDE encryption, third-party Encryption Key Managers (EKM), data masking, and other data security policies. Images should also include the metadata to support a data catalog similar to the new Azure data catalog for search and reporting. Immutable images combined with metadata provide an auditable record of data use within the enterprise, improving data governance.
Containers are popular as a means to realize economy with an average 5:1 reduction in VMs when using containers on a shared VM. Database cloning delivers a 99% savings in storage over duplicated data environments.
Portability With Any Infrastructure or Public Cloud
The primary path for portability is for the RDS to run on a broadly supported Operating System, such as Linux or Windows, enabling the solution to run on any public cloud or private infrastructure. Running on a supported, COTS-based OS enables the RDS to deliver the freedom to run on any on-premise infrastructure or public cloud with data image portability.
On-premise data delivery has been limited to volumes served from storage arrays and secondary copy appliances. Storage arrays and appliances serve cloned volumes and files with PowerShell scripts used to create the volumes and mount databases to a target. These solutions are costly to implement and manage and require dedicated storage admins. An RDS runs as an Operating System Service and provides DBAs and developers the ability to create images and serve up environments without impacting storage operations. The RDS automates the creation of storage system snapshots or clones with automated delivery to the selected application environment.
A leader in hyper-converged storage recently reported that over half of their fiscal year deployments involved support for both on-premise and cloud use. Forward-looking IT decision makers focus on solutions to support both on-premise and public clouds.
Aligning Data Operations With Business Needs
A Relational Database Service automates the use of the storage infrastructure and provides superior alignment of data operations with business needs. Legacy storage systems struggle to expose data to applications and lack the metadata needed to align operations with business needs. An RDS operates at the application layer providing developers and DBAs support to automate creation and delivery of secure data environments. RDS metadata includes users and groups, the origin of the data, and privacy policies applied. Managers will have full visibility into the data lifecycle and the steps needed to improve hot fix throughput and effectiveness, and other operations.
RDS = DevOps With Data
DevOps strategies are ubiquitous and most advanced for support of .NET and Java for front-ends and middle-tier applications. Organizations continue to struggle, however, to incorporate relational backends into Continuous Integration processes. Industry surveys indicate the average database backend test environment is updated twice monthly or less, and few organizations achieve adequate test coverage with VM or shared SQL Server instances.
It’s time to modernize SQL Server dev/test support with production database clones to enable “full stack” development and test for improved test coverage and quality. Database clones provide full read/write support are provisioned in seconds without impacting storage and provide the best environment for functional and unit testing. While Docker containers are recommended for dev/test, organizations also need data delivery for all SQL Server environments. Windocks is an example of a modern RDS that provides support for "any source" with delivery to "any target" with support for any "on-premise or cloud."
Opinions expressed by DZone contributors are their own.