I spoke at the SoCal Code Camp in San Diego yesterday (6/26/2011), giving a new talk called “Azure for Developers, Part 1 and Part 2”. The point of the talk is to show the different bits of Windows Azure and how to code them, and explain why you would use each bit, sharing my experience migrating my company’s infrastructure to Azure last year.
Here is what I covered in this talk:
- SQL Azure – migrate a database from the local SQLServer to a SQLAzure instance.
- Create a Web Role with a WCF service. Add code to handle the transfer of diagnostics to Table Storage and Blob Storage — tracing, IIS logs, performance counters, Windows event logs, and infrastructure logs.
- Add methods to the service that read and write to/from the SQL Azure database. This includes exponential retry code for SQL Azure connection management.
- Change a client app to consume the service, show how to add a service reference and then call it.
- Show how to change the connection strings and publish the service to the cloud.
- Change the client to run against the service in the cloud and show it work. Show the diagnostics using the tools from Cerebrata.
- Add a method to the service to submit an entry to queue. Add code to initialize the queue as needed.
- Add a worker role. Add code to handle the diagnostics. Add code to initialize the queue as needed.
- Add code to the worker role to retrieve the entries from the queue and process them.
- The method that processes the queue entries writes the messages to blob storage.
- Update the service reference in the client and run it; show the results in blob storage.
So it covers: SQL Azure, web roles, WCF services, diagnostics, queues, blobs, and worker roles. That’s all the big stuff except for writing to table storage. I couldn’t figure out how to incorporate that into my application, and covering everything above took almost the full two hours.
One thing to note — The code that handles the exponential retries when accessing SQL Azure is a brute force method. You might want to check out the best practice recommendation from the App Fabric team, which can be found here. They have a framework that provides extension methods to the calls to SQL Azure that include the retry code. I would make two changes to this code – I would change it to allow me to pass in a string to be logged with the information, and a boolean telling whether or not to log the SqlContextID. The SQLContextID can be used by Microsoft to figure out what’s going on, but you have to make a database call to get it, so you should use it specifically, not everywhere.
If you do use my method of putting in the retry code yourself, you can test it by mucking up the connection string to the database to make sure all of your retry tracing works right. It’s the pits when you find out you put in the wrong number of arguments or somehow mess up your tracing statements!
The code and the database can be downloaded from here. The database was created using SQLServer 2008 R2 Developer’s edition; I’m providing the mdf and ldf files. Just put it with your other SQLServer (or SQLServer Express) data files and attach it using the SQLServer Management Studio.
If you’d like a 30-day Azure pass, you can get one here: http://bit.ly/robinonazure. This provides the following, which should get you well on your way to figuring out how to use Azure:
- Windows Azure – 3 small compute instances, 3 GB of storage, and 250,000 storage transactions.
- SQL Azure – 2 One-GB Web Edition Databases
- App Fabric – 100,000 Access Control Transactions and 2 Service Bus Connections
- Data Transfers – 3 GB in, 3 GB out
If you missed me in San Diego, you can see me at the San Francisco .NET Users Group on 8/17/2011 or at the Silicon Valley Code Camp on 10/9/2011. I’ll also be presenting online to the LIDNUG (LinkedIn DotNet Users Group) from 10 a.m. to noon PST on 8/26/2011. I’ll post other opportunities as they firm up.
If you have any questions or comments, please feel free to leave a comment below and I will respond to it.
RobinDotNet's Blog 