Database DevOps in the Cloud: A Step Beyond Database-as-a-Service
When talking to one of our close partners recently, we started discussing the difference between Database-as-a-Service (DBaaS) and Database DevOps in the Cloud. We spent quite some time on the topic and it became apparent that even for people working in the industry, all these new terms and offerings can be confusing. Now putting myself in the shoes of our customers, I wondered how they feel?
Motivation enough to help clarify these two terms. On top of this, with IT departments moving away from ‘built-to-order’ and embracing an ‘assemble-to-order’ approach, it is even more important to understand all types of cloud solutions available in the market.
With this blog, I will clarify the terms DBaaS and Database DevOps and most importantly contrast them. Lastly, I will make some references to the Lemongrass solution offering.
Let’s start with some simple definitions…
Database-as-a-Service: Definition
DBaaS is a service provider offering, consisting of a fully-provisioned database for the customer and its users. The database – which is provisioned in either a public cloud like AWS or Azure, or in the service provider’s private cloud and sold via a subscription – frees the users from the database provisioning, as well as the management of the database.
Depending on the offering, a customer will have the ability to access the database on root level and make customer-specific adaptations to it. Frequently however, this root level access is not granted, rendering the DBaaS as a black box for users. Especially for sophisticated use cases, this frequently creates a problem.
Database DevOps in the Cloud: Definition
Most of us know how the term DevOps was coined: the attempt at bringing Development and Operations teams together more closely. This is done by breaking the boundaries between their siloes, with the goal of increasing quality and speed of IT releases that deliver business capabilities. Hence, DevOps is not about tools or technology, but about improving IT delivery and therefore improving business results.
What is the Difference?
Simply put, DBaaS is mostly about moving the responsibility and location of a database and its core operations from in-house to a third-party service provider, combined with a shift towards a subscription – hence a move from CAPEX to OPEX. DBaaS is a great step into the cloud for any company, but for a DBaaS to provide transformational business value, it needs to entail qualities of Database Cloud DevOps. Only then will it give your business new capabilities and help transform your company.
The goal of Database DevOps is process improvement and hence is like lean principles. In lean, a company is concerned about improving the entire value chain from company to customer. This broad definition is more and more adopted within DevOps circles.
Look, for example, at the concept of CAMS – which has since been extended to CALMSS by Eveline Oehrlich and team at Forrester:
Culture, Automation, Lean, Measurement, Sharing, and Sourcing.
DBaaS and Database DevOps: Detailed Comparison
I researched several market offerings for Database-as-a-Service and DB DevOps and found the following differentiation when looking at the initial provisioning, operations, as well as governance side of databases in the cloud.
The Business Side of Cloud Database DevOps
Now we are finally coming to the exciting part. What does a DBaaS/Cloud database with strong DevOps capabilities add to the business – both when looking at bottom and top line? Without further ado, here we go…
TOP LINE: Scaling up for End-User Performance and Adding Sites for High Availability
Imagine a retailer that can scale their online storefront dynamically when business booms. Typical times are Christmas and Black Friday, but there could be other ‘booms’, for example during online promotions or sales events.
Key to successful operations during this time is to ensure end-user performance on all systems. With highly automated Database DevOps, scaling up a production to maintain or increase end-user performance is a matter of a few clicks – the same as with adding high-availability sites for this same company to ensure uninterrupted operations during these critical times. Especially with the ability to adjust for only a few weeks out of the year, running redundant high-availability clusters now becomes affordable.
BOTTOM LINE: Rightsizing Systems and Turning Non-production On and Off
-> Rightsized Systems
Like the above retail example, having the ability to scale up a mission-critical system in minutes with very little effort removes the need to scale cloud databases for maximum annual load and/or the 3 year growth. Our team at Lemongrass frequently sees environments that are sized 2.5x at the vendor-recommended maximum size. Simply speaking: this is waste!
We typically size all our production environments with a little headroom and then very carefully watch the testing and operations phases via sophisticated cloud monitoring and management capabilities.
Once datasets grow – or usage peaks, we can provision additional resources during running operations, in minutes.
-> Start/Stop for Non-production Systems
Another great way of saving cost is by proactively and automatically managing all non-production resources. Why not turn them off?
At Lemongrass, we have capabilities to stop all complex enterprise workloads that we are managing with a single click in a graceful fashion.
-> Better Though… Idle Stop
But what if I cannot foresee when systems are needed? Valid question, and with powerful Database DevOps, the management layer should be able to determine when resources are idling. At least that is what Lemongrass does.
SUMMARY – This is Relevant for ALL Businesses
Making end users happy – and therefore growing revenue on the top line combined with saving cost on the bottom line – is a formula relevant to all businesses.
Remember:
