The Database Future Is in the Cloud

I've written before about the disappearing DBA, and how the database administration role itself is evolving. I believe the days of tuning indexes are ending, one page at a time. Cloud database services such as AWS RDS and Azure SQL Database are accelerating this change, automating away routine tasks such as backups and even query tuning. I’m here today to remind you that despite all these advances, a universal truth remains: bad code will bring good servers, and services, to their knees. Migrating data and applications to the cloud doesn’t reduce your database performance monitoring needs. I don’t care what relational database you’re using, or if it’s in the cloud, your data center, or under your desk. Every relational engine works in a similar manner. Every query request will be in one of three states: running, runnable, and suspended. Therefore, it’s important to know the details of what’s happening inside the database engine, cloud database or not. Because while the database performance issue may not be your fault, it most certainly will be your problem. Cloud database services are shifting our tasks, forcing our role as a DBA to evolve. Let’s look at some examples of what’s changed in the past few years. Automatic tuning and auto-scaling. While some cloud services promise automatic tuning, those features are often focused on tuning individual queries instead of tuning a workload. Auto-scaling is then deployed to help manage workloads, but auto-scaling doesn’t help fix issues related to locking, blocking, and deadlocks. It’s up to you to help diagnose such problems by tracking concurrency, contention, and waits. You can’t RDP to the cloud database service. Gone are the days of using RDP to the database server to poke around and turn nerd knobs until the issue is fixed. Your troubleshooting skills need to shift, and your tools need to evolve to support these new skills. Database engines are evolving to run on multiple O/S platforms and integrate with other data services. Multiple data sources. There is so much data available, from many disparate sources. It takes a long time to become an expert in any one piece of technology, such as SQL Server. It takes longer to be an expert in SQL, Oracle, AWS RDS, the artist formerly known as Sybase, and DB2. Having many layers of data means many chances for a query to run long, which results in a surprising bill at the end of the month. Having the right tools to help with multiple engines is important. Too much noise. As a result of the exponential growth in data, and the ease in accessing data from any course, we’re flooded with noise mostly in the form of alerts. You need tools to get a signal through the noise. Features such as anomaly detection, built upon machine learning, help you be efficient with your time. Focus on design. I’m a huge advocate for cloud database services such as Azure SQL Database, AWS RDS, and even (gasp!) Oracle Cloud Database Services. I want to let the machines do the tasks they’re good at, such as backups, auto-scaling, and HA/DR stuff, so humans can focus on the things we’re better at, such as database design. Having tools to help isolate an index affecting hundreds of queries is one way you can have a large impact with minimal effort. Cloud databases require monitoring, same as Earthed databases, but the metrics are different, as are the options for making changes. Today’s hybrid data landscape will force users to focus on good design from the start. Your skills and tools should be focused and flexible to handle whatever comes your way next. Because change happens at a faster pace today than yesterday.