SQL Server in the Cloud
It costs a lot of money to own and operate a relational database platform. Wouldn't it be nice to be free of that trouble and expense?
What if your users could just ask for the data they want and it would appear magically out of a cloud? For one thing, you would be done with hardware costs, software licenses, and a heavy maintenance burden. For another, no one would ever wake you up again at 3 am to tell you that the database server crashed. All this for a hundred dollars a month.
A few years ago some people began to take those pipe dreams seriously. They started developing what we now call cloud computing, data management as a service. A number of vendors including Microsoft have now launched their first generation cloud services. A dream come true? Not exactly. Now the dream hits hard reality.
We took a look at Azure, Microsoft's cloud computing environment. We found a platform that may be useful for some niche databases and departmental-scale applications, but is not quite ready for prime time.
That doesn't mean Azure can be dismissed from your consideration. It just means it is not ready for large scale, high volume, high performance applications.
Database services in the cloud will find a place in the SQL Server world. It is worth your time to take a look at Azure now.
Microsoft’s entry into the cloud computing arena is composed of three components: Windows Azure, the operating system, SQL Azure, a SQL Server database instance, and .NET Services, the resources for application development. All three are implemented as services located in the cloud.
You can sign up and start using Azure now at no charge. Microsoft will begin charging for Azure on February 1, 2010. The entry level subscription will cost $9.99 per month and allow you a database of 1 gigabyte. The higher level subscription will allow you a database of up to 10 gigabytes for $99.99 per month.
Either subscription will allow you a maximum of 4 user databases of sizes totaling no more than the subscription limit. That means 10 gigabytes is currently the upper limit for any Azure database.
In addition to the monthly subscription, there are additional charges for bandwidth usage ($.15/gb) and for additional file system storage ($.25/gb).
The advantage that Azure has over competing services like Amazon’s SimpleDB is that Azure is relational and supports an almost complete set of TSQL commands. In SQL Azure you can design a normalized database. You can join and query tables using TSQL syntax.
Competing services use other kinds of access methods on non-relational data stores. With Azure you can leverage the skills already in your organization and do not have to tackle an unfamiliar programming paradigm.
However, cloud computing in general and SQL Azure in particular have some limitations you must take into consideration when planning to deploy to the cloud.
It is both the strength and weakness of cloud computing that the database server is invisible to you. You are free of the cost of owning and managing a database server but you are also subject to the decisions and policies of those who do manage it. For example, Azure will drop your user connections if any of the following things occur:
• Excessive resource usage
• Long-running queries
• Long-running single transactions,
• Idle connections
After considerable searching, I have not found any definition of what “Excessive”, “Long Running” or “Idle” mean to Microsoft in this context. Does your query get disconnected at 30 seconds, 10 minutes or an hour?
How might you fix long-running code that causes your users to be disconnected? You will not do it with SQL Profiler, because that tool is not supported by SQL Azure.
It is difficult for me to see how Azure in this first incarnation could be very useful for an enterprise level database. Even if your database will fit into 10 gigabytes, the limitations on what your can do with it are significant.
For example, database backup is not supported. Microsoft suggests that you either bulk copy or use an integration services package to regularly download your database data to flat files. This means that your recovery options are limited to time of your last download. Log or incremental backups are not possible.
If you use Integration Services to download your data, IS must exist on a sql server in your own environment because it does not exist on the cloud server. In either case you will pay bandwidth charges for pulling down all of your data at regular intervals.
Here are some other limitations that might pose problems when implementing your application:
• Windows authentication of users is not supported. You must use SQL Server logins.
• You cannot use the “sa” login since it has server-wide scope. When you set up your database, you are given instead an account that works much the same as the ‘sa’ account, but has permissions only in your database.
• You must always use encryption when connecting to the Azure database
• All tables must have a clustered index.
Here is a link to other limitations and guidelines in this release of Azure.
Security and Private Clouds
Acceptance by large corporations will be the key to the success or failure of Azure and cloud databases in general. So far CIO's in that arena have been extremely resistant to the whole idea. At bottom are issues of security.
At the recent InterOp conference on Cloud Computing in New York, Rico Singleton, deputy CIO for the state of New York, asked the cloud providers present "Can you give me a private cloud that can provide all the benefits that you provide now on my private network closed to the outside, and still be able to give me similar ROI?" Many other attendees echoed the same sentiment.
The Microsoft representative Yousef Khalidi said that private clouds are in the planning stage. However, it is difficult to see how that can be accomplished at competitive prices and without abandoning some of the fundamental benefits of cloud computing.
There is not enough data available to say anything definite about Azure performance. However, it seems from the few reports available that we can expect an Azure application to be significantly slower than a comparable application hosted in a traditional server environment. I believe this will generally be true of all cloud databases, not just Azure.
At this point, perhaps the most useful thing an enterprise could do with SQL Azure is set up a test environment to gather experience in cloud based development.
Cloud computing will eventually become a viable environment for some applications because of the cost savings it can provide in specific situations. Your team will want to have the necessary experience when Azure is ready for enterprise-scale development.
I would be interested in hearing your opinion about Azure in general or this article in particular. If you have a moment, please send me an email.
SQL Consulting, Inc.