The idea of "SQL Server in the cloud" is all the rage as I write this article. Many SQL Server experts already predict the demise of the IT data center and a complete upending of the current state of our industry, in which large enterprises can spend millions of dollars on SQL Server licenses, hardware and staff. I have to admit, when I first heard about this idea, I was ecstatic. What could be better for an enterprise than to have all the goodness of a SQL Server database with none of the hardware or staffing issues? However, on deeper examination, there is much about which to be cautious.
The first red flag for "SQL Server in the cloud" is simply an issue of expectations. Microsoft initially announced a plan for SQL Server Data Services (SSDS), later renamed SQL Data Services (SDS), as a component of their Azure Services Platform, http://www.microsoft.com/azure/default.mspx . However, many of us hear the words "SQL Server" and "cloud" used in the same sentence and find both loaded with meaning and implications. To use an analogy, being promised "a fine steak dinner" in a "four-star dining establishment" conjures a very specific set of expectations in most people's minds. Even if the meal and the establishment are of high quality, people will be disappointed if they don't measure up to their expectations.
Let's dive deeper. Upon further analysis, Microsoft's declaration that SDS would be "a lightweight and limited set of features" drew slidelong glances as enterprises and ISVs waited with baited breath for an opportunity to play with the Community Technology Preview (CTP). For example, SDS has very limited storage capacity; a BLOB cannot be larger than 100mb in size and its metadata cannot be modified. If you need to make a change to a BLOB's metadata, you will have to drop it and recreate it. Databases created in the cloud, called containers, also are limited to not more than 1,000 containers- that is, tables and other database objects. Other oddities include no support for capital letters in container names (at least at the time of this writing).
A number of business-side issues also exist. For example, Microsoft makes no promises about the consistency of service speeds. Customers who have exceeded their allotment of storage or CPU cycles might see their access limited, or, even find that connections are turned away. Similarly, there is no means for a customer to identify, through their own mechanisms or tools, where in the cloud their data might be and whether any of their own data is at risk in the event of a security breach. Is this OK for your part-time T-shirt business? Maybe. Is this OK for a major enterprise? Not just no, but heck no!
As you can expect, users were less than happy with this very limited set of features, as well as the performance limitations. In fact, the outcry from many users, especially ISPs, apparently has been enough to cause Microsoft to support a much fuller set of features in Azure in time for the Microsoft Professional Developers Conference (PDC) this November.
I believe Microsoft definitely will get this puzzle's equation right. It's only a matter of time. Will it be in time for the 2009 PDC keynote address? If I were a betting man, that's not a risk I'd take. I think the launch of a full-featured SDS will be measured in years, not months.