In the previous part, I discussed the changes in the database world — from on-premise hardware to cloud infrastructure — and how it has affected multiple roles in IT, specifically that of the database administrator. While the prior post focused on infrastructure DBAs (iDBA), as promised, this post will now delve into the evolution of the application-focused DBAs (aDBA).
Applicative DBAs (aDBAs) are part of the application development within an organization, not IT. In fact, they have never been responsible for production aspects of database administration. That duty has been managed by the iDBA, who deals with availability, upgrades, security and daily tasks of the databases’ administration. The aDBA, on the other hand, is R&D focused. Regardless of the hiring party, whether it is a bank or an ISV, the aDBA is the foremost authority on data in the context of application development. A deep understanding of the tables, structure, relationships, SQL commands, as well as the code accessing them, are the aDBA’s livelihood.
Although this has undergone some changes with the onset of SaaS and hosted software, the need still remains, and has even grown. In the old days, aDBAs were, for the most part, only concerned with working closely with developers to ensure the databases suit their respective application requirements, and vice versa. In addition, applications underwent a confirmation process for smooth and efficient sailing with their respective databases. This process involved diverse activities ranging from designing to fine tuning the tables, queries, schemas, partitions and more, to ensure their compatibility and alignment with the application’s needs. In short, the main goal of the aDBA was, and still is, to make the database optimal for the application, and conversely make the application congruent with the database.
The Hybrid aDBA/iDBA
The aDBA role, generally speaking, hasn’t really changed much, since apps are still apps and developers still need the guidance of someone who really understands the ins and outs of the database. aDBAs remain the advisors of the app, and guide R&D through the right course of action when writing code and queries. The major change is actually in the consolidation of this role to include some iDBA aspects.
In contrast to the traditional world where development and production environments are not necessarily tightly related, the new web-scale application operates differently. Let’s take the scenario of a modern social web app that was developed by a small R&D team, supported by a single (possibly outsourced) aDBA member. Initially, the organization deals with a small and manageable demand. Suddenly, however, the service receives market traction and the small, closed development environment is faced with the need to support the production scalability necessary to cope with an imminent exponential growth. The new environment forces the aDBA to take complete responsibility for database layers and performance. The traditional separation line between the application stack and the infrastructure layer blurred, the aDBA is coerced into an aDBA/iDBA hybrid. Similar to how IT and R&D have undergone transformations attributable to the onset of DevOps-type roles, today you can find DBAs of both types (application and infrastructure) in the DevOps field.
The DBA has gone from solely focusing on dev-administration to taking on a consulting role, as well. In the modern IT world, the aDBA takes a significant part in strategically choosing the platforms, databases and tools needed to support application requirements, whereas in the past, the decision went from Oracle to SQL. Today, the innovative cloud organization has consolidated infrastructure with a growing abundance and variety of databases and languages, namely: SQL, NoSQL, Key Value Stores, Distributed Databases, and language choices, Node.js, Erlang, Ruby and more. There is a dire need for someone to fully understand the best tool for the job, and luckily, that someone is the modern aDBA.
The Data Champion
These days, due to many different R&D considerations, you can find applications written in multiple languages that are stored in an equivalent number of databases. Some databases need ACID, and some need to be able to be queried without complex sectors, among other considerations. Developers are taking charge and making a lot of decisions, especially with the onset of agile development and fast rollout deadlines. aDBAs need to be familiar with all of the corresponding features and rules in order to make quick decisions that promote how applications run in production. As a result, some organizations have even changed the role’s title and are now calling their DBA, the Data Champion.
An aDBA is expected to be an innovative team member as well as highly responsible for the management of production data. Application functionality is likely to change while the database continues to grow, leaving the aDBA with the responsibility to maintain data security and availability at all times. Decisions, such as which database engine and platform to use, are critical and have a direct impact on the future of online businesses in terms of scalability, performance and lock-in.
We, at Scalebase, understand these challenges and arm our customers’ with outstanding scalability and performance while maintaining the DBA’s control over data and flexibility to fine tune to fit the application’s exact needs.
Whether it be the role of the iDBA or aDBA, database administration and the comprehension of data storage itself is no simple undertaking. Cloud platforms such as Scalebase have simplified and essentially hidden many of these complexities from end-users, concealing their true significance in application deployment and management. By ensuring that the volumes and volumes of data that continue to grow by the minute are always accessible from an applicative and infrastructure perspective, it is plain to see that DBAs are truly holding down the fort.