Windows Azure Best Practices

I was on Twitter and suddenly some remember that it would be interesting to write some Best Practices about using Windows Azure. Here are some of the ones I remembered:

1. Get out of the way when you can. Send client directly to blob storage for static content
2. Use Shared Access Signatures to provide direct access to ACLed content. Can be time-bound and revoked on demand. Also important will be using a Shared Access Policy in order to remove information like end date from url
3. Serve public blobs from the edge with the Windows Azure CDN. You have fewer hops, and be closer to the customer.
4. If you’re using #CDN don’t forget to Manage the Content Expiration. The Default is 72 hours
5. If you’re using CDN use versioned urls to allow immediate refresh. Really important to avoid caching problems
6. Cache hot data in memory to avoid slower data-tier access. Ex. Session State, immutable reference data. Using the Caching ties will help you reduce latency and in some cases also costs
7. Consider using more smaller compute instances instead of few large one. Most times you’ll get better performance
8. Partition Data based on the indexing needs. Use #SQLAzure for highly indexed data, and #Storage for the rest. Really consider doing Hybrid Partitioning
9. Shard your #SQLAzure data across databases to increase the workload.
10. Don’t forget to do the basic performance tuning to applications. Measure, optimize & create a baseline for performance
11. Don’t forget to enable compression for additional dynamic content types in Web Apps
12. You can’t update Apps with a different number of endpoints, so prepare for that upfront, leave some backdoors opened
13. In #Azure #AppFabric Caching Prefer to cache more smaller objects then few larger ones, increases your performance
14. Consider VMRole only when you need something installed that takes long time or is a non-automated install
15. Use Startup Tasks preferably in background unless you need a specific order in their launch
16. Use Asynchronous Work Pattern and Queues instead of using a Synchronous approach on your Roles
17. For devices don’t connect directly to #SQLAzure, proxy those in your #Azure Compute (of course #SOA approach)
18. If you use Startup Tasks don’t forget to log everything. Ex. command >> %~dp0log.txt 2>> %~dp0err.txt
19. Don’t forget to use “/y” in everything to avoid confirmation messages. Ex. “copy /y source destination”
20. For Startup Tasks use local storage since it’s a guaranteed space, and if there’s not enough space it won’t run.
21. If you need to run a startup task that needs the IIS pool to exist, then you should use OnStart() in elevated Role – This isn’t a problem since running a Role in Elevated mode doesn’t affect how the Web Application will run on IIS
22. Process that needs to be monitored you should use a ProgramEntryPoint or NetFxEntryPoint instead of Startup Tasks
23. Define NetworkTrafficRules in order to better protected internal access to your roles
24. If you’re using Traffic Manager build a AppHealth page Monitor that checks if everything is OK in your Application
25. When using Table Storage use the SaveChangesOptions.Batch to improve performance and save transactions
26. Choosing your VMSize is important, choose accordingly to your Speed, Memory, IO and Network needs.
27. Use Retry Logic for #SQLAzure connection and for #AppFabric Service Bus, Cache and Storage. Use Transient Fault Handling Framework for SQL Azure, Windows Azure Storage, Windows Azure AppFabric Service Bus and Cache.
28. Don’t use owner for #AppFabric Service Bus. Create your own login and provide them the appropriate permissions. Check this post by Neil Mackenzie.
29. Don’t use the #SQLAzure login that you created on the Management Portal in the connection String. Create your own. This is because you need to work in the least privileges and you don’t want to use the SA for that.
30. When using Queues instead of using GetMessage use GetMessages(count), this will help you save transactions and improve performance of your solution
31. If you’re using Workers that are Queue based (Pooling Mechanism), use a back off mechanism when no messages are found in the queue. This will help reduce the number of transactions that are done and improve your solution performance
32. If you’re using Workers that are Queue based (Pooling Mechanism), you should consider using notifications to resume the back off mechanism. #AppFabric Service Bus will be perfect for this, but don’t forget to do the cost calculation to your scenario.
33. Perform your Application Scaling process considering all options, Scale Up, Out and Down, don’t forget Down.

Last Updated 2011-10-21.