DBA Paradox – Plus ca change, plus c’est la meme chose

The quote comes from Jean-Baptiste Karr.  And while some may not be familiar with the source and that original language version, almost everyone is familiar with the paradoxical adage in English,

 “The more things change, the more they stay the same.”

While you hear people use that idiom often, many don’t understand it or use it incorrectly.   Quora is filled with various forms of confused questions seeking answers to

• What does it mean?
• Is it not contradictory?

But the more experience you have, the more obvious the answer.  While the world appears to change constantly, aspects remain constant to the observant.

What does that particular paradoxical idiom have to do with DBAs?

Before I answer this question and explain why this particular phrase inspired this blog entry, we should cover some background.  I have written a few prior blogs on the DBA career and how people tend to end up in that career.  But a running theme underneath is always the perpetual predictions of the career’s impending doom.

• DBAs and Dinosaurs
• Why so many DBA conscripts?
• Tinker, Tailor, Developer, DBA

My supported opinion throughout is that these repeated DBA career obituaries  we keep encountering amounts to semantically jousting about evolving roles and responsibilities, as though most careers are not undergoing similar evolving challenges.

Database Administrator versus DBA

The way people think of the DBA has evolved beyond the TLA ( three letter acronym ) that it represents.

DBAs don’t think of themselves as “administrators”.   They are problem solvers.  If no problems existed in the charter of insuring the speed and accuracy of that most precious of all resources, the data, then they would have nothing to do. 

They solve problems that have already occurred; they prepare for problems that will inevitably occur; and they try to do as much of this as possible without being noticed. 

Maybe in the beginning, when “data” and “base” were still two words, the title DBA actually did involve more administrative activity.  But the name has been sticky through the years despite attempts to put it to rest.

Data Professional versus DBA

A couple of years ago, there was some talk among leaders of the database community with ominous rumblings of the “death of the DBA”, but not ironically.   But the future was projected in a new role or title, the Data Professional. 

Drilling into the expected duties of this category of careers revealed much of the same needed skills that had previously been assigned to DBA roles.  So this concerted effort seemed more about rebadging than distinctly different duties.

People can choose to call their careers and roles what they prefer.  But most of the people I speak with still identify with the ingrained term of DBA.   So my take is that “Data Professional”, much like “Fetch”, is not going to happen.

Another Paradox

When I first began to learn of various database systems, those with experience in multiple types of database systems made what seemed to me to be two conflicting statements.

• All databases are the same.
• Each database is different.

Oracle, SQL Server, DB2, etc. all had the same basic goal of storing and delivering data in a quick, reliable, and efficient manner.    All have locks, tables, some form of logical versus physical storage, resource contention handling, and memory management.  But they all had different terminology and different design implementations to achieve those goals.  And a certain expertise in those detailed differences was necessary to diagnose problems or tune for optimum performance.

So how valuable is experience in one type of database system when trying to learn another when the differences in the details can be quite complex and sometimes confusing? 

A self-identified “Accidental DBA” was telling me of his experience being lifted from his role as a SQL Server developer when the business realized it needed a designated DBA.  (As typical, this happened after the first crisis.)   But while he was a newly minted SQL Server DBA, he did not seem to be struggling in the role or having difficulty knowing what he needed to do as such DBA conscripts often report.  Then I learned that prior to becoming a SQL Server developer, he had been an Oracle DBA for a few years.

Even though the details and mechanics of managing Oracle and SQL Server are quite different, this person had the advantage of the disciplines of backups, diagnosing hotspots, monitoring performance, and insuring data integrity.  The developed instincts of how to be a DBA translated even as he learned the specifics of maintaining SQL Server.

Inspired by an Old Book

I have been kicking these ideas around since the prophets of DBA doom have been prognosticating that the age of the cloud would finally relegate the DBA role to obsolescence. My grumbling rebuttals were largely kept to myself, and whoever might make the mistake of asking “What are you thinking?”

Then I read a weird book review on Brent Ozar’s blog.  The review was about as Ozarian as it gets, a book review of Inside SQL Server 6.5.   “What an odd way to spend a weekend?” was my first thought but I kept reading and got more and more interested.  The blog in question really dove into the technical details of pre-millennial technology.

The expected musings on how far we have come in a couple of decades turned into comparisons with cloud-based and cutting edge technology that we are beginning to adopt as the cloud hype cycle moves into the phase of widespread adoption. Brent did a great job of pointing out, at a base-level, how the concerns and motions of the 90s DBA were not really different than a DBA trying to implement a high performing cloud-based database today.  As Brent said, “Same math, different names.”

Of course, the details of how you go about doing those things is different, just like how you go about doing things for Oracle is different than doing it for SQL Server or MySQL.  But knowing what you need to do and how to make the correct trade-off decisions is just as relevant in each case.

For more musings on older database history, read along.

Cloud Sticker Shock

One of the most annoying misconceptions coming from the cloud evangelists was the cost savings.   It was not annoying in the sense that the theoretical cost savings were not real.  It was annoying in the inference that cost-savings would be automatic.  And one of the implied cost savings for some was that the DBA would somehow not be required in the automatically managed cloud databases.

So I was a little gleeful to read this account of the cloud sticker shock that many CFOs and CIOs have been experiencing.  A survey of IT executives revealed that unpredictable ongoing costs and lack of visibility into cloud resource usage are top issues for them.  While the cloud savings in capital expenditure is undeniable, long term savings may be elusive as you still incur the cost of what you use.  And unless someone is tracking and planning that usage, the savings will never materialize long term. 

It turns out that costs of using someone else’s system still needs oversight and planning, not to mention taking care of the most important asset to most companies, the data itself that you cannot afford to lose even temporarily.

Somebody somewhere needs to be making sure all those DBA tasks are covered.  For every old thing that is automated there seems to be a new complexity to manage that is just as important.  There can be more productivity and efficiency, but no magic cloud genie exists.

Coming Full Circle –Paradox Explained

So if it isn’t obvious how all this rambling relates to the opening idiom: Things are undeniably changing and seemingly faster in the technical world than anywhere else.  But that doesn’t mean the experience, instincts, disciplines, and judgment of the DBA (or Data Professional if you must) are not needed or applicable.

Just as past DBAs have made the transition from Oracle to SQL Server, or mainframe to client-server systems, DBAs who keep current on the technology are still needed as the protectors and curators of the data. 

“Reality is made up of circles but we see straight lines.”
― Peter M. Senge, The Fifth Discipline: The Art & Practice of The Learning Organization

So make sure to keep current on the newest technologies and platforms, but also be content that the skill of a Few Good DBAs will still apply in the new millennium cloud world.