What makes the Cloud-based version of SQL Server, SQL Azure, compelling? Part 1 …
I am going to have to do this in parts because there are different IT & business roles that will see different value in SQL Azure based on the aspects of their jobs that are affected by a move from on-premises to Cloud. The change can be minimal in some cases or dramatic in others.
Let’s start with the primary role interacting with SQL Server databases: DBAs.
Compelling features:
- Quick & easy to provision a new database. By going to your Windows Azure portal, you can request a new database of varying max size, up to 50 GB and have a new database ready in minutes.
- Costs. You pay monthly like your database was a utility. If you averaged 10 Gb size for your database in SQL Azure, you pay that rate.
- Elasticity. Now, if you start growing to 20 GB and 30 GB, your database is just fine in SQL Azure. You now step-up to the price points for those larger database sizes.
- Easy to migrate. There are tools on Codeplex and a new version coming of Data Sync to let you integrate and sync data similar to replication seamlessly between Cloud and on-prem SQL Server.
Things to be aware of – differences from SQL Server:
- You do not have control of the system & instance levels of SQL Server in SQL Azure. This is not the same as standing up a box or a VM with SQL Server. You get a database that is part of PaaS (Platform as a Service) in a Microsoft data center.
- Backup & recovery is not the same. There is a database copy feature that you can schedule to create “snapshots” of the database that are copies. Backups are built-in through the fact that 3 replicas of your database are constantly maintained by the Azure infrastructure.
- High availability is through database replicas and the Azure infrastructure. You get the same replicas and the same infrastructure for each database. You do not set-up mirroring, log shipping, clustering, etc.
That is not everything there is to know, just a few pointers to get you started. I’ll move on to developers next in part 2 … Many thanks, Mark