CarTrackr on Windows Azure - Part 5 - Deploying in the cloud

This post is part 5 (and the final part) of my series on Windows Azure, in which I'll try to convert my ASP.NET MVC application into a cloud application. The current post is all about deploying CarTrackr in the cloud after all modifications done in previous posts.

Other parts:

• Part 1 - Introduction, containg links to all other parts
• Part 2 - Cloud-enabling CarTrackr
• Part 3 - Data storage
• Part 4 - Membership and authentication
• Part 5 - Deploying in the cloud (current part)

Deploying CarTrackr on Azure

Deploying CarTrackr is done using the Azure developer portal. I'm creating a hosted service named "CarTrackr", which will host the cloud version of CarTrackr. I'm also creating a second storage acocunt project, used for TableStorage of all data in CarTrackr.

To create a deployment package, the documentation states to right-click the Azure project in the CarTrackr solution, selecting "Publish...". I really hoped this would be easy. Unfortunately, this was some sort of a PITA... Great to see an Exception in the output window. Fortunately, someone had the same issue: Packaging Azure project manually when the 'Publish' action fails. The Exception seems to be thrown because the CarTrackr project is too big for the packaging system. *sigh* Starting an Azure SDK command-line and invoking the cspack.exe seemed to do the trick.

Anyway, on to uploading the generated package to Azure: the package, service configuration and deployment name should be given, after which an upload takes place.

Time to run! After browsing to http://cartrackr.cloudapp.net, I'm expecting to see CarTrackr!

But no, Error 403 - Forbidden - Access is denied... What is wrong? My quest to host CarTrackr on Azure seems to be full of obstacles...

Deploying again!

After some hours of re-packing, re-building, re-deploying and starting to get annoyed, the solution was to change my call to cspack.exe... Not only the /bin folder should be packaged, but also all other content. My bad! Invoking C:\Users\Maarten\Desktop\CarTrackr>cspack "./CarTrackr_Azure/ServiceDefinition.csdef" /out:"./CarTrackr_Azure/CarTrackr_Azure.cspkg" /role:"Web;./CarTrackr"  was the right thing to do.

A deployment later, CarTrackr seemed to work smoothly!

And again...

Yes, again. I wrote this blog post about a week ago and decided to add Google Analytics in the live version of CarTrackr. While deploying, I decided to upload the latest version to the staging environment, and swap it with the production environment... Bad idea :-) Deployment totally killed my data storage (it seemed) and was throwing strange errors on the production URL.

Some hours later (that is: 2 hours of build, deploy, check, ..., a night sleep and some more build, deploy, check, ...), I had the strange idea of putting my production ServiceConfiguration data in the package itself. This should not be necessary, but you never know. And it is what I did with the first working production deployment. And yes, this indeed seemed to be the solution!

Check it out!

Checkout http://cartrackr.cloudapp.net for the live version. No need to sign up, only to sign in. Note: when entering a refuelling, enter the date in US English format... 

It is likely that you are going to download and play with my source code. When doing that, check out the TableStorage membership, role and session providers in the Azure SDK, which you can use in CarTrackr if you want. More on this can be found on http://blogs.msdn.com/jnak/archive/2008/11/10/asp-net-mvc-on-windows-azure-with-providers.aspx.

Looking for the Azure CarTrackr sources? CarTrackr_Azure.zip (654.98 kb)
Looking for the original CarTrackr sources? Checkout CodePlex.

Conclusion on Azure

It took me quite some hours to actually convert an existing application into something that was ready for deployment on Azure. The toughest parts were rewriting my repository code for TableStorage and getting the CarTrackr package deployed. With what I know know, I think writing an Azure application should not be more difficult than writing any other web application. The SDK provides everything you need, remember to check the samples directory for some useful portions of code.

I do have some notes though, which I hope will be used for future CTP's of Azure...

• Your application is running fine on the development fabric?
  There's no 100% guarantee that the Azure web fabric will serve your application correctly when it runs smoothly on the development fabric. Just deploy and pray :-)
• Viewing log files from the web fabric from the Azure Services Developer Portal would be a real time saver!
  Currently, you can copy the server logs to blob storage and then fetch the data from there, but a handy web-tool would really save some time when something goes wrong after deployment. Same story goes for TableStorage: it would be useful to have an interface to look at your data.
• Packaging? Great, but... what if I only wanted to update one file in the application?
  I've uploaded my package about 10 times during deployment testing, which required 10 times... the full package size in bandwith! And all I wanted to do was modifying web.config...

Sidenote: funny to see that they are using OPC (Open Packaging Convention) for creating deployment packages. It shows how easy it is to create a custom file format with OPC, just like Julien Chable did for a photo viewer.

Overall, Microsoft is doing a good job with Azure. The platform itself seems reliable and stable, the concept is good. Perhaps they should consider selling the hosting platform itself to hosting firms around the globe, setting a standard for hosting platforms. Think of switching your hosting provider by simply uploading the package to another company's web fabric and modifying some simple configuration entries. Another idea: why not allow the packages developed for Azure to be deployed on any IIS server farm? 

This is an imported post. It was imported from my old blog using an automated tool and may contain formatting errors and/or broken images.