In part 1 of “What Makes SQL Azure Complelling?”, I focused on the DBA role and what is good & what is different with SQL Azure from SQL Server.
Now let’s talk about the SQL developer role.
The DBA role is only partially transparent from SQL Server to Azure and in some ways simpler, in other ways limiting and just plain different. For developers, the change will be less intrusive, but have a number of limitations.
One of the unmistakeable benefits of the Platform as a Service (PaaS) approach of Windows Azure & SQL Azure is that you can airlift your applications & databases to the Cloud with minimal impact and changes to code. In fact, with an application that you have written that connects to SQL Server via ODBC, all you have to do is change the connection string to the Azure connection string and everything will work just fine. The Windows Azure management screen even gives you a place to copy the connection string:
There are a few steps you need to follow first. You need to get your database from your traditional on-premises SQL Server database into SQL Azure. To do this, I typically use the SQL Azure Data Migration Wizard from Codeplex which you can download free here. It’s a great tool, very effective, simple and straight-forward. Microsoft is completing a CTP 2 of Data Sync for SQL Azure that will allow you to automate moving data around from SQL Azure to different data centers and also on-prem SQL Server that will operate similar to SQL Server replication, which is currently not supported in SQL Azure.
Next, you will need to make changes to your applications that may be required due to unsupported features from SQL Server in SQL Azure. Here is a complete list for application developers. And here is my list of common gotchas when converting applications from SQL Server to SQL Azure:
- Replication is not supported
- No support for CLR
- Partitioning is not support
- No Service Broker
- No FILESTREAM
- No Fulltext Search
- No Sparse Columns