First Time in the Cloud with SQL Data Services

I just completed putting data into the cloud for real and getting it back out using SQL Data Services for the first time, and I wanted to share the experience.

I've been chomping at the bit to do some real cloud computing ever since attending a Software Design Review about 7 weeks ago. I could develop locally with the pre-CTP SDK that was made available to me, of course, but I didn't have a cloud account. The whole idea is to use the cloud after all, so cloud computing on your local box isn't terribly exciting. At PDC2008 the platform was branded (Windows Azure), the CTP given out (updated software), and most important of all you can now sign up for cloud accounts.

I finally received an Azure Services account invitation this week which allows me to make use of SQL Services and .NET Services. Apparently a separate but similar process will give me the ability to put applications into the cloud. In the meantime, I'll have to be content creating local apps that can use the cloud for storage, access control, service bus communication, and workflow (those last 3 are what .NET Services gives you). This is what the portal looks like once you've set up your account:

I decided to start with SQL Data Services. There is an SDK for SDS, which you can download from the SQL Data Services Developer Center. Included in the SDK is SDS Explorer, which looks like this:

While the SDS Explorer is rather simple, simple is all you need to use SDS. HTTP GETs and POSTs are what you use to retrieve, query, or store data using REST. There are other ways to access SDS, such as using C# or Ruby, but using REST from the SDS Explorer seemed appropriate for first-time experimentation.

This is definitely not your father's SQL Server:

• There's a learning curve. There's a new authority-container-entity hierarchy you need to understand. Authorties hold containers. Containers hold entities. Entities are like tables, but records are really just ids and data. An entity can be homogenous where all data is similarly structured, or jagged. Fortunately the documentation explains this nicely.
• Access using REST is simple. It's way different from what you're used to in the enterprise (not necessarily in a bad way), but I found myself comfortable using GETs and POSTs to store and retrieve data in no time.
• It's fun. Once I finally stored some records and was abel to retrieve them, I felt a real sense of accomplishment. And it was fun. Granted these are baby steps, but you've got to walk before you can run. Performance was excellent.

I have to admit, this experience is warming me to REST. Those restafarians might be on to something after all.