Death of the DBA, Long Live the DBA
I planned on finishing up and publishing a different post today, but after a number of conversations with DBAs in the community, this topic took precedence.
Yesterday the above announcement came out with the Oracle earnings call, along with the following:
“In a couple of weeks, we will announce the world’s first fully autonomous database cloud service,” said Oracle Chairman and CTO, Larry Ellison. “Based on machine learning, the latest version of Oracle is a totally automated “self-driving” system that does not require human beings to manage or tune the database. Using AI to eliminate most sources of human error enables Oracle to offer database SLA’s that guarantee 99.995% reliability while charging much less than AWS.”
With DBAs that have been around a while, we know the idea that you don’t need a DBA has been around since Oracle 7, the “self-healing database”. I received numerous emails and messages and even a phone call from folks in the community, concerned about the announcement, along with the rebranding of Oracle Technology Network to Oracle Development Community.
The Role is Changing
I’ve been presenting on the topic of the changing role of the DBA for almost a year now. It’s not an unknown, folks. We all realize that the influencer has broadened and for cloud initiatives, what better way to introduce it into the business than to give it to developers and let them build out environments that require very little input or guidance from operations?
The demand on the development cycle has increased exponentially. None of us can deny that and as much as we know that data friction is the cause of this, many times we DBAs felt fulfilled by that friction. The best DBAs all have a few control issues and the ability to control the environment was essential to ensuring stability and consistency of design, platform, etc. occurred. We may not like to hear it, but it’s just how it is. It was part of my job to slow things down when I noted issues that could impact uptime, performance or accessibility.
With the introduction of cloud, particularly SaaS, the need for operations, (DBA, administrative and network support) is little to not required. IaaS is still a powerful opportunity for the business to have more control over the environment and expertise, but it’s going to look awfully attractive to companies to pay more monthly for a SaaS offering when the business is sold on the idea, “You won’t need all those DBAs, server and network administrators any longer.” The extra cost, when billed monthly is easier to “swallow” than annual licensing fees and salaries.
DBAs are now recommended to look to cloud providers to utilize their skills or move to a development role. I’ve been proposing a third option of DevOps, as I’ve stated time and time again. The DBA role is changing and we just need to admit that we’re not needed for much of what we once were.
Or are we?
Oracle is not the only one to claim that you won’t need a DBA, nor have they done it as successfully as Microsoft SQL Server. At the release of SQL Server 7.0, there was a push of marketing that stated a DBA was no longer necessary. Windows Admins and developers were installing SQL Server and taking over management of the database tier. It resulted in a temporary lull in available positions for SQL Server DBAs and as I worked for a company whose largest environment resided on SQL Server, I remember interviewing candidates who couldn’t tell me what an “LSN” was, how lock escalation worked or even how data was written to the SQL Server transaction log. We quickly exhausted candidates searching for a qualified DBA. Luckily, Microsoft learned the error of their ways and within two years, all those databases installed by non-DBAs came to a breaking point and DBAs were re-introduced in mass quantity. The SQL Server DBA community is thriving and has some incredibly skilled administrators that understand the database engine, design and code.
I foresee this as a potential scenario for the Oracle database community now and this is why.
Clouding Your Way Out of a Software Problem
Any DBA who specializes in optimization knows that hardware offers around 15% overall opportunity for improvement. My favorite quote from Cary Millsap, “You can’t hardware your way out of a software problem” is quite fitting, too. A hardware upgrade can offer a quick increase in performance, only to find that the problem seemingly returns after a period of time. As we’ve discussed in previous posts. The natural life of a database is growth- growth in data, growth in processing, growth in users. This growth requires more resources and if the environment is not performing as optimally and efficiently as possible, more resources will always be required.
When we attack an optimization project at the code, design and application level, we have over an 80% opportunity for improvement. The improvements are long term and can serve future projects, as well.
Having this information in our pockets, let’s now add the reality of the cloud. Depending on the provider, we purchase compute and storage “packages” to serve the best needs of the environment. It may not be the most optimal configuration, but if we need more, it’s easy enough to scale up. All of this comes with a cost. Anyone who thinks they’re going to save money going to the cloud really shouldn’t make this the reason for going to the cloud. One of the largest surprises for companies who migrated to the cloud early on, although the monthly costs looked promising, the overall annual cost realized no savings and often increased expenditures. Your benefit of the cloud is easy access, easy scaling when needed, for most primary systems, it won’t result in savings., The real question is, “should you scale and cost the business money just because it’s there?”
As I stated earlier, you can’t hardware your way out of a software problem, but can you cloud your way out of a software problem? Cloud vendors will be all too happy to scale you to the next higher cloud package offering. They will be very happy to do it transparently for you, but this will be a required, regular process if you don’t have someone optimizing your environment.
Are you really expecting your developers to be skilled in identifying performance issues and optimization of code and design?
Long Live the DBA
Developers are expected to do more in a shorter cycle and with less every day. Agile is here and with the introduction of DevOps, there is structure around agile development to demand even more from them. The skills and the depth of their development knowledge is already vast and they’re that will result in them being stretched to fulfill the demands from standard development tasks.
This will result in a high demand for DBAs knowledge of database engine, the optimizer and how to optimize environments. Those DBAs with advanced skills in these areas will have plenty of work to keep them busy and if Larry is successful with the bid to rid companies of their DBAs for a period of time, they’ll be very busy cleaning up the mess afterwards.
Originally published at DBA Kevlar.