Having built our local ASP.NET Web API project and consumed its data inside AutoCAD, we’re now ready to deploy our web-service to the cloud. In this first part, we’ll look at some background information on Azure, in particular, and then get ready for the publishing process, which we’ll complete in the next post in the series.
Choosing a provider
As is obvious from the title, for these posts we’re going to use Windows Azure. Alternatives such as Amazon Web Services (AWS) provide IaaS (Infrastructure-as-a-Service) capabilities related to hosting ASP.NET – you basically get the ability to deploy Windows Servers in the cloud you can connect to and host your application on – but what’s interesting about Windows Azure is a tighter integration, something known as PaaS (Platform-as-a-Service). If you’re interested in understanding the difference between IaaS, PaaS and SaaS, then this should help.
On the subject of hosting providers… I found this debate to be very interesting, with proponents of both Azure and AWS fighting their respective corners. I suspect that for this audience – as it was the case for me – the arguments in favour of Azure tend to be more compelling, as we’re working closely with the .NET stack. On the other hand, Autodesk is currently a significant user of AWS. Over time I can imagine that the benefits of tighter integration – co-location of compute and storage resources being of particular importance – might lead to our developers and customers choosing to host their own services alongside ours, but we’re a long way from this being a significant issue, and I expect there to continue to be changes in the cloud-hosting landscape over the coming few years.
To get started with Azure, I recommend a few background resources. For those of you somewhat familiar with ASP.NET, this set of articles will probably be of use. I also sat through this introductory jump-start video, but didn’t make it to its brethren – it was mostly extolling the benefits of cloud computing in general.
If you’re going to watch one video on Windows Azure, this is it. Scott Guthrie does a fantastic job of keeping it simple and to the point: he creates an ASP.NET MVC app and deploys it on Azure in around 4 minutes.
We’re basically going to follow the same process as Scott did – which is a big reason for using VS2010 to build our ASP.NET MVC 4 project, as there currently isn’t a Windows Azure SDK for .NET that integrates with VS11 – but we’ll also be adding a few steps of our own to help us further down the line.
Before we look at getting our project deployed on Windows Azure, a quick disclaimer: I’m largely learning this as I go. While I’ve used IIS and ASP, back in the day, I haven’t recently used ASP.NET, and working with the cloud is altogether new for me. But that should also encourage people that you don’t need to know the ins and outs of AWS or Azure to get started with this stuff – it’s surprisingly easy.
Now for those steps that will save us some headaches, later on:
In the main Web.config file in the ApollonianPackingWebApi project, inside the <system.web> element, we’re going to add the following setting:
This allows any web-service errors to be passed through to the browser on the client, rather than us needing to open a Remote Desktop session on the server in order to get the error locally via a browser there.
This change helped me to understand the reason the application didn’t work when initially deployed to Azure: I needed to make sure F# was available to the project. While we clearly have a reference to FSharp.Core.dll in our F# library, we also need a reference to it – with CopyLocal set to True – in our primary C# project. A tricky one to track down, but I can see why it needs to happen.
Getting started with Azure
This should provide you with the ability to – just as Scott did in the video – right-click the main C# project in our solution and select “Add Windows Azure Deployment Project”. It’s that easy to get the deployment project in place. :-)
Via this project, it’s possible to choose the number and size of the instances available to your application’s load-balancer:
Now that we’ve prepared our deployment settings, in the next post we’ll go ahead and publish the project to Windows Azure.