When I first heard about the cloud I rolled my eyes. This will never take, it sounds very much like the mainframes we came to know and hate (my first database project was killing a mainframe that was costing our non-profit organization $15000 a month, which as a non-profit was simply horrible.) Even four years ago when I was writing "Pro SQL Server 2012 Relational Database Design and Implementation" I pretty much didn’t mention the cloud at all

My how times have changed. The cloud, and Azure in particular is becoming more and more the necessity to target our database work, because, in my opinion, it is filling two specific scenarios which are hard to provide service for (along with being generally useful for even more purposes):

1. Very small organizations: Places where they do not have the resources (human and computing) to provide a proper computing platform. The cost is likely far less for these scenarios in most cases
2. Very large computing needs: If you need massive power, it may be easier to use Microsoft’s platform to do your computing, particularly if you don’t need the power for long periods of time.

What is truly awesome about the way AzureDB works is that it is very very similar to the on-premise/box product. There are two versions of Azure that applies to us relational database types that I will work with. The first is running the box product on an Azure VM. For the normal database programmer, this will not change very much at all. For some, if not all of the book, this is how I will be running the code as I won’t be loading SQL Server 2016 on my laptop directly until RTM. It is certainly possible that I will use a local VM, but we will see. I will of course include my system settings wherever I include performance statistics.

The second is Azure SQL Database. Azure SQL Database is basically where you get a database exposed to the Internet instead of a virtual machine. You get a surface area the is very similar to typical SQL Server databases with far fewer knobs to adjust. If you want to know much more about the services the earlier link will give you an overview, I won’t cover too much about the Azure SQL Database platform, either here or in the book, but I will provide code that works in either location.

Both of the products, the On Premises versions and the Azure SQL Database versions are part of the Relational Database family of products. They share a common base, and a common purpose: to work with relational data. They look basically the same, and operate mostly the same, and serve (at their core) very same purposes.

As such I will make sure that all of the scripts that end up in the final book have been validated on the different editions of SQL Server (as I have always done), and have been executed at least once on Azure SQL Database as well. What I won’t do is go into many details of how to connect to an Azure SQL Database, mostly because it takes quite a few pages to do so (I just tech edited a book that covers such details, and I will direct readers to that book for details on how to connect… Peter Carter “Pro SQL Server Admin” http://www.springer.com/gp/book/9781484207116).

As a quick test, I took the code from the previous version of Chapter 6 (which I will be working on after I have written my presentation on Concurrency for SQL Saturday Nashville). Chapter 6 is a simple database create that demonstrates the basic process of changing a normalized base model to a physical database and the finishing touches that make even a 6 table design better.

All of the code for Chapter 6 executed with no change, except for a few of the fundamental differences between AzureDB and the On-Prem versions:

1. Dropping and creating the database (So I changed the script to drop all objects first, a practice I use for all clean model databases that will be used for unit tests and compare scripting with active databases).
2. USE statements to change from master to the user database

I hope this change to the book will be useful to the readers as they start to make changes from on-prem to cloud databases to see where the differences lie. I expect many people, even a lot of seasoned pros are wary of how much work the cloud versions of database implementations will be. I will cover in later blogs and the books some differences you need when building your databases, and in building your applications to leverage a platform where there may be some exaggerated latency (and some cost) if you don’t do a good job of building the entire system with bandwidth as a concern.