Here are several simple tips if you are planning to leverage Windows Azure for your applications:

  • Application Settings - Don't use the web.config to store application settings, specifically environmental application settings. For example: SQL Connection strings, should be stored in the
    Service Configuration not the web.config. The problem is since the web.config is part of the deployment package, you will either have to redeploy a new package or Remote Desktop into all of the instances to make a change.  Think about how you move builds across environments: Development --> Test --> UAT --> Production

            Common Web Config Settings that should be moved to the Service Config

      • SQL Connection Strings
        • Including Entity Framework
      • AppFabric Caching
        • Yes – Azure lets you copy the web.config settings for caching, but caching it typically going to be environment based so move it to the Service Configuration.
  • ASP.NET Membership Provider 
  • Deployment – Leverage the VIP Switch functionality, don’t just deploy to the production node. Deploy to the staging node, smoke test, then do a VIP Switch. If something isn’t right, this gives you a great way to rollback. Yes – you have to pay for the staging compute instances. There are some cases where you can’t leverage this feature, such as a change to a WCF contract, where WCF client needs to be updated as well. Plan your deployment strategy for this scenario.
  • Scale Out, Not Up – Too many times it’s easy to say I’ll just use the biggest VM size available.  Your memory and CPU footprint should account for load, but you can spread that load across multiple instances.  IE: 2 x Large Instances or 4 x Medium or 8x Small instance? In a lot of cases – you’d be better off with 4x Medium or 8x Small than 2x Large and it’s the same cost.  
  • Performance and Diagnostic Data – Collect this data, it makes troubleshooting alot easier for you. At a minimum capture the crash dumps, so they will be stored Blob storage – Ideally you have some kind of Monitoring solution deployed on Premise – like SCOM with the Windows Azure management pack or another third party solution.
  • Don’t enable Profiling or Remote Desktop for production instances – Profiling will be a performance hit in production, Remote Desktop exposes another potential attack surface. Leverage Diagnostic and Performance data to troubleshoot issues.
  • Don’t leverage CTP features in Production – CTP features are great, but don’t have SLAs. (Once in Beta features typically have SLAs). IE: Traffic Manager is a great feature, but while it is in CTP, it is extremely risky as a single point of failure with no guaranteed SLA.   

 

Have some thoughts? Share them with me: midunn@microsoft.com