The good

I’ve been running several web sites in Azure for about a month now. Most are simple information pages with a small number of hits. A couple of WordPress blogs and one with higher traffic (tellmon).

Migrating existing databases

The move to Azure was in most cases quite easy. For Microsoft SQL you can use the SQL Database Migration Wizard which does the job of moving a database to and from Azure quite well.

For mySQL you can use a the normal mysql dump method. One note however on mySQL. Microsoft does not host mySQL itself in Azure but relies on a third party company called clearDB. Once you setup any website in Azure that requires mySQL you will automatically get a free account at clearDB and your database is created with them. This is quite nice, but the problem for me was that firstly you only get one single database which is limited to 20 MB of size. Want more databases or larger database you’ll need to upgrade your free account and start paying a subscription to clearDB as well.

Migrating files (web and content)

With Azure you can use FTP to move your existing web files and content quite easily. You can also use WebMatrix to edit/upload.

Web jobs

A lot of web sites I’ve been working with has one or more Windows Services that does miscellaneous tasks either on a schedule or continuously. Azure web sites has support for something called web jobs. A web job is a small zip package you upload to Azure that contains a batch file, a power shell script or an executable file (.exe) together with any config file or other files (like DLL’s) you need. Upload the package to Azure and either set a schedule or make it run continuously. Azure will restart your application if it stops and is set as continuously running.

I’ve changed my windows services to simple console applications with a while (true) loop with a small Thread.Sleep to throttle CPU. Works a treat.  Another bonus is that Azure will capture any messages you write to console out and you can view the log from the Azure portal.

One thing you need to remember is that WebJobs scale out to multiple instances together with the web sites if you have Azure scaling turned on. So make sure you have some way of synchronizing the jobs so that you don’t do what ever your doing more than once.

Email

Most of my web sites need to send email from time to time. Understandably Azure does not supply you with a SMTP server. What I recommend is to sign up for a free account at sendgrid.net. You’ll get 20.000 free emails a month which is far more than I require. Specify username and password for the smtp server and send away.

The bad

The world is not perfect, neither in Azure. So far I’ve come across some issues that show how running in the cloud differs from running on premise.

SQL transient errors

Every now and again SQL errors pop up in the error logs. They most often is one of the following:

System.Data.SqlClient.SqlException: A transport-level error has occurred when receiving results from the server.
The semaphore timeout period has expired.

System.Data.SqlClient.SqlException: Timeout expired.
The timeout period elapsed prior to completion of the operation or the server is not responding.

System.Data.SqlClient.SqlException: A connection was successfully established with the server,
but then an error occurred during the pre-login handshake.

Turns out I’m not the first to experience these and there is a whole lot of information about this on the web. Microsoft has written a blog post called Troubleshooting in Windows Azure that describe these issues and how to solve them.

Applications should handle error conditions gracefully if they can. This is even more important given the distributed nature of Windows Azure. Effective troubleshooting begins with a good transient-failure handling design. Transient errors are one of the main areas in which cloud applications fail to behave as expected due to transient error conditions inherent to internet applications.

If you are using Microsoft Enterprise Library it has support for transient fault handling from version 6. You can specify a retry strategy that will make EntLib data calls retry a set number of tries within a given timespan before giving up.

If you are using Linq2Sql like I often do for small projects you can use something like this to leverage the EntLib retry strategy.

    public static T ExecuteWithRetry<T>(Func<T> action)
    {
        var retryStrategy = new Incremental(5, TimeSpan.FromSeconds(1), TimeSpan.FromSeconds(2));

        // Define your retry policy using the retry strategy and the Windows Azure storage
        // transient fault detection strategy.
        var retryPolicy = new RetryPolicy<SqlDatabaseTransientErrorDetectionStrategy>(retryStrategy);
   
        // Receive notifications about retries.
        retryPolicy.Retrying += (sender, args) =>
        {
            // Log details of the retry.
            var msg = String.Format("Retry - Count:{0}, Delay:{1}, Exception:{2}",
                args.CurrentRetryCount, args.Delay, args.LastException);
            
            Logger.Log.Warn(msg);
        };

        try
        {
            return retryPolicy.ExecuteAction<T>(action);
        }
        catch (Exception ex)
        {
            Logger.Log.Error(ex);
            throw;
        }
    }

Then to use the retry policy:

using (var dc = new NorthwindDataContext())
{
     Employee e1 = ExecuteWithRetry<Employee>(() =>
         (from x in dc.Employees
          where x.LastName == "King"
          select x).First());
}

Sources:
http://stackoverflow.com/questions/12282427/transient-fault-handling-with-sql-azure-using-entity-framework
http://www.windowsazure.com/en-us/documentation/articles/best-practices-troubleshooting/
http://peterkellner.net/2011/01/21/sqlazure-connection-retry-problem-using-best-practices/