I decided to start a series of blogs where I interview key people in the SQL Server community. Instead of me asking technical questions, I plan on asking about their outlook on the future, books they read (non-fiction and/or technical), and their overall thoughts on where technology (mainly SQL Server) is headed. You can find more interviews here.
Mohammad: Do you think people who dismiss the cloud as a “fad” or just don’t take it serious enough to learn about it (i.e. Azure, AWS, etc), will be in a tough spot to find a job 5 years from now?
David: I see SQL Server technologies evolving in numerous directions, but the overarching theme will be cloud. Just look at the current release cycles for on-prem SQL Server. It’s a compiled and boxed version of the SQL Server features that are already released in Azure SQL Database in the previous months. Even the Linux release is (IMHO) partly because cloud-based SQL Server platforms are looking for a smaller footprint operating system. The bigger question for me is – are your applications ready for the shift? Most business-critical app vendors that I see are not yet even supporting SQL Server 2016, let alone newer versions. The limitations of DBaaS also are too much for many of these applications. But… they’ll get there, and you must be ready.
Mohammad: Do you ever see the traditional SQL Server DBA role being replaced/eliminated?
David: Never. I don’t see it being replaced or eliminated as long as the DBA themselves are able to keep up with change. I see the role evolving, and quickly, however. The role is evolving. Just like with cloud technologies, other features and tasks are changing. DR in the cloud is becoming just a few clicks. Backups and restores are much simpler to set up and manage. Availability is easier with Availability Groups. Many of the routine day-to-day operational tasks that DBAs have been tasked with for years are being automated. However, the role is drastically changing. While these tasks are being made simpler or are being automated, the role of the DBA is changing to be a bit more proactive. The DBA should start to emphasize tasks such as performance tuning, query optimization, and database design improvements, all of which can help to boost the performance of the applications. The other challenge is keeping on top o the all of the new enhancements that the DBA is able to leverage to make their lives easier, streamline operations, and improve business continuity. It’s a never-ending cycle of learning, one that I personally thrive on (I get bored easily!).
Mohammad: What are you most proud of doing/accomplishing for the SQL Server community so far in your career?
David: I’m probably the most humble guy in the room and I don’t much like talking about myself. But, I’m thrilled to have been able to help DBAs in the SQL Server community learn more about the infrastructure that their databases are powered by over the years. I’ve thoroughly enjoyed training thousands of professionals at events all over the world on the art of how virtualization, CPU and memory architecture, networking, storage, and the operating system all relate to databases. Most recently, we’re adding cloud into the picture too.
Mohammad: What non-technical/non-fiction book/s would you recommend? If you only read technical books…what do you recommend?
David: I’ve got a pretty eclectic list of books that I’ve been reading lately. The books that are non-technical but directly applicable to the job are all about the psychology behind presenting, probability and statistics, entrepreneurship, and negotiation. I haven’t had too much time lately for recreational reading outside of more technical subjects I’m afraid. If you want to read two of the best technical books that I’ve ever read, read ‘The Mythical Man Month’ by Frederick Brooks, and ‘SQL Server 2005 Practical Troubleshooting’ by Ken Henderson.
Mohammad: For someone who’s career focus has been on one aspect of SQL Server (i.e. Database Engine), do you think it would be wise for them to become a “jack of all trades” by starting to learn, SSRS/IS/Azure, etc. or remain focused on their area of expertise? In another words, which would you say is more valuable? mile wide / inch deep or inch wide / mile deep?
David: I prefer both! Now remember we’re consultants, and we’re asked to do a lot of things around the SQL Server platform, so my view might be a bit skewed at this point. I personally want to see folks that are skilled in many facets of a product like SQL Server and how it relates and applies to the business. It’s more of the mile wide approach from how it relates to the business and how the different features relate to each other. However, for the core features that directly relate to the needs of the client/project, I want the person to know certain critical areas extremely well. It’s a good mix of mile-wide and mile-deep in the areas that matter for their interests and job role. For example, our focus is on how the SQL Server engine interacts with the platform underneath it. I specialize in SQL Server internals, HA/DR, performance tuning, and all of those items for the platform below it. However, at this point in my career, I know how to *spell* SSAS and that’s about it. I can virtualize and tune the infrastructure around your warehouse, but I’ll refer any requests for us working on a warehouse to other folks we know that can do it a lot better than us.
Being a mile wide and a mile deep in certain areas makes you more adaptable as the world changes, and you can transfer the deep knowledge to a new ‘thing’ quicker. If you’re a technologist solely focused on a certain feature of a certain product, what happens if that feature is deprecated? Or a better feature comes out? I had a friend in college who was one of the most amazing Adobe Flash developers that I’ve ever seen. Now look at the state of that technology. It’s virtually dead, so if he had not recognized this and transferred the energy to learning a new product/platform/feature, he’d be out of work at this point.
The same goes for our virtualization knowledge. ‘Cloud’ is shaking up the world. All cloud means is that it’s someone else’s datacenter and they put some serious automation and abstraction around the various components. Our shift to the cloud was arguably quicker than DBAs who had never been involved with the infrastructure and virtualization in their datacenters. Today DBAs need to know about things like IOPs, network firewall rules and routing, and server sizing in ways that some environments insulated them from in the past.
I’ll stop my ramble there 😊 To shorten the response, you should be both. Specialize but have a keen awareness of the things around it, because as the world changes, so should you!