Wade Wegner

I had the great pleasure of co-authoring an article on application migration to Windows Azure for MSDN Magazine with my friend George Huey, creator of the SQL Azure Migration Wizard.  This article stems from our work helping dozens of customers – both small and big – migrate their existing applications to run in the cloud.

(Ours is the second down on the left.)

While this article is by no means exhaustive, we did try to explain some of the common patterns and scenarios we faced when helping customers migrate their applications into Windows Azure.  I hope you find it valuable.

I was reading through the FAQ document for the Windows Azure platform this evening (what else is there to do on a Sunday night?), and I came across the following:

What is the Windows Azure AppFabric?

With AppFabric, Microsoft is delivering services that enable developers to build and manage composite applications more easily for both server and cloud environments. Windows Azure AppFabric, formerly called “.NET Services”, provides cloud-based services that help developers connect applications and services across Windows Azure, Windows Server and a number of other platforms. Today, it includes Service Bus and Access Control capabilities. Windows Server AppFabric includes caching capabilities and workflow and service management capabilities for applications that run on-premises.

Windows Azure AppFabric is built on Windows Azure, and provides secure connectivity and access control for customers with the need to integrate cloud services with on-premises systems, to perform business-to-business integration or to connect to remote devices.

The Service Bus enables secure connectivity between services and applications across firewall or network boundaries, using a variety of communication patterns. The Access Control Service provides federated, claims-based access control for REST web services. Developers can use these services to build distributed or composite applications and services.

I’ve spent a lot of time with the AppFabric, and believe I understand the intent of the above description.  But what about the rest of you?  If you have, or even if you haven’t, spent time using the AppFabric, how does this description resonate?  Does this help you understand the AppFabric, or are you left confused?  Do you understand it’s place and value in the larger Windows Azure platform?

I implore you to leave some feedback and let me know what you think.  Please, share your thoughts!  How can this be improved?

It was an amazing TechEd NA 2010, and I admit that it took me a few days to recover.  Between the heat and humidity, great times with friends, and good food, I managed to spend a bit of time at the conference.

I had the pleasure of co-presenting with Jerome Schulist, a solutions architect at the Tribune Company.  Jerome is one of the architects that engineered the solution that has allowed the Tribune Company to store and process terabytes of data on the Windows Azure platform.  This solution involves a number of really interesting scenarios, including:

• Parallelized upload of terabytes of digital content into Windows Azure blob storage using .NET Framework 4.0
• Best practices for uploading a massive amount of content
• Scaling strategy for Windows Azure blob storage through multiple storage accounts and a “round robin” pattern
• Content reprocessing with Windows Azure worker roles
• Automatic scale-out and scale-back of worker roles through queue lengths

For detailed information on this solution, you can take a look at the Tribune Company’s Windows Azure case study or you can watch our TechEd NA 2010 presentation here:

As promised in the session, you can find the final code built during the session below.  Just remember to update the config files with your own credentials.

On an email thread today, someone was looking for suggestions on how to start a job simultaneously across multiple worker roles running in Windows Azure.  For example, image you have ten worker roles already running and, through the command of an admin or user, you want to “release the hounds!”

Definitely an interesting scenario, and many different ways to approach it.  Initial ideas and thoughts centered around using Windows Azure storage tables or blobs – in fact, Steve Marx quickly threw out some pseudo code highlighting a reasonable way to approach the problem:

   1: while (blob.DownloadText() != “RELEASE THE HOUNDS!”)

   2:     Thread.Sleep(TimeSpan.FromSeconds(1));

   3: // do the actual work

Then to release:

   1: blob.UploadText(“RELEASE THE HOUNDS!”);

You could definitely take this approach and have success.

Of course, to me this scenario screamed multicasting with NetEventRelayBinding.

NetEventRelayBinding supports multiple listeners on the same URI, which means that you can have 1 or 1000 worker roles in Windows Azure all listening to the same URI – this gives you the ability to push out events to all listeners, as any message sent by a client gets distributed to all the listeners.

Clemens Vasters sums NetEventRelayBinding it up nicely on his blog:

The NetEventRelayBinding doesn’t have an exact counterpart in the standard bindings. This binding provides access to the multicast publish/subscribe capability in the Relay. Using this binding, clients act as event publishers and listeners act as subscribers. An event-topic is represented by an agreed-upon name in the naming system. There can be any number of publishers and any number of subscribers that use the respective named rendezvous point in the Relay. Listeners can subscribe independent of whether a publisher currently maintains an open connection and publishers can publish messages irrespective of how many listeners are currently active – including zero. The result is a very easy to use lightweight one-way publish/subscribe event distribution mechanism that doesn’t require any particular setup or management.

So, the architecture might look something like this:

In this scenario, an admin sitting on a laptop can send a message to the Service Bus, which in turn relays the message to all the listeners.  When the worker roles receive the message they will “release the hounds” and process whatever it is they need to process.

Note: this approach is just as valid for listeners that don’t reside in Windows Azure.  For example, if you have an application that is distributed across PCs and you want to send every client a message (without implementing some form of polling) this is the perfect approach.

So, without further ado, here’s the code to release the hounds!

Now, a few comments on the code:

• I wrote this using Visual Studio 2010 RTM. Your mileage may vary.
• Make sure you have the Windows Azure SDK and the Windows Azure AppFabric SDK.
• The first thing you’re going to want to do is search on YOURSERVICENAME and YOURISSUERSECRET and replace with your own values.
• It’s initially configured to run locally.  Just hit F5.
• When you run locally, three things will launch:
  1. The local development fabric, with two worker roles.
  2. A Windows Forms application with a big button (hey, it’s better than a console window!).
  3. A console window that displays traces from all your worker roles.  This is especially useful for getting information from your worker roles once you’ve deployed to Windows Azure.  I’ll blog on this another time.
• When you eventually deploy to Windows Azure, but sure to uncomment the <extensions> and <bindingExtensions> sections in the App.config, as the Windows Azure AppFabric SDK is not installed in Windows Azure, and it won’t understand NetEventRelayBinding.

I personally think this is a pretty neat solution, and can enable a lot of advanced scenarios.  I’d love to hear your feedback and comments.

If you take a look at the official Windows Azure platform website, you’ll see two definitions for the Windows Azure platform AppFabric (hereafter referred to as the Azure AppFabric) prominently called out:

• “… connects cloud services and on-premises applications.”
• “… helps developers connect applications and services in the cloud or on-premises.”

While the purpose of the Azure AppFabric seems clear to me – enable developers to connect applications and services – there are a couple things that generally cause confusion: execution and branding.  I plan to talk about how to use the Azure AppFabric quite a bit in the future, but in this post I want to address the branding.

The Azure AppFabric has been rebranded numerous times.  This isn’t surprising given that it has largely been a community technology preview, but it has lead to some confusion.

So, some brief history …

Note: this is based entirely on my cyber-sleuthing and personal experience.  I’m sure I have gaps and perhaps an inadvertent inaccuracy, so as I get corrected I’ll update.  I didn’t join Microsoft until early 2008, so the early days of the Azure AppFabric precedes my Microsoft employment.

In April 2007, the BizTalk Server team announced that the CTP release of BizTalk Services was live.  They had created an Internet Services Bus (ISB) that allowed developers to create “Internet scale composite applications more rapidly.”  Clemens Vasters described this new ISB in a post.  Later, in July 2007, the BizTalk Server team talked about Hosted Workflows in BizTalk – an exciting extension to the ISB announcement.  Over time, Access Control was added into the mix as well.

Soon, word of Project Zurich started hitting the airways.  Mary-Jo Foley wrote about “’Zurich,’ Microsoft’s elastic cloud” back in July 2008, describing it as an initiative to “extend Microsoft’s .NET application development technologies to the Internet ‘cloud.’” Close, but not quite right.  My first introduction to Project Zurich came while working on a project with RedPrairie on a supply chain proof-of-concept, that ultimately culminated in a Bob Muglia keynote demonstration at PDC 2008 (around 59 minutes).

At the Professional Developers Conference (PDC) 2008 the platform was rebranded .NET Services and included as part of the Azure Services Platform.  You can actually still see some of the .NET Services branding on this BizTalk Service page.  By the fall of 2008, .NET Services had emerged as a mature platform (even though still in CTP) consisting of an Internet Service Bus, an Access Control Service (ACS), and Workflow Service.  In June 2009, the .NET Services team announced that they were pulling the Workflow Service.  As Windows Workflow Foundation in .NET 4.0 evolved, it was clear that most customers wanted Workflow Services to also follow to the .NET 4.0 model (not .NET 3.5), which it was not.  Consequently, .NET Services team pulled workflow and focused on the ISB and ACS.

At PDC 2009, .NET Services went through it’s most recent branding change, and was eventually launched in 2010 as the Windows Azure platform AppFabric.  Of course, this is a really long name, so most people just end up saying Windows Azure AppFabric or just Azure AppFabric. 

The biggest challenge I see today with the name is that, at PDC 2009, we also rebranded “Dublin” and “Velocity” as the Windows Server AppFabric – almost too much name overloading, although there are some good reasons for it that will emerge over time.  To make things clear, I’ll always say either Azure AppFabric or Server AppFabric.

If you really take a look at how this all has evolved, you can start to see how Microsoft’s cloud platform strategy has evolved over the last several years.

So, where does this leave us?

In my opinion, it leaves us with a technology that is a key differentiator in Microsoft’s cloud platform.  I’m not just saying this – I really believe it, or I wouldn’t be moving my family up to Redmond so that I can focus on it.

In closing, let’s be clear on two things – in Azure AppFabric, there’s both a Service Bus and Access Control Service.

The Service Bus is an Internet-scale enterprise service bus that makes it easy to connect applications over the Internet. Services that register on the Service Bus can easily be discovered and accessed across any network topology.

The Access Controls Service helps you build federated authorization into your applications and services, without the complicated programming that is normally required to secure applications that extend beyond organizational boundaries.

Okay, now that I’ve spent a little time  covering some history and the past, expect to see a major focus on what you can do today – and lots of code and examples.

Hope this helps.