Cloud VMs are Not an Architectural Failure on Your Part

With the demise of the #SQLHelp hashtag (well it still exists, but it’s much harder to support since Elmo ruined twitter), I’ve been spending the cycles I used to spend on #SQLHelp at the Azure subreddit. I see a lot of questions there around migrating on-premises databases to platform as a service offerings like Azure SQL Database or Azure SQL Managed Instance. Those solutions are very good, for some solutions, but like an other architectural decisions they all come with some trade offs, which I’d like to discuss in this post.

The other reason why I’m writing this post is something, that I wrote in my last Redmond column about Broadcom’s acquisition of VMware:

While many experts suggest reengineering applications so they aren’t dependent on VMs (for example, containers or other cloud native services), a lot of the customers in question don’t have development staff, and buy line-of-business software that has been subject to the same private equity playbook and doesn’t see big development efforts. There are no easy decisions for customers, and the challenges around VMware will continue for several years.

A lot of people will tell you that you should re-engineer your applications to run in containers, or PaaS offerings. Or even your database servers—I might have even told you this. And while if you are building your own applications, and managing your entire stack, I stand by my statements.

However, most of the audiences I speak to, and clients I support are either using third-party software, or have legacy code, that would require a great deal of engineering to support using a new platform. Does your application do cross-database transactions? You probably can’t use Azure SQL DB. Do you need more than 16 TB of space? You can’t use managed instance, without paying for literally the most expensive SKU.

Cloud VMs are really good–the SQL on Azure VM team has done an excellent job of building new features, you can do everything you could do on-premises, your migration options are easy and the same as on-prem, and you can granularly control your resources like storage volume and performance, memory and CPU cores. If you are using RDS, Managed Instance, or SQL DB, you are limited to what the cloud vendor provides.

Matt Gordon and I are going to be doing 100 minute session at SQL Bits called “When to Wave of Landing Data in PaaS Services”, and we are going to cover when you should and shouldn’t use a PaaS database services. We’ll talk about the cost perspective, the management tradeoffs, and our experiences both good and bad with some of these services. There is nothing inherently bad about any of these services, but they aren’t the best use case for all workloads.

Share

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Trust DCAC with your data

Your data systems may be treading water today, but are they prepared for the next phase of your business growth?