Also see updated demos from //Build. They show how complex logging scenarios can be implemented just with a few lines of code using the power of SLAB and Rx.
Principal Program Manager at Microsoft patterns & practices
Great post, Tim. While I've read Dr.Cook's essay some time ago, your post inspired me to get a refresher plus look a bit deeper and do my own write-up: http://blogs.msdn.com/agile/archive/2012/07/03/thinking-about-complex-systems-and-cloud-availability.aspx
@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:
- 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.
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.
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.