Turn your SAP databases into a strategic weapon for digital transformation

By 
Swen Conrad
Technology

Database DevOps in the Cloud: A step beyond Database-as-a-Service

By 
Swen Conrad
, posted on
, posted 
August 7, 2017

What’s a Rich Text element?

The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.

asdsadsadn sldjflsdjf

Static and dynamic content editing

A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!

How to customize formatting for each rich text

Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.

When talking to one of our close partners last week, 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 or our customers I wondered how they feel?

Motivation enough to help clarify these two terms. On top, 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 Ocean9 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 providers private cloud and sold via a subscription, frees the users from the database provisioning and 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 the 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 it will 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 since has been extended to CALMSS by Eveline Oehrlich and team at Forrester:

Culture, Automation, Lean, Measurement, Sharing, Sourcing.

 

DBaaS and Database DevOps: Detailed Comparison

I researched several market offerings for Database-as-a-Service and DB DevOps and found 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 coming to the exiting part finally. 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 his online storefront dynamically when business booms. Typical times are Xmas 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. – 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.

Please read this blog about Multi-Channel marketing to learn more about a cloud native Retail deployment that benefits from Database DevOps.

 

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 Ocean9 frequently sees environments that are sized 2.5x at the vendor recommended maximum size. Simple 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 and in minutes.

-> Start/Stop for non-production Systems

Another great way of saving cost is by pro-actively and automatically managing all non-production resources. Why not turn them off?

At Ocean9, 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 Ocean9 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. If you disagree, please comment below and tell my why.

Remember:

Not all database offerings in the cloud are equal: Look for ones with strong built in Database DevOps
Back to top