For reasons I don't completely understand, I'm not allowed to call the following advice "Best Practices" - apparently there is some liability or something there. So let's say these are "really good ideas" for developing applications for Windows Azure. (Did you see how I worked it into the title anyway so the search engines find it? Always thinking. :) )
And of course these are by no means comprehensive - just a few notes I've made as I've been involved with projects. So here they are, in no particular order:
It may sound pedantic, but it's just true. You need to learn how the platform works. The most issues I run into are things that are documented - most of the time very clearly.
- Follow standard best practices for your language
Windows Azure code does have some differences, but in large part it's just code. If you write Java to run on Azure, write good Java. Learn the best practices for your codeset and apply those - it will not only make your code faster and less error-prone, it will be cheaper to run.
- Keep a backup of your deployments
Things happen. Make sure you have your latest deployment checked into source code. If someone were to perhaps stop paying the bill and the Role is deleted, Microsoft does not have a secret backup of your application. Do not ask me how I know this.
- Batch up calls - fewer calls are usually more efficient (and cheaper) than lots of smaller calls.
This is typical for distributed computing environments - include the retry logic tip as well to ensure the call is successful.
- Use Cache and max out the instance wherever you can - you're paying for it, use it!
In a distributed computing environment, you may have a lag in time between operations. Make your code less brittle to failures for a given call, and ensure that you include retry logic.
This article is a must-read.
Microsoft keeps three copies of your data at all times in a datacenter, and backs up those three copies to another for safety. But that's at the latest moment - if you need point-in-time restore, make sure you code that into your architecture.
Affinity groups are a way of keeping your data and code together. This is usually a great idea from a performance standpoint, although there are applications that can break this rule for centralization or seldom-accessed data.
- Have a lights-out strategy
Anything that a human makes can fail. That includes entire datacenters, routers, the Internet. So make sure you know what to do if everything is unavailable. Perhaps that's just a notification system, a full fallback to an on-premises system, something. But plan.