SQL Azure Decoded (SQL’s new name)
If you want to be brutal about it, SQL Azure is just SQL’s new name. Think the same three capital letters, only now in a blue-cyan shade. Granted, Windows Azure is a great big new shiny platform as service, which can piggyback on both Microsoft server farms and on premise infrastructure.
You would almost have heard of the other four tenants: Live, .NET, SharePoint, Dynamics CRM. However, as far as SQL is concerned, there’s simply very little difference, Azure or no Azure. This is just another relational model database server service that you can run off your radar screen.
Amidst all this exciting non-development is actually a sound strategy. Services such as reporting and synchronization are usually quite highly customized to inpidual server needs. By playing a game of changing expectations, SQL Services can approach modern demands of multi-tenant scalability on a gradual basis. Since administrators aren’t promised anything, there’s little scope for disappointment either. So in this article, let us take a closer look at the actual advances made in the name of Azure.
First of all, there are exciting developments in the architecture involving discontinued support – specifically. The entity-based ACE data model (property bag) is finally laid to rest. Applications now gain access through Transact SQL-over-Tabular Data Stream, which means you can still reach your relational data in the old-fashioned way with internet friendly protocols like HTTP and REST through the ADO.Net Data Services framework. Administrators can rest assured that operation-wise, managing an on-premise SQL will feel just the same andwith the majority your favorite applications and TSQL codes still functional. Of course, you might need to amend it a bit to get the most out of the fully relational data model, or perhaps even write up some new applications. The bottom line is that the legacy data access routines are very much available for extra services.
So it’s the same technology especially in the areas where it really matter, such as mission-critical enterprise and web applications. Of course, routine dictates a flurry of announcements for new functions and support for all sorts of obscure data types. Unfortunately, only the basic Relational Database Management Services (RDBMS) capabilities are available at the moment. You’re looking at a subset of the existing SQL Server built-in stored procedures and system views but at least you can track how much you’ll get billed in real-time. At least we can take solace in a highly available, scalable and distributed environment, even if you can’t tell the difference before they changed the name.
Perhaps something more exciting then. The Azure Table Storage which is a simply structured, non-relational and scalable data storage solution. Depending on your needs you can add on additional structure to your data, or forget all about it if you’re sticking to REST-based structure less miasmas and even mix-and-match with SQL since both are supported in parallel. Besides, since the current maximum size for your SQL Azure database is a paltry 50GB, you’re going to need some help on the side.
If you’re thinking about creating new applications, you’ll be modifying the good old Visual Studio (perhaps even Eclipse in the near future). There’s also the possibility of ASP.NET controls and tools on top of that. As for the promised web-based management suites and documentation with regards to other ostensibly interoperable languages, they remain a promise at the present. Still, we are looking at a large number of languages – remember Windows Azure is an open platform -ranging from .NET, PHP, Ruby and Python to Java.
For the innumerate execute, it all boils down to 10USD/month per GB up to 50 GB for the server itself; never mind that price list at the website. As far as I can see, at 10+ GBs (which gives you the Business accolade) you get a promise: auto-partition, CLR, fan outs etc., but not the actual provision of the features themselves. Data transfers are 10 cents in and 15 out, unless you’re based in Asia which are 20 out. From now until March 2011, everyone except the 1 GB and 10 GB plan gets unlimited inbound transfers during off-peak hours. Although the actual financial savings would probably escape your attention.
In this case, things feel somewhat dodgy. Bear in mind that the whole shebang remains a Community Technology Preview (CTP) service which is a polite way of saying we can’t wait to start charging you for things we haven’t really finished developing. Across most measures of uptime, be they connectivity, storage, access or whatnot, a rough rule-of-thumb is you will get 10% off in the following month if they fail three-nines.
Many of us are probably going to live in the cloud when the time comes.Perhaps in a far-off future (some say as many as five years) keeping physical servers will be seen as a quaint eccentricity, not unlike old people who hoard newspapers. So this is a good time to give migration some serious consideration. If you are a developer keen on experimentally locally, there’s the SQL Server Express version.
The first step is simple enough: export the schema and transfer the data. The former can be in the form of a TSQL script exported from Server Management Studio which can be executed against Azure. The latter could use the Generate and Publish Scripts Wizard. There’s also Sync Framework, which is handy if you haven’t quite made up your mind and prefer running your precious in both places for a while. There’s the Migration Wizard itself though community-built but it gives you much greater scope in terms of geo-controls or do it raw in bulk data copy with bcp.exe.
We would like to remind you, once again that Azure can’t run everything from your existing server (“a subset of features” in the parlance) and you’ll need to amend your code. It pays to pause for a moment and relish in the priceless thought of freeing your immaculately tended database from its shabby physical confines. Except, its price is 10 USD/GB, of course.
