It's High Time DevOps Stopped Failing DBAs
April 04, 2016

Robert Reeves
Datical

I'm going to make a case that may not be altogether popular: Most businesses still aren't doing DevOps right.

The results of a recent survey called Assembling the DevOps Jigsaw suggest that just 20 percent of businesses (and probably fewer) have fully implemented DevOps. Of course, there's some contention over what constitutes "full implementation" and I'm here to tell you that even those advanced DevOps adopters are likely missing a key piece. Despite claims of "winning" at DevOps, a majority of businesses still haven't married their database with other DevOps processes.

Somewhere along the path to continuous integration and so-called "full" DevOps deployment, the database got left behind in favor of speed through the build, test and deployment phases of application release. It's great that dev teams have been able to automate development processes as much as they have. And the speed gains have been a boon for organizations making an effort to continuously release updates to meet customer needs.

But too many IT departments are still forgetting that every change to an application – and these days there are a lot of changes – spawns a set of corresponding schema updates to the database underpinning the app. While developers have accelerated from one release per quarter to weekly updates, database administrators (DBAs) have remained in their slow-mo silos, manually checking that code changes coming down the pipeline to ensure nothing bad happens to the database. Right now, organizations working within this system are still (barely) meeting their release goals. But the workflow is clearly broken, and soon DevOps teams won't have a choice but to find new ways to address the database. To keep up with the demands of continuous delivery, we all need to start using DevOps tooling for the database.

Recalling the "Three Ways"

It's been a long time since the DevOps movement really took hold. Remember the "Three Ways of DevOps?"

Just in case you need a refresher, generally, they're as follows:

1. Systems Thinking: The first step for DevOps success is the breakdown of organizational silos. The First Way tells us to understand development and operational processes in the context of wider organizational goals, and to focus on the performance of the entire system, particularly by anticipating team member needs and always working to increase flow through the whole system.

2. Amplify Feedback Loops: Many of us live for speed now. Shortening feedback loops between phases of the development process means feedback can be integrated to take action and make improvements sooner. Amplifying these loops also means we can receive and act on feedback continuously.

3. Culture of Continual Experimentation and Learning: We've all heard the phrase "fail fast." Innovation depends on being able to quickly prototype, test and learn. While "fail fast" may oversimplify the Third Way, encouraging teams to experiment and learn from code that doesn't work helps them move quickly to the next thing that will.

Theory vs. Practice

Theoretically, we've all done these things for application development. We understand our organizational goals, automation tools like build servers have helped us shorten and amplify feedback loops, and we've all failed on our way to a fit-and-finished build.

Working from this theory then, the DevOps-led release cycle should be a well-oiled machine. However, if the database is the support framework for applications, we're still releasing products on shaky footing. Even as it has become painfully apparent that DBAs can't keep up with DevOps-powered continuous delivery, teams "following" the Three Ways of DevOps have categorically ignored the database in several ways:

1. While developers code quickly and won't send app defects through to the next step, to QA and certainly not to production, they take for granted the impact their code changes have on the database.

2. Build servers let developers automate app release processes in all environments, but database changes still need to be manually reviewed by the DBA team before being instituted. This slows down the release cycle, increases the chances of manual errors at the database level, and can result in developers coding on outdated versions of the database. In this scenario, feedback loops (automated or otherwise) don't really exist.

3. "Fail fast" is not an option for DBAs. Failure at the database level doesn't necessarily equate to syntactically incorrect SQL. It often means a change has somehow found its way into production that has resulted in an outage. While developers are experimenting, they're creating more work for DBAs who need to protect the database from being the epicenter of a catastrophic failure.

DBAs Don't Have to Suffer

Expanding DevOps cultural and tooling to include the database can solve these problems. With new ways to protect the database, automate and validate changes, and add speed and repeatability to the database-centric portion of release cycles, there's no remaining reason to keep DBAs on the outside of the DevOps "inner circle." We have the tools and the knowledge. It's time to apply the "Three Ways of DevOps" to the database:

1. DevOps teams need to break down the final wall between themselves and DBAs. Because they currently don't understand DBAs' needs and challenges, developers toss database changes over the fence without a second thought. By bringing database change automation into the process sooner application developers will receive feedback about their changes much earlier in the development process.

2. Automating database changes can amplify, speed up or even completely satisfy the need for feedback loops between DBAs and QA. Integrating automated database processes with build servers can add feedback loops earlier in the development process, giving developers the tools to write code that gels better with its underlying data structure.

3. Without a constant, overwhelming stream of database changes to manage, DBAs themselves may be able to experiment and innovate. DBAs will finally have time to focus on The Third Way and work to enhance security, compliance, efficient reporting and what's next for the database.

I'm going to tell it to you straight, DevOps teams: Somewhere in your organization there's a DBA who needs help. You have the DevOps tools and methodologies that DBAs need to move into the future, so start anticipating their needs and stop ignoring the critical databases that support your applications. Only then will you truly master the "Three Ways of DevOps."

Robert Reeves is CTO and Co-Founder of Datical

The Latest

October 18, 2018

Are applications teams prepared to manage the chaos arising from an ever-growing landscape of heterogeneous deployment types? A recent survey of application and operations professionals sought to better understand how the industry is shifting and what the future of DevOps might look like. Here is what the survey uncovered ...

October 16, 2018

More than half of organizations have a dedicated DevOps team to help them better implement agile strategies, accelerate release cycles and ensure continuous development. However, databases have a habit of holding DevOps back ...

October 15, 2018

Test Environment Management can save organizations close to $10,000 for each release, yet only four percent of large enterprises have fully integrated TEM processes into organizational DNA, according to the 2018 Test Environment Management Survey released by EMA and Plutora ...

October 11, 2018

Agile is indeed expanding across the enterprise and there was a significant jump from last year to this year in the percentage of respondents who indicated that all or almost all of their teams were agile, according to the State of Agile 2018 report from CollabNet ...

October 09, 2018

Adopting a modern application architecture is critical to business success and a significant driver of profit growth in today’s digital economy, according to the results of a global survey of IT and business executives released by CA Technologies and conducted by Frost & Sullivan ...

October 04, 2018

How do you integrate tools to enable shift-left performance? The following tools will simplify maintenance, can be managed in a centralized way, and provide an easy-to-use UI to comprehend results ...

October 03, 2018

Focusing at the API layer of an application can help enable a scalable testing practice that can be efficiently executed as part of an accelerated delivery process, and is a practice that can be adopted and enabled at the earliest possible stages of development — truly shifting left functional testing. But what about performance testing? How do we enable the shift left of nonfunctional testing? Here, we explore what this means and how to enable it in your organization ...

October 01, 2018

As businesses look to capitalize on the benefits offered by the cloud, we've seen the rise of the DevOps practice which, in common with the cloud, offers businesses the advantages of greater agility, speed, quality and efficiency. However, achieving this agility requires end-to-end visibility based on continuous monitoring of the developed applications as part of the software development life cycle ...

September 27, 2018

Imagine that you are tasked with architecting a mission-critical cloud application. Or migrating an on-premise app to the cloud. You may ask yourself, "how do the cloud savvy companies like Airbnb, Adobe, SalesForce, etc. build and manage their modern applications?" ...

September 26, 2018

In a DevOps evolution, there are many paths to success, but even more that lead to failure, according to the 2018 State of DevOps Report from Puppet ...

Share this