DEVOPSdigest

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(link is external) 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(link is external)?"

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."