Azure Virtual Machines: Initial Thoughts

Last week was a weird one for me. For the first time in more than 25 years, I found myself unemployed. I was anticipating using my newfound abundance of free time to learn as much as I could while I continued searching for my next employment opportunity. But my plans got scuttled: as a Floridian, I found myself coping with the aftermath of hurricane Irma. I was fortunate to have no damage to my home. There was plenty of cleanup to be done around the house, however (mostly downed tree limbs). I was one of the lucky few that had power at home. Many local friends were not so lucky. Some of them came over for a hot shower, the glory of air conditioning, and a sympathetic ear. Schools were closed for the week and my young son was home.

Despite my unexpectedly busy week, I found time to create a Microsoft Azure account. I created my first VM in Azure, which got me thinking (uh-oh) and inspired this post. In the on-premises world, creating a new SQL Server VM might involve several people: a virtualization specialist, a networking engineer, a storage admin, a windows/system admin, and a database admin. Granted, in many organizations, we wear many hats. So in small-ish shops, a single person might be all that's needed to create that same SQL Server VM. In Azure, I can't see it being anything but one person.

In Azure, you can pick a VM template with SQL Server already installed. Networking options aren't templated--you have to make some choices. But Azure does some "hand holding" to get you through without needing much networking expertise. If you under/over-provision RAM, CPU, and/or storage, you can increase or decrease those resources fairly easily. (To be fair, this holds true on-prem for VMWare...and presumably Hyper-V too.) So to summarize: a single person can quickly stand up a VM without much knowledge of SQL Server, networking, virtualization, or storage.

And that may be a good thing or a bad thing, depending on your perspective. There's been a lot of debate and discussion recently in social media about whether the DBA is or isn't dying or dead. At the very least, I'm thinking we may no longer be needed for new installations. Maybe that's already the case if your organization uses VM templates with SQL Server preinstalled. There are plenty of other observations about the changing/evaporating role of the DBA of the future. I'll leave those alone for now.

As for the networking ingredient, I wish I had more insight. I get the feeling bad network choices made when an Azure VM is created could be anything from annoying to disastrous. I suspect the network engineer skill set is still vital in the Azure world. But man, Azure sure does make it seem simple.

Perhaps it's the storage, virtualization, and system admins that have the most to be worried about. Is Azure a gut punch for them? People with expertise in those fields can configure VMs that are "better" than what most Azure users could. But in typical Microsoft fashion, Azure is probably "good enough" for most. I continue to believe speculation is an exercise in futility, so no predictions here on my part. But if you're late getting to the Azure party as I was, you should know what you're up against.