Make the move to managed databases

And free your DBAs to focus ‘on the valuable stuff’

Sponsored Have you hugged a database administrator lately? If not, find one and give them a cuddle. The chances are, they might need one. Your average DBA has a lot to offer, but there's something holding them back: the databases themselves. Admins and other database operators are spending too much time doing mundane tasks that aren't taking advantage of their full potential.

Or so suggests Amazon Web Services (AWS), which says that it has changed all that by reinventing the database as a managed service. Why should admins bother with all the grunt work, it reasons, when it could just handle all of that for them, abstracting these tasks in the same way that it abstracted everything else?

A database isn't just for Christmas

The problem with traditional databases is that they need an inordinate amount of nurturing. Not only does this set a mundane daily task list for DBAs; it changes the fundamental economics of owning a database, argues Barry Morris, general manager at Amazon Web Services.

"The cost of a database isn't just the upfront cost. The cost of the database lifecycle is very high. It isn't just the actual dollar cost, but the complexity and the lack of agility that's the problem," he explains. "It's the difficulty of keeping it available."

Databases may come with backup tools, but admins can run into problems when using them, including latency issues, resource management, error handling. Restoration can also take time, which increases as data volumes grow. With most databases supporting applications that can't be down for long, waiting for the database admin and the sysadmin to put the hamster back in the wheel isn't workable. There's also the question of testing to consider.

Businesses that insist on failing over to another system face more challenges. That hot failover system must have the capacity to cope with the transitioned workload when disaster hits.

DB admins might not be able to cope with the inflexibility of a self-hosted database either. The engine can only work with the computing power and storage that it has, and if your workload flexes considerably, you'll find yourself either struggling with a lack of capacity or hemorrhaging cash because you've paid too much for a kit that sits idle. Then there's the additional task of database software patching to keep things secure and avoid compliance drift. This isn't something companies should skimp on, lest they fall victim to security issues, but it's another bugbear for admins that rely on their production databases to be constantly available. What if a patch breaks your system or takes it down temporarily? The alternative, again, is to use a testing system. But then you still have to apply a patch to a running system at some point.

Using DBAs to their full advantage

Morris argues that this work isn't the profitable part of the database operation. Neither are mundane tasks like security and access management, encryption handling, or perhaps even operations monitoring. As the underlying engine room work that enables the database to do its job properly, it's critical, but does not contribute directly to the value of the core asset - the data that it is processing. In Amazon parlance, it's 'undifferentiated heavy lifting'.

DBAs shouldn't be spending their time on this stuff, Morris warns. These are things that should fall to a sysadmin - the shire horse of the IT infrastructure, rather than the purebred DBA. Unfortunately, it's difficult for many companies to distinguish between the two.

"DBAs understand the applications that are actually accessing that database and understand the semantics of their own business and the domain that their company is operating in," Morris says. "That's the interesting stuff. The valuable stuff."

What are those primo DBA tasks? Refining database performance is key, and tuning SQL - often by hand - is still a big part of many DBAs' value-added work. Supporting the development team is another key area where DBAs can add value, as is tuning the data for better analysis and refining data management processes.

Time to move to managed?

Morris presents the managed database as a way to free the DBA from the shackles of mundane tasks, enabling them to focus more closely on these and other higher-end tasks. Moving to a managed system goes beyond simple re-platforming - colloquially known as 'lift and shift'. Lifting and shifting an existing database into the cloud puts it on a virtual machine in a cloud provider’s infrastructure. It may eliminate the need to use your own hardware, but you still take all your database management problems with you. Whoever is responsible for the database still has to handle the same underlying tasks that burdened them in-house.

A managed database solution does what the cloud is good at: it abstracts. It uses database systems integrated tightly with the cloud to shield admins from the grunt work tasks, leaving them to focus on the more value-added work.

AWS runs a variety of managed database services spanning relational engines through non-relational databases. Its fully managed database services include relational databases for transactional applications (Amazon Aurora, RDS for MySQL, RDS for PostgreSQL, RDS for MariaDB, RDS for Oracle, and RDS for SQL Server), a document database that is compatible with MongoDB (Amazon DocumentDB), an in-memory data store for caching and real-time workloads that is compatible with Redis and Memcached (Amazon ElastiCache), and a wide column database that is compatible with Apache Cassandra (Amazon Keyspaces).

Whereas self-managed databases (on premises or in the cloud) carry a burdensome set of extra management tasks, these managed services take care of many things straight out of the box, Morris explains.

One of the most important is durability, he says, citing the company's MongoDB-compatible DocumentDB database. "If you store a single byte in that database, we actually store it in six places. In fact, we store it twice in three separate availability zones."

Other services that come baked in include security. The databases integrate with the AWS identity and access management system, which standardizes security and frees devs and DBAs from having to worry about authentication and authorization headaches.

Powering up productivity

This means that whoever touches the database - from developers to any kind of IT admin - needn't focus all their efforts on keeping the underlying architecture healthy and operational. This is especially important in the DevOps world, where developers aren't just responsible for their code anymore. These days, they're responsible for the platform that it runs on, which means it's their problem if the database falls over at 2 A.M. This is an unwelcome imposition for developers, who learned coding so they could build cool applications, not so they could test database backups (or lie awake worrying at night because they didn't).

Eliminating the mundane parts of handling a database is likely to make developers and DBAs alike more productive. An IDC study on RDS productivity showed that DBAs could handle 60 percent more databases on average using a managed database than those doing their own low-level administrative lifting. DBS teams were 37 percent more efficient overall, while development teams saw a 45 percent increase in productivity. Moving to a managed system also dropped unplanned downtime by 97 percent, because try as they might, a DBA nurturing their own system will be limited in what they can do, reliability-wise. Moving to fully managed databases is made easy with migration tools, programs, and experts for a seamless migration experience.

What the future holds for DBAs

This is all very edifying, but what will DBAs do when their databases move to managed? Even some of the performance optimization tasks that they might consider value-added work today are made easier in a managed environment. For example, you can get SSD-backed instances via RDS optimized for different workload types.

There are still plenty of things for DBAs to do in the cloud, but they're likely to become even more specialized and value-oriented. For example, they need to prepare their organizations to cope with ever-growing data volumes while still delivering results at low latencies. This means designing highly-tuned schemas. Other emerging tasks include supporting more robust data governance protocols as companies wake up to the importance of issues like data provenance.

Functions like these will also come from the cloud, either natively via the service provider themselves, or via software partners integrating via the cloud company's marketplace. Layering these and other cloud-based services atop a managed database sharpens the need for cloud expertise.

Like so many other IT roles these days, DBAs will have to build increasing amounts of cloud knowledge into their skills portfolio. But it might just make their jobs more exciting and allow them to venture into new areas that they didn't have time to explore before.

Sponsored by AWS

Biting the hand that feeds IT © 1998–2021