Snowflake for SQL Server users - Part 2 - Cloud First Design

In recent years, I’ve done a lot of work in software houses (Microsoft calls them ISVs or Independent Software Vendors). Many of these software houses have worked out that they won’t be able to just keep selling their on-premises applications because their customers are asking for cloud-based solutions.

And more importantly, the customers want the software houses to manage the applications rather than themselves. So, many of the software houses start trying to turn their on-premises applications into Software as a Service (SaaS) applications.

And the outcome? Is almost always really, really poor.

Cloud First

The real problem is that those applications haven’t been written with a cloud-first mentality. They really are often the “square peg in a round hole”. What often happens is that the cloud-based versions of the applications have large numbers of limitations compared to the on-premises versions of the same applications, because recreating everything in the cloud (when there were things that weren’t designed for the cloud) is often nearly impossible.

I’m a big fan of Azure SQL Database, and they’ve done a great job on it (way better than almost any other application), but it’s still quite a distance short of where we already were with SQL Server on-premises. I wish the marketing for the product would focus on how what is there (i.e. a truly amazing product) but the discussion always seems to be around what’s missing, and how it compares to the on-premises product. In fact, I’m sure the entire reason that the Managed Instance versions of Azure SQL Database appeared were to address some of the shortcomings.

If the first time you’d seen SQL Server was to see Azure SQL Database, you’d come away saying how amazing it is. But if you’ve come from the on-premises product, chances are that you might be already using something that isn’t there.

Nice to have a blank slate

Even if you were brand new to Azure SQL Database though, you’d find aspects of how the product is designed that are based on thinking from decades ago, and were designed for systems that were available back then. It’s very hard to make major changes when you’re bound to trying to keep backwards compatibility.

One key advantage that the team building Snowflake had was a clean slate where they could design a product that targeted cloud provider based services under the covers, instead of on-premises physical devices and operating systems.

 

For an index to all posts in this series, see the first post here.

2019-08-15