My view: Say hello to Database DevOps Engineer
The Database Administrator is going away for sure. The old-school person with magical SQL abilities and knowing all the caveats there are to know about RDBMSs is doomed in the era of "multipurpose" developers. The "DBA as in Database Advocate" idea carries an important weight, but I feel we should augment the notion a bit.
With the constant growth of so-called "microservices" we - the DBAs of the new age - are faced with many new challenges. The never-ending push toward "agility" makes us re-organise our work totally. We - who were once an island - now find ourselves struggling for inclusion in the broader operations environment, where "control" is an ancient ideal and "human SPOFs" are something to be avoided at any cost. We're not gurus anymore.
The new DBA isn't a "one-trick pony" anymore. If we want to keep up with how things are done now, we should take on the new "DevOps" belief as our own.
But why the change?
Nowadays, developers are perceived as "multipurpose", software-creating assets. With the rise of tools bringing coding and administering closer together, developers are now able to create infrastructure as code, deploy entire platforms with a single click, bring new database to life with a push of a button. As Dj accurately notes, coders these days won't wait for operations people to provide them with the access they need - they will instead spin up a new instance in the cloud.
Another thing is that the way we architect software now is much different, than in the good ol' days. The idea that POSIX and the GNU project came up with over 20 years ago is now seen as the best way in our industry - create simple, autonomous pieces of software that perform one task really well. And connect them together using a common language - an API. If any function has to change - you have to replace just the component performing it. And it seems to work really well on the application level. But what is often forgotten is the low-level data stack. What can be seen more and more often, are sets of microservices operating autonomously on application and API level, but connecting to one and the same database under the scenes. Obviously, allowing this kind of an approach is questionable at best; multiple access patterns can disturb the caching layer and confuse the query planner, overlapping views might cause problems with sequential scans and there is the question of constant schema changes required by many applications for the same set of tables. This was a problem long before microservices came around, granted, but nowadays we're seeing a new application popping up almost every week, so the scale is much bigger now, than it was before. That's a big challenge for the DBAs - not only to educate and advocate for best practices' compliance, but also to keep up with the demand. We need to not only guard existing databases, but also be able to provision new ones in a blink of an eye.
Nowadays DBA isn't "only" a database administrator; we should have a broad skill-set allowing us to maintain the environment in which our precious RDBMSs run to the full extent. We need not only to create databases, but also systems on which they run. We need automation for databases as any other system does. We need to be able to shift our focus from manual labour to orchestration and to do that we have to create our own tools since we are the ones who know, how they should look like and what they should do.
We were always a bit different than other operations people, but now, in this new time, we need to keep up. And to do that, we need to be included in the general operations environment. But we're dragging this baggage behind us and probably because of that we're still being perceived as highly specialised individuals that... well... don't have much to offer apart from their database expertise. But that's not entirely true, since nowadays many people in the DBA field come from a system administration or software development background. It's unfair and unreasonable to deny them the inclusion they need to fully ascend to the "agile" operations world. We're struggling for that inclusion, but obviously the first step should be ours; only after that we can start to be seen as Database DevOps Engineers.
It can be hard to balance, but we shouldn't strive anymore to be some sort of gurus and yet we should still be available and willing the help and assist and yes - advocate as well. Irreplaceable people are always the first to be replaced, so our goal should be to make ourselves as useful as possible while still maintaining our special attention to detail and high level of responsibility.
One other important thing is service continuity. It's really easy to become a "human SPOF" when working in the traditional model. When "silosiation" is highly developed and we have "database guys", "infrastructure guys", "monitoring guys" and so on, the ability to take over from a sick or otherwise gone team member is very limited. And it's especially problematic when it's about databases - these are highly sophisticated pieces of software and knowing them from inside-out takes considerable amount of time. This is just another point for including DBAs more into the broader operations world. We need to become more like the modern sysadmins with their automation and orchestration frameworks, but there's a lot we have to offer them as well. Working with databases requires a special kind of discipline; attention to detail is really high amongst the requirement for a "good" DBA. Standardisation and normalisation are something obvious to us - in the database schemas as well as in the day-to-day operations. Standards. Discipline. Thinking before doing. Standard Operating Procedures. This is what we can bring to the DevOps table.
What is a Database DevOps Engineer?
Database DevOps Engineer enters and brings with him a plethora of skills ranging from low-level database maintenance, writing and optimising queries, knowing the planner inside-out; but also low-level operating system configuration, picking the right storage and optimising its parameters, taking care of the basic hardware monitoring, creating Munin/Grafana dashboards, writing Nagios/Icinga/Sensu plugins. And of course automating all that stuff using Puppet/Chef/Ansible/Salt, simplifying common tasks with scripts, handling partitioning, LVMs, virtualisation and so on.
A Database DevOps Engineer is, in many aspects, just like any other DevOps guy in the company, just with a "hint" of specialised knowledge on the database side of things. He not only manages databases and protects the data, but also facilitates the evolution of the data layer - by advising the best ways to share the data amongst applications (be it by replication, ETL processes, foreign data wrappers and so on) and by implementing the solutions chosen by other teams in timely and repeatable manner so that when a need arises for another setup like the one chosen, there's already an module/role/playbook/recipe that other, non-DBA team members can use.
Database DevOps Engineer knows about "the cloud", is able to use APIs or containers. He may not like it, but he's ready and willing to listen if there are good arguments for using solutions like this.
Database DevOps Engineer is not afraid of letting go, if the team decided it can take care of their databases on their own. Database DevOps Engineer is there to assist even, if he's not the formal system owner.
Database DevOps Engineer combines his DevOps skills with the database knowledge gathered over many years of experience and uses that to create tools for other teams to use ranging from automation playbooks, single-click deployments to parametrised monitoring dashboards to automated slow query reporting.
Who is a Database DevOps Engineer?
The good news is that we're not magical unicorns anymore. Nowadays, there's plenty of people in our field that are more or less familiar with databases. It takes time to know some specifics, but even the most knowledgeable of us learn something new everyday. The DBA of the present and the future is someone with a broad experience not limited to just databases. So in fact, provided a certain level of discipline and attention to detail (and willingness to learn, of course), any DevOps Engineer can, in time, add the "Database" prefix to his or her role name.
The natural candidates though for becoming Database DevOps Engineers are those of us - DBAs - who already deal with (or want to, but are denied the chance to) much larger spectrum of technologies, than just the databases alone. We certainly have the mental capabilities to become so much more than we are viewed as, but we should be the first ones to realise that. Becoming more familiar with operating systems, storage arrays, networks, scripting can go a long way towards making our workflow more smooth and our positions more agile-oriented and DevOps-aligned.
If you like this article please consider sharing it with your friends.