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?
History
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 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.
Pingback: Colorado Tech Weekly #223: Never Stop Learning - Scott Pantall
Pingback: Long Live The DBA – Curated SQL
Great article, thanks for sharing.
The future for the DBA is not in operational tasks such as backups, restores, or even query tuning. Every database platform is moving towards offering these services out of the box. This reduces the need for the current number of operational DBAs, but that does not mean those people won’t have a job.
The operational DBAs that can pivot to roles such as developer or data analyst will always be able to find work.
This always had been the think tank of Development to get DBA onto their stack, but DBA think process is quiet different from Developer. Developers are essentially technical analyst who work with business analyst in developing applicaton, they do not have indepth technology standpoint to take role of DBA. DBA’s are uniquely positioned to think from Business Application User Interface to Data and Storage/Hardware and face customer wrath for anything that goes wrong
Pingback: Le métier ne mourra pas, mais il faudra s’adapter. |
I think this is a very timely discussion – should be more of it.
I’ve been bothered by this question for the past 2 years. I used to think with my Oracle and SQL Server DBA skills I would not need to change “major” again till my retirement. How wrong was I. During the past 4 years first I ran into Greenplum and Netezza, then the wave of big data, noSQL, AWS and RDS databases, all of which I embraced and tried to update my knowledge, still seems to me big data and noSQL are now ruled by java developers, and serving as an application DBA in a poorly executed agile environment, the developers took the reign and I could no longer be the gate keeper of the data. The price will be high, the application they came up will work, but won’t scale, to go back and fix it is like having to pull out a block from the bottom of the Jinga stack. Still all management wants to hear is “automate”, “agile”..the buzz words. While I certainly see where they are coming from, I wish they realize the cost of it.
Is it now wise to choose a career as DBA after doing Bachelor Commerce, or should I become Linux administrator?
If you truly believe that hardware administration is a better option than database administration after all I said here and all the information on the cloud, then we’ve failed to get the message across.
I think it is wise to consider a career as a data professional, yes. And “DBA” means something different to everyone. I would not think there is much of a career path for Linux/Unix/Windows admins in 5-8 years, except as a matter of course for a Cloud admin. Much of the tasks that a LUW admin would do today will be automated away (backups, patching, etc.), allowing the human to focus on human tasks (architecture, analytics, security and risk management).
HTH
@@ThomasLaRock:disqus thanks for the response , one of my question is i am from commerce stream , will it be wise for me to go for DBA/LUV ADMIN ? Thank you again
Ah yes, no DBA’s except for the DBA’s that are writing the DBA automations!?!