Meet the New DBA, Different From the Old
Meet the New DBA, Different From the Old
Are DBAs a dying profession? No. But tolerance for the old-world DBA’s penchant for encouraging teams to depend on them for basic workflows is rapidly disappearing.
Join the DZone community and get the full member experience.Join For Free
Built by the engineers behind Netezza and the technology behind Amazon Redshift, AnzoGraph™ is a native, Massively Parallel Processing (MPP) distributed Graph OLAP (GOLAP) database that executes queries more than 100x faster than other vendors.
There’s a rapid shift taking place in today's technology organizations. The role of the DBA is being redefined and increasingly replaced by other roles and specialties. This is happening even as data explodes — in fact, it's happening precisely because data is exploding. It's a trend that is accelerating, and it sometimes takes people by surprise.
In general, the DBA role is shifting from the lower layers of the technology stack up into the higher layers, where its concerns overlap more and more with technical operations and even development. Let’s consider why this is happening and what it means for the future of data management and data operations.
In the olden days — a few years ago — DBAs were responsible for topics such as database security, installation, tuning, storage, upgrades, replication, and backups. These "low-level" concerns typically had to be performed for a limited number of servers, because the model that companies typically used had a single monolithic database, which would run on the biggest and most powerful server the company could afford. It made sense to hire a person and dedicate them to the care and feeding of the company’s only critical database assets.
As the only domain experts of the gnarly internals of complex database software, DBAs eventually occupied a unique position — they could help application developers build apps that would use the database wisely. They contributed experience and judgment in data modeling, schema design, indexing, query design, and query optimization. While these responsibilities and insights sounded good in theory, there was a downside: DBAs became a critical bottleneck for the development team, who couldn’t get much done without involving them.
Today, it’s commonplace for a business to have hundreds or thousands of database servers. Manual babysitting is wasteful and begs for automation. Automation is best achieved by building software that can manage the database servers, and the best example of this is Amazon RDS, which runs the database for you and doesn’t let you administer it. You can only enable it, and then it’s locked down to the point that you can’t really interfere with its operation. Upgrades, storage, and the like are all automated. In this scenario, DBAs are no longer doing the low-level stuff; their old domain is just a feature of the platform.
But what about DBAs' other roles? Are DBAs still needed to help with data modeling and index design and so on? Increasingly, I’m seeing companies say no. Many of VividCortex’s customers are good examples; some of them have several hundred developers and not a single DBA. These developers are expected to be more full-stack, to know and care more about the database and how to use it wisely. No one would expect every developer to know all the intricate internals of the database, though, so there are still specialists with extra database superpowers sprinkled around the teams. They identify as developers who are more capable, though.
So, the DBA role is being redefined and reshaped by trends such as cloud, PaaS, DBaaS, and other adaptations of modern engineering. These changes preserve agility and velocity in the face of scale and complexity: DevOps, SRE, microservices, and so on.
The shift is rapid, and it's accelerating. Amazon AWS, already a large and fast-growing business, reports that RDS and other hosted databases are by far their fastest-growing service lines.
What if you’re not using the cloud? Companies are still building data platforms — they’re just doing it internally. There are platform teams at most companies of credible scale today, providing data as a service to internal “customers” who consume them, often aligned with microservices-focused teams or the like. Their job title is often something like Storage Engineer, Data Engineer, Platform Engineer, or Data Tier Ops. It’s rarely DBA. The “A” in DBA is associated with coddling a unique snowflake database, and no one today has time or tolerance for such special machines at scale.
Are DBAs, then, a dying profession? I would say not. DBAs are a changing profession, adapting to the changes I’ve described. What is rapidly disappearing is tolerance for the old-world DBA’s penchant for encouraging or permitting teams to depend on them for basic workflows, such as releasing or testing new application versions. I’ve seen multiple people fail to redefine their value to the company and become sidelined as the managers realize they are actually hindering, not helping.
The benefits of a more modern worldview and definition of the DBA role are quite compelling — dramatically increased product velocity, developer productivity, and ultimately, the business’s top line. It comes down to the question of whether data is a sustainable competitive advantage or a thorn in the company’s side.
What are your thoughts on the changing role of the DBA in modern data-intensive applications and teams? Post in the comments section below, and check out our free e-book, The Hidden Costs of Data Engineering, in which we analyze how real engineering teams across the country have responded to huge increases in data activity.
Published at DZone with permission of Baron Schwartz , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.