Part 1 – This is not a pipe, it’s a pipeline: becoming a DevOps DBA

By Marcus Davage, Lead Product Developer, BMC Software

In 1929, Belgian surrealist artist René Magritte painted ‘The Treachery of Images’ aka ‘This is not a pipe’. He said, ‘Perception always intercedes between reality and ourselves.’

Pipes were ubiquitous then, as smartphones are today. Let’s consider a smartphone. It is far, far more than a phone. It is an all-in-one communications, entertainment and retail centre; this is not a phone. It satisfies modern demands for instant service, instant messaging, instant gratification. People want it all and they want it now. Instant upgrades, improvements, new features; no bugs and smooth transitions.

So what makes our customers any different?

Enter DevOps, a portmanteau word. Not a large leather suitcase that opens into two hinged compartments, but a word created when two different words are blended into one.

First observed in Belgium 80 years after Magritte’s ‘not a pipe’, DevOps aims to combine software development and IT operations, shortening development lifecycles by providing continuous delivery and continuous integration with high software quality. Complementing the Agile methodology – like siblings in the same family – DevOps aims to deliver software better, faster, safer, cheaper and happier than previous efforts.

It breaks down the barriers that defined the silo mentality that plagued software development for decades. DevOps is not only adequate automation, sufficient scheduling, and tolerable tooling. It’s about a culture of communication, of people, practice, and process. DevOps is not just a word, it’s a world that is created when the sounds and meanings of two different worlds are blended into one. But is everything in the DevOps garden quite as rosy as the idea suggests? Here’s where perception and reality can clash.

‘Update your app? Certainly. Download, install, replace. Update your operating system? No problem. Bring down your LPAR, upgrade, bring it up again, move on to the next one. You want a database change? Sure. Unload, drop, recreate, reload. Oh, sorry, you didn’t say that you didn’t want an outage…’

Now, every DBA knows you don’t replace an entire database, or even table for every schema change. Db2 has become far more capable of handling online schema changes with ALTERs and deferred share level change reorgs. There is always that little outage though, isn’t there? The dreaded switch phase. The tools that are now available to developers enable them to perform more and more software changes, more and more frequently. We call this the Release Velocity.

Database schema changes, however, do not traditionally take the same path. The database release velocity is generally slower. Far slower. It takes seconds, even minutes to deploy a new copy of code. It can take hours or days to unload, drop, recreate, and reload a multi-terabyte tablespace. The deployment gap or velocity gap is this difference.

Let’s consider for a moment the difference between traditional waterfall development and Agile.

With waterfall, no real value is delivered to end users until the very end of the project when the code is moved to production. With Agile, development teams can deliver improvements in smaller chunks more frequently, instead of waiting until the end of a project. Value is added incrementally over time, and beginning very early in the project lifecycle, instead of waiting until the end of what may be a monolithic project. And when development processes are properly automated, as encouraged with DevOps, the result can be less risky, even when teams are putting out releases more often.

You’ll have heard the term shift‐left when discussing DevOps these days. What is that? Well, the traditional software development lifecycle progresses through multiple stages, usually shown on a diagram from left to right. We start by gathering requirements, move on to designing the application, and then to writing code. After that, we test it thoroughly and only then deploy the application. DevOps brings a shift‐left mentality to the Software Delivery Life Cycle. Processes on the right are moved to the left, so they are performed earlier in development.

Developers have a well-defined automated process or pipeline to deploy code from system to system. However, when there is a schema change involved, the process must stop. It becomes a manual process of contacting the DBA (maybe through remedy or a ticket system) and then the DBA having to find time to determine what the developer is doing, what has changed, will it impact my system, does it follow our standards, do I have time to deploy it… The development process is on hold.
Yes, we still need the DBA, but their expertise and role need to be integrated into the DevOps process. The DBA designs, plans, models, changes, implements, supports, and maintains the database lifecycle from development, through various testing environments and into production. Your organisation may have separate development DBAs and production DBAs, but they still need to coordinate.

In DevOps, developers (including development DBAs) and operations (including production DBAs) need to work together to deliver changes at a pace that satisfies both operational availability and development targets.
Don’t just invite DBAs to your scrums only when you need them to implement an emergency change to a development environment because they haven’t got the authority to do it themselves and have thus stalled. They need to be involved from the very beginning of the project design, from Scrum Zero!

I suspect few blogs move from René Magritte to Scrum Zero via DevOps in 800 words, but there you go. In part 2 I will expand on my theme a little more, and explain how developers and DBAs can come together for the greater good.