Like most people, I chuckled under my breath when doomsayers started publishing books about the apocalypse predicted by their interpretation of the Mayan calendar. In their view, the Mayan calendar ends in 2012 and thus spells doom for us all - despite the fact that the classical Mayan calendar, like ours today, was cyclical.
But as I was considering some of the momentous and disruptive changes we're facing lately, it suddenly hit me. The year 2012 might be the year when life as we've known it as IT and data professionals changes, completely and irrevocably. That's not to say that the world ends for us. It's just that the world as we know it will be replaced by something entirely new.
Consider the following:
- Improving virtualization technology means that the last holdouts against virtualization in most big enterprises, the databases, are finally moving en masse onto virtual machines (VMs). VMs provide a number of benefits, such as better utilization of hardware resources, easy provisioning and configuration, and very strong disaster recovery features. Those are three areas where many DBAs earn their bread and butter. While VMs might make those benefits easier to obtain for most IT organizations, they may prove to be career limiting for DBAs. I especially hear a lot of customers talking about how significant VM-based disaster recovery is for them, so, database backup specialists are looking at a big impact on their careers in the not-too-distant future.
- Ultra-cheap and convenient cloud database services mean that many simple transactional database applications will simply end up in the cloud, rather than on-premises. I've spoken with many SMBs who have no intention of installing a small rack just to manage their sales, customer management, or email systems. The cloud can do it quite nicely, thank you, and for pennies on the dollar, to boot. So, DBAs with a more generalized skill set are looking at a situation where their skills will be less needed in the not-too-distant future.
- Solid State Drives have finally broken the widening mismatch between the ever-increasing speed of CPUs versus the tiny, incremental improvements in speed of hard disk-based IO. The last time I checked a TPC benchmark, the vendor achieved tens of thousands of IOPs using about one thousand hard disks. Big systems like those in the TPC tests need dedicated IO specialists to build and maintain high speed database systems. But, once again, it looks like SSDs will diminish the significance of IO specialists in the not-too-distant future.
- Powerful multicore CPUs are here today, and even more powerful 32-core CPUs (such as Intel's Keifer and AMD's Montreal) are just over the horizon. Throughout the previous decades, when CPU power was expensive and scarce, DBAs spent a lot of time honing their craft as query tuning specialists. With abundant CPU waiting in the wings, it seems like another DBA skill set will be on the decline in the not-too-distant future.
In almost all major areas of DBA work, the near future is fraught with uncertainty and very likely to see a lot of disruption: setup and configuration, CPU tuning, IO management, backup and recovery. Even the art of database design is under attack by the NoSQL movement, which, in my opinion, is about the fact that NoSQL users do not have to design their database prior to deploying it.
Am I worried that the DBA will be out of a job in 4 years? Not really. In situations like this, I usually try to find a corollary from history, and we've got a lot to choose from over the past several decades. I find a lot of similarities to the progress of the automobile industry. There used to be a time when everyone who had a car had to be able to work on the car. My dad and his pals - at barbeques and picnics - would spend half the afternoon looking under the hood of the newest GTO or Barracuda. It was easy to work on those old cars, but, on the other hand, you had to work on them - a lot. Nowadays, most of us put three times as many miles on our cars as our parents did, but all we know about the mechanics of a car is where the gasoline goes. I think we're looking at a similar transition in data and databases - omnipresent and yet completely out of mind.