Jason Massie (aka StatisticsIO.com) wrote a blog post this week called The Death of the DBA.  He talks about why the coming cloud computing craze creates career chaos.

I have the exact opposite opinion: I can’t wait for databases to move toward the cloud because it makes database administrators even more vital.

Reason #1: Cloud computing costs real money, and DBAs can help cut costs.

When you move your database into the cloud, your cloud vendor starts billing you on a per-month basis for CPU time, memory, and storage space.  Normally, when DBAs say they cut costs for a company, they’re talking about funny money: if we optimize indexes and cut storage space by 10%, we don’t suddenly get cash back.  When software is a service, though, we will see real savings, a real reduction in our next monthly cloud bill.

Cloud vendors won’t get involved in tuning indexes, cutting storage space, optimizing memory and cleaning up CPU cycles because they make money off bad application design and bad production decisions.  Want to make a bunch of duplicate indexes on your Amazon EC2-hosted MySQL server?  Knock yourself out – Amazon’s happy to let you do it, and they make more money off every bad decision.  Go long enough without a DBA, and the applications will start racking up big monthly bills.

Reason #2: Disaster recovery becomes even more important.

How many of us have been shafted when some kind of third party provider suddenly closed up shop in the middle of the night and disappeared?  Think back to the online storage craze in the initial dot-com boom: everybody and their brother was offering online storage space for free or for cheap.  Some of the providers are still around, but most of them folded up and died, taking user data along with them.

Disaster recovery no longer just means preparing for your own business failures: with cloud computing, it means preparing for the failures of your cloud vendor too.  No cloud vendor is too big to experience problems: check out the Amazon S3 outage in July 2008 and the Amazon S3 outage in February 2008.

Reason #3: Web hosting hasn’t killed the need for sysadmins.

Web sites have been hosted at third party hosting providers for more than a decade, but try calling your hosting company and getting good help with a problem.

I just recently chatted with a sysadmin who sat through a grueling contract renegotiation with their hosting provider.  They’re spending tens of thousands of dollars per month on hosting, and the hosting provider touted all kinds of advantages like redundant internet connections across multiple datacenters.  Come to find out – they only had a single datacenter, and were thinking about growing to another one.  The hosting provider also mentioned that they had the right to move machines between datacenters at any time without warning as part of planned maintenance windows.

Without a skilled sysadmin, these unfortunate problems wouldn’t have come to light, and the poor client would have only found out when their machines went down and came back up with new IP addresses.  This is a huge security risk for the client, who has to pay external security auditing firms to verify that their private data is in good hands.  They would have to redo their security audits and fork out big bucks.

Does third party hosting solve solutions and offer value?  Absolutely.  But does it eliminate the need for administration, security auditing, day to day maintenance, planning, and app design?  No way.

Reason #4: The economy of scale means it can be cheaper to manage your own servers.

Say three companies came out right now offering SQL Server hosting services:

• Company A offers no-frills hosting for $X per month
• Company B offers hosting with backups & restores for $X * 1.5 per month
• Company C offers managed hosting with backups, restores and performance tuning for $X * 3 per month

Your company has to evaluate each hosting option, and the larger you get, the more sense Company A makes.  At a certain number of databases, you’ll save money by doing the management yourself.

Company C can’t offer management features without paying for DBAs.  The DBAs have to work somewhere, and you can bet that Company C will heavily mark up their DBA costs because everybody has to make money somehow.

Reason #5: Security & SOX compliance.

I did a short stint at a major financial firm who wouldn’t even allow their employees to get their email over the web.  Imagine putting their financial data on databases in “the cloud” – no way.  Private companies might be able to get away with it, but after a couple of security scares (think lost tape backups) the paranoia will set in.

I can already visualize the ads for consulting companies.  “Think your data is safe in the cloud?  How do you know Mr. Hacker Guy isn’t connecting a USB drive to your server right now?  Pay us and we’ll find out.”

Reason #6: Do you stand next to your servers now?

The good DBAs I know don’t work in the datacenter (except when it’s time for OS reinstalls, and these days a lot of that is handled with imaging and deployment tools).  They work from a cubicle, office, or coffeeshop miles away from their servers.  We don’t have to put our hands on the servers, and they could be anywhere.  I’d love for my databases to move to the cloud, because it makes it easier to justify telecommuting.  Preferably from a beach.  With margaritas.  (Might be able to expense those during meetings, too.)

Bottom Line: The cloud is coming, but it’s not going to rain on the DBA party.

Now is a great time to be a DBA, and while I think there are disruptive computing forces on the horizon, I don’t think the cloud is going to put an end to the DBA career.

So what about the future is going to change the DBA career in say, five or ten years?  Well, as RAM and solid state disks get cheaper, I can foresee the day where databases run entirely in memory and just back up to disk.  Performance tuning becomes less of an issue, and we get to focus on functionality instead of the number of bytes an index will take.

Think back ten years ago in general computing & programming: people were still writing programs in assembly because they needed the speed.  Now, raw speed of an app isn’t as much of an issue for general programmers and they get to focus on which cool new language will make the programming faster, not the code execution.

To me, that’s really cool and exciting.  It means in a few years, we might be able to do more data mining and predictive analysis with even the most basic, everyday databases.  I might be able to say, “Man, remember when we had to worry about the number of indexes on a table?  Wow.  Yesterday sucked.”  That’s awesome!