I was lucky enough to be invited to speak at the Windows Azure Boot Camp in Grand Rapids. I presented along with Dennis Burton, and Jason Follas. I covered Azure Queues, Azure AppFabric, and the closing session on migration strategies into the cloud. (You can download the materials at the boot camp site.
I enjoyed the trip. There was a lot of enthusiasm for the Azure, and for moving applications into the cloud. I’m thrilled to see our region building momentum behind cloud and Azure adoption.
Here are my key take aways from the sessions I delivered:
Azure Queues are conceptually like a queue data structure. Obviously, most developers don’t need a full session to discuss a queue data structure, so there must be more here. In the case of Azure queues, that’s additional features for redundancy and persistence, and a protocol to ensure that messages are always processed: never started and then dropped.
Azure queues are a persistent and redundant data storage (like blobs and tables). All the instances of your application’s roles can access the logical queue. If a node storing a physical queue is rebooted (for a service upgrade, or some other hardware or software failure), the queue does not lose any of the messages. Other copies are still available, and the redundant node will come back, or migrate to a new VM if the node has a serious hardware failure.
The protocol for processing messages requires you write some defensive code when processing queues. Message processing is a three step process:
This three step process allows Azure queues to help you ensure that all messages are processed completely. If your worker role fails to finish processing, and doesn’t call DeleteMessage (within the specified timeout), that message moves back from the In Process state to the waiting state. The message now will be processed by another worker role.
Point to remember: DeleteMessage() must be the last method call you make when you process a message.
Of course, a catastrophic failure may not be the only reason a queue message does not get completely processed. Your worker role may simply exceed the timeout. In that case, the queue still marks the message as un-processed, and hands it to another worker role. This does mean it is entirely possible for queue messages to be processed more than once.
Point to remember: Azure queue messages will be processed at least once. They may be processed more than once, due to timeouts. Ensure that your message processing code is idempotent. Processing a message twice (or more) must produce the same result as processing a message once.
AppFabric can be hard to describe. There are a lot of nuanced features under the AppFabric umbrella. There are many different ways to use it to produce applications that are a combination of on-premise and in the cloud services. I find this session one of the harder ones to discuss. There’s just so much and so many different scenarios. It’s easy to give this session and leave attendees with spinning heads at all the possibilities.
I finally came up with a quick phrase that, while not strictly accurate, does get your head in the right space:
AppFabric is the Conjunction Junction of Windows Azure: It’s job is hooking up services, and making them run right.
Of course, that is obviously a simplification. But, it is a useful way to think about AppFabric. If your design calls for services running in different locations, and you want to have those services connect to each other, AppFabric is the right tool. AppFabric also helps with connecting peer-to-peer services. It’s got components and features that help with authentication and authorization.
In general, when different services need to find each other, and the end goal is having those two services speak directly to each other, starting the conversation by having AppFabric connect the two services is the right choice.
This is also a tough session, because the AppFabric is still in CTP mode, and new features and changes are coming quickly. I did have trouble practicing one of the demos because of the updated AppFabric portal release. I like the new portal much better, but I haven’t found all the features in it yet.
The final session was is the one that discusses ways to migrate your existing applications and services to Azure. It discusses different ways to take large enterprise applications, decompose them into services, and migrate those services where you will get the most return quickly.
The key point: The Azure platform includes many ways to communicate between services on premises and in the cloud. The best way to get your applications in the cloud is to pick the service with the best ROI and move it. Rinse, and repeat with the next component or service. I do think this is one of the most important differentiators between Azure and Amazon’s EC platform. The same migration strategy requires much more work on the EC platform than it does on the Azure platform. You’ll need to build the communications infrastructure that is already part of Azure.
Dennis and I will be involved in two more Azure Bootcamps: April 13,14 in Southfield MI (near Detroit) and April 20-21 in Downers Grove, IL (near Chicago)
All of these projects are Open Source (using the Creative Commons license for content, and the MIT license for code). If you would like to contribute, visit our GitHub Repository. Or, if you have questions, comments, or ideas for improvement, please create an issue for us.