This topic, Best Practices for Performance in Windows Azure Applications, appeared with the recent Windows Azure Spring 2012 refresh. It's focussed on design issues that affect performance. A related topic that was published at the same time, Troubleshooting in Windows Azure, discusses the run-time side of things.

A lot of my topic deals with Windows Azure SQL Database (the database previously known as "SQL Azure"), and especially Federations. In that light, I want to call out a great video of a presentation on Federations by Cihan Biyikoglu at the 2012 US Tech Ed conference in Orlando. Cihan's blog is also a great source of information about Federations.

Federations illustrates an interesting paradox concerning Windows Azure performance. Individual operations in Windows Azure are often slower than the corresponding operations on an in-premises server, for a number of reasons, including latency, and automated fail-over (nodes, including persistent data, are generally replicated a number of times: this takes time, and if a node goes down, and fails over to a secondary node, this also takes time). But this can be more than compensated for by the scaling out of resources, and Federations is an outstanding example of this. The result can be a massive parallelization of work, which can greatly increase performance.

While database scale-out is the commonest example, the same techniques can be applied to other Windows Azure resources.

Another important aspect of Windows Azure performance is the need to test your architectural design by early-on creating a proof of concept application. Windows Azure contains a lot of "moving parts", and it is in a state of rapid evolution and development. Your exact combination of parts has not necessarily been tested by Microsoft (a Computer Science class in Combinatorics will clarify why this is (hint: look at the factorial function...)), and you should validate your architecture early in the development cycle, rather than trying to fix perf problems when about to deploy your application, or even worse, after it's in production (this has of course never happened to me :-)).

Finally, Eric Lippert has a video where he talks briefly about performance as an engineering discipline. Actually most of the video is about C#'s new features and also about Roslyn... But his remarks about performance are worth hearing.

I want to give a shout-out to another topic in the Best Practices series, that was published along with the Performance and Trouble-Shooting ones: Windows Azure Security Guidance.

Finally, as always I welcome feedback! Windows Azure performance is a vast area, and there are undoubtedly areas that could use more detail. And it is a continuously evolving platform, so new issues are likely to appear.