Over the last nine months I’ve presented (virtually) eleven times on a variety of topics relating to SQL Server and the Microsoft Data Platform. Long-time readers will know I have some experience as a high school teacher and college lecturer, and I’ve co-authored three technical books on SQL Server.
My most popular session at the PASS Summit in 2020 (which you can watch on YouTube) was about what it means to be a DBA, because the landscape is changing. Microsoft has made massive investments into shared computing through their pervasive Azure service offerings. Even Azure has had a bit of an identity crisis, first by being part of the Windows everywhere strategy of Steve Ballmer, then as a more focused cloud division under Satya Nadella, and now evolving into what we were all destined to see: a hybrid mix of on-premises and cloud computing.
Whether we like it or not, the economy of cloud scale is attractive to many organizations. Despite all the “it depends” from consultants and Microsoft’s own documentation, folks are jumping in headfirst and worrying about billing later. This is not unique to Microsoft of course. Other competing cloud vendors including Amazon and Google — and smaller players like Oracle and IBM — have attractive services for a relatively modest monthly cost (and operating expenses are more attractive to the balance sheet than capital outlay for new hardware and software every few years).
There’s obviously something good there, in other words. The sheer capacity of cloud storage alone is unimaginably huge. Azure Storage, Amazon S3, Backblaze B2; I’ve always said that storage is the gateway drug to the cloud.
But let’s turn our head to databases once again. There’s an industry joke that Microsoft gets things right in version 3 of their products. Well, frankly speaking, we need to take a hard look at version 3 of SQL Server in the cloud (also known as Azure SQL Database). There are single databases, database pools, Hyperscale and so forth, all respectable offerings in their own right, but the big daddy of hybrid has to be Managed Instance. This is where instead of having to rearchitect a database for a cloud workload (or lift and shift into yet another virtual machine) MI is meant to be the best of both worlds, and we’re in for a treat with SQL Server 2022.
A headline feature of the new version is failover to Managed Instance. Not only that, but you’ll also be able to fail back from Managed Instance to an on-premises 2022 instance again. As other people in this community have also written about this feature, it’s a huge technical success on Microsoft’s part to take a versionless database based in Azure and make it run on a versioned instance of SQL Server.
I’ll be the first to admit that those of you not in the Enterprise Edition world would not see much use from this. If you’re budget conscious, this is just something nice to think about as One More Thing you won’t use. But for tens of thousands of organizations around the world, high availability without thinking about versions and backward compatibility is hugely attractive. Not only that, but the ability to restore a Managed Instance database locally means that you can continue running your dev, test and QA on-premises. Your data is portable. You’re not tied into a specific cloud vendor just because you have the convenience of a fully managed data environment.
So, I have some questions for you. Does this brave new world interest you? What do you want to know more about on this blog? Is Managed Instance even on your radar? If not, do you want a deep dive into specific features of Azure SQL or SQL Server on-premises? Are there gaps in your knowledge that you’d like to fill? Maybe you want to brush up on some fundamentals of database design. Perhaps you want to find out more about SQL Server on Linux or containers.
Help me help you make the jump, for free, right here on this site. I look forward to hearing from you in the comments below.