Ian Hardenburgh considers Microsoft's strategy with SQL Azure. Where does it fit into the overall cloud picture and what benefits will it deliver to database admins and analysts?
For almost ten years now, I've been working with SQL Server technologies. I began using the product at its inception, right around the time when Microsoft first broke off from the Sybase code base, with its preeminent SQL Server 7.0 release. However, it wasn't until SQL Server 2000 came out that I came to realize its true potential as an ad hoc querying powerhouse. Then, I started to use Analysis Services, and was introduced to the world of BI and data warehousing. Shortly thereafter I was convinced I was working with a RDBMS and enterprise reporting system that could rival even the likes of what SAP and Oracle were doing at the time -- with tenfold scalability.
As the ASP.NET framework community grew, and improvements to its SQL connectivity and command functionality alongside it, the direction Microsoft was taking with its coveted and well selling database product became very clear. If data was to be at the center of the enterprise in the 21st century, SQL Server was to be both the principal storage point and analytical heart to that information. This is probably best exemplified with its continued advancements with time-tested services, like Integration Services and Reporting Services, as well as its continued development with more progressive technologies, such as with the imminent release of its Hadoop big data solution in SQL Server 2012.
However, parallel to the on-premise SQL Server, a lot of effort has been put into SQL Azure, as Microsoft prepares to be a seminal force in the cloud by complementing their cloud compute platform. Therefore, the question remains, are these two products (on-premise SQL Server and SQL Azure) impassive, where SQL Azure might be relegated to a MySQL type of storage point for application data, or is SQL Azure to become something of an end product for SQL Server in the coming years?
Even though Microsoft touts SQL Azure database's "manageability," "high availability," and "scalability" (see this MSDN library article), it should be noted that SQL Azure currently only holds a subset of the functional elements that on-premise SQL Server (2008) does. However, the SQL Azure database can be readily queried with T-SQL, akin to how one queries an on-premise SQL Server database engine. Furthermore, one can use SQL Server Management Studio to develop database objects, as well as to a certain extent - manage the database as one normally would. Of course, this doesn't include use of certain components like Integration Services, as they aren't directly stored within the Azure fabric, so to speak. On the other hand, one can use SQL Azure as a data source, in a bidirectional manner.
For example, you can retrieve data stored in a SQL Azure instance for use with an Analysis Services cube, or Reporting Services report. Additionally, and probably most habitually (when considering how Azure has become a haven for small development shops or single-purpose web services), one would use SQL Azure as the backend database for a Windows Azure Compute Web Role developed application.
So why does SQL Azure have all this co-dependence on on-premise SQL Server software? I think the most likely answer to that question is obvious. Migration takes time. And seeing to it that certain components like Analysis Services are extremely memory intensive, it'll probably be some time before we see enterprises opting for an entirely cloud-hosted SQL Server solution. In fact, it's quite possible that we'd never see these services be folded into the SQL Azure ranks at all. They could eventually be completely phased out, as Microsoft looks to provide on-demand hosted reporting tools like SQL Azure Reporting. Regardless of their direction, I have to admit that it was tremendously shrewd of Microsoft to start building the core of its technology (the database engine) in the cloud first. Even though they were obliged to shed a few pounds, by eliminating their BI toolset, in the interim.
Microsoft's SQL Azure strategy seems to be not all too much different than the one they are embarking on with Windows Azure. That being to provide their users with the means for integrated development, all while requiring the least amount of administration (on the users part that is) as possible. Earlier in this post I spoke about how I spent the better part of ten years watching SQL Server technology grow from a mere two-bit relational database, into an analytics juggernaut. My career has seen a similar path. Not in terms of being a juggernaut, but where toward the beginning of it, I spent much of my time just trying to store and secure data, now I spend the majority of my time trying to understand it, as I believe Microsoft intends. However, on more occasions than I'd like, certain administrative requirements like database engine tuning, as well as the all-so-boring database I/O performance measuring and planning type of tasks deter me from the more important job of statistical analysis and data mining (the real stuff that can make or break companies). This is when I see SQL Azure as my liberating force - my zenith in the sky, if you will. The place where I no longer need to administrate and can just simply develop.