Домой United States USA — software Make the move to managed databases

Make the move to managed databases

216
0
ПОДЕЛИТЬСЯ

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? 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. 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.

Continue reading...