There has been a massive evolution in the needs and requirements of managing and running a database in a modern enterprise over the last decade. Database administrators (DBAs) in charge of running enterprise databases are seeing a prevalent shift in focus: instead of ensuring access and availability, they are being asked to develop architecture, design, and scalability strategies that meet business needs and goals.
Much of this evolution began with internet-based companies and the newer revenue models they employed. These companies asked their site reliability engineers (SREs) or multi-faceted DBAs to ensure that the company's main revenue engine (applications and web pages) not only stayed up but could scale to wherever the business needed to go. This far exceeded the standard duties of past DBAs: just keep the database up, keep it backed up, and react to issues as they occur.
New revenue models, new application issues
As doing business on the internet became not only more common, but necessary to remain competitive, enterprises needed to find new deployment models that could keep up with shifting technologies and architectures. One of the biggest of these was the cloud and "as-a-service" paradigms, where software, databases, platforms, and even infrastructure could be "rented" via cloud-based models (software as a service [SaaS], database as a service [DBaaS], platform as a service [PaaS], and infrastructure as a service [IaaS], respectively).
The requirements and needs for managing cloud-based databases and DBaaS-based database environments have evolved along with this shift. For example, in the SaaS world, application outages mean lost revenue. Beyond the loss of immediate revenue (along with the expenses that go along with solving crises), downed services and applications mean a loss of customers. This means a loss of recurring revenue (both for the customers and providers of SaaS). To keep revenue flowing, every part of a company's critical SaaS database infrastructure needs to be planned out, including things like having a built-in redundancy and a future-proofed architecture, as well as how to scale for growth.
Growth means expanding services or entering new markets. This often comes with a need for new business-critical applications. In today's "as-a-service" world, there are several ways these can get developed and deployed. In-house, in the cloud, as a service? A combination? Are containers a good idea? Virtualized environments? All are options when you are trying to grow your business and meet customer requirements.
And success at meeting customer requirements is how businesses meet (or don't meet) business objectives. In today's world, customers expect applications and web pages to work quickly, seamlessly, and with little effort. We have all gotten accustomed to the immediacy of what we want, when we want it. This means that enterprises must be agile and able to deploy new services and applications quickly to meet the demand for new features or take advantage of new opportunities in unexplored markets.
Enterprise database needs are evolving
When deploying services, applications, or websites, you always need to plan for scale. The first thing that can impact data is a change in the database workload—whether due to a change in the data being stored and accessed or a change in the amount of traffic.
It's also important to understand how flexible your database environment is. Can it expand horizontally to deal with growth, or will it need more hardware? If you're in the cloud, what are the costs associated with increased usage? It's easy to buy more instances in the cloud to meet an immediate need, but those can be forgotten and left draining cash from your operating expenses, even after the need for them has passed.
Knowing what type of information you are collecting and why can provide some insight into how. This often means using different databases for different applications.
For example, consider an e-commerce site. There are many applications that work together to collect data for e-commerce: shopping cart contents, completed orders, inventory information, and restocking orders. You can store all this information in a single database—but that can require extra work and overhead to convert the data into a usable format for specific applications. Instead, you can store the information in a database best suited for that type of data. Forcing one database to handle a workload it wasn't designed to handle can degrade performance and cause other problems.
The more issues you can design out before launching products or services, the less chance there is of a future catastrophe. This means, for example, a financial-trading application developer requires DBAs and database engineers to architect a database that scales easily and avoids problems with latency. To do this, they need to work closely with the developers to write better, more efficient database calls and construct a database that reduces lag to near zero.
When a company moves its database to the cloud (for example, using DBaaS options such as Amazon Relational Database Service and Aurora, Google Cloud, or Microsoft Azure), the cloud provider often takes over much of the operational automation and mundane day-to-day tasks.
So, do you still need DBAs? Yes! The changing database landscape doesn't eliminate the need for database expertise: It moves the focus of that expertise closer to the design and development side of the application. Someone needs to not only design and tune the database to support the application, but that person must also understand how to build the modular pieces available in the cloud into a cohesive, scalable unit that meets the needs of the application and the company. This means there are much higher impacts and clearer ROIs realized from efficient database expertise.
What do DBAs need to know?
As the database landscape evolves, valuable DBAs will be less focused on fix-it solutions and more focused on strategy and planning solutions. DBAs will be asked how the database can contribute to the overall business goals of the company and what solutions there are to help meet those goals. They will need to help application developers create database calls that not only make sense now but will work at scale.
With new technology options such as cloud deployment and containerization, they will need to monitor and constantly reevaluate how applications are working with the database and how to improve performance (or incorporate new features or demands from customers without affecting performance).
Finally, as more and more companies use different databases for different applications and scenarios, DBAs will need to continually keep up-to-date on new database trends and technologies in order to remain an expert source of database knowledge.
Over the years at Percona, we have seen this shift as well. The types of issues we face daily have evolved along with the database environment (and the role of the DBA). Currently, more than 50% of the support tickets our customers open are related to application design issues, query performance, or database infrastructure design. Five years ago, help requests and support tickets around issues like these represented less than 20% of our overall caseload.
This makes sense when you think about the maturity of open source databases such as MySQL, MongoDB, MariaDB, and PostgreSQL and the technological advances that impact the database. More stable databases, coupled with advances in either homegrown automation or cloud-based infrastructure, reduce the likelihood of general crashing bugs due to the core database software. Often, today's causes of outages and issues are design decisions, bad code, or odd "edge cases" that weren't considered in the initial planning.
All of this means that the role of the DBA is moving away from simply "keeping it up and running" to a much more strategic position: The DBA is one of the experts that helps enterprises reach their strategic business goals.
Comments are closed.