Comments

@Glenn and @redsquare

Thank you, guys, for the kind words. Happy to see such an interest in our journey.

Yes, we'll try to address the topics you've requested. Data migration is actuall the theme of our V2 pseudo-production release. We'll be reporting on that experience soon.

Thank you for watching. Here are several useful resources on Wasabi:

• http://aka.ms/autoscaling
• The Developer's Guide
• Sample app used in the demo (source, installation instructions)
• Hands-on labs (include walkthroughs to customize Wasabi)
• Other resources

If you find Wasabi useful or if you have improvement suggestions, please send us feedback.

V1 post-production release has shipped:

• The sample app is live.
• The code can be found on GitHub.
• The latest draft of the docs is ready for your review.

See the backlog and track our progress on getting to V2 is here.

Since several people pinged me with the questions how to find the Tailspin Management console sample app I was using in the demo of Wasabi, here're some direct links:

Grab the self-extractable zip.

Also, follow the steps from the installation guide to get it running.

Great episode, nice extreme tripling!

In addition to the MSDN reference documentation on the Transient Fault Handling Application Block, check out Chapters 6 and 7 of the Building Elastic and Resilient Cloud Applications guide from the patterns & practices, the team that built the block.

@Mithya,

Sorry, I didn't get notifications about your questions and only saw them today.

1) Yes, in the final version this attribute is called "alias".

2) You need to make the management ceriticate available to the role hosting Wasabi. This means deploying it through the Windows Azure portal and adding it to the list of certificates for the role. Then you also have to specify that certificate's thumbprint for the subscription element in the services store.

3) You can have Wasabi autoscale itself (the block is prepared to deal with multiple instances of the autoscaler - we are using an execution lease), but that's not necessarily something that you would probably want to do. The technical reason is that it's better for an autoscaler to be running continuously in an instance. If you modify your app and decide to redeploy, the autoscaler will need to be interrupted and redeployed as well. Thus, it's better to run in its own role - an extra small worker or web role would do.

The SDK for notifications and autoscaling ScottGu mentions at 00:40:35 is the Integration Pack for Windows Azure from the Microsoft patterns & practices team.

Note, Microsoft Enterprise Library application blocks are now available via NuGet.

The Validation Application Block is now available via NuGet:

http://nuget.org/List/Packages/EnterpriseLibrary.Validation

The Validation Application Block is now available via NuGet:

http://nuget.org/List/Packages/EnterpriseLibrary.Validation