Somebody Else’s Problem: How We End Up Making Mistakes in DevOps Toolchain Selection

Originally published on DZone by Robert Reeves, CTO, Datical.

Quick! Describe your application’s system architecture. You have 30 seconds….go!

Welcome back. I guarantee that the majority of you did not mention the database more than in passing. Instead, you probably described containers or your clever use of RESTful APIs to leverage legacy systems. Very infrequently do we think of the database as a Tier 1 citizen in application system architecture. Too often, the database is Somebody Else’s Problem in the DevOps reality and we ignore it.

Let’s take a step back and remember why we adopted DevOps in the first place. I’m not talking about business reasons like not being “Ubered.” Instead, let’s recall what happened that made us want something that unites our development and operations teams and enables us to release software faster and better. It was Agile software development.

Agile eliminated the wall between the business and development teams. That reduction in friction led to an enormous increase in applications and their corresponding number of releases. A tsunami of releases crashed down on us. Had we not seen this increase in demand for releases, I highly doubt we would have felt the need for DevOps.

Recent surveys of Datical customers’ software releases found that more than four out of five application releases require some sort of database change. That might mean updating a stored procedure or adding a new column to an existing table. The number of application releases has increased, and the number of required database schema changes has increased right along with it.

As a result, just as system administrators and release managers have been screaming for help and tooling to support their efforts, DBAs need help too.

The honest truth is that we neglect to involve our DBAs early enough in the application development process. Correspondingly, we neglect DBAs in our DevOps toolchain evaluation process. We treat their responsibilities and plight as Somebody Else’s Problem. When we need a database change, we simply create a ticket. We might even write a SQL script. Somebody on the other end will handle it for us; we don’t have to worry about it. Well…that’s only true until we DO have to worry about it.

We have to worry because database changes have become a huge bottleneck for application release automation. Companies like Automic, CA Technologies, ElectricCloud, IBM and Xebia Labs have automated many application release tasks, but those advancements have not benefitted the DBAs. In fact, by accelerating application releases, they have made DBAs more likely to fail to deliver under increasing demands. This problem will continue to worsen under the Somebody Else’s Problem mentality.

Setting the stage in that way, it becomes clear why it is absolutely necessary to have all stakeholders involved in selecting the DevOps toolchain. Avoid the Law of Unintended Consequences by first defining the pieces needed for a successful full-stack deployment. Then, engage each one of those stakeholders to understand their needs and requirements. Find consensus and improve. It’s really just that simple.

When you ask the DBAs, you’ll find them envious of the innovation provided to the development team. DBAs are crucial stakeholders in your success, so let’s treat them as such and provide them the opportunity to advise, decide on and use the tools that every one of them wants.

To learn more about the importance of selecting the right DevOps tools, check out our white paper: “4 DevOps Tools You Can’t Live Without”