In the last post, we added a Windows Azure deployment project to the ASP.NET Web API project we created previously. In this post, we’re going to go ahead and publish our project on Windows Azure.
To get this started, we right-click the deployment project in Visual Studio’s Solution Explorer and select “Publish”…
… which brings up the “Windows Azure Publish Sign In” dialog.
At this stage, you probably don’t yet have an Azure subscription. Whether you do or not, click the link on the dialog to proceed:
If you don’t yet have a subscription, it’s at this point that you’ll be prompted with the options available to you. I personally signed up for a 3-month trial subscription, for which – by logging in – I can then download credentials to my local system.
I’m then able to go back to my Publish dialog and import these credentials:
Now we’re ready to really start publishing to Azure. Our next step is to choose a name (which will be used to form the URL *.cloudapp.net that you’ll use to access your web-site and/or -service).
You also get to choose your hosting location – in this case I’m going to deploy to Western Europe… partly because it’s the closest location to me, personally, but also because the Eastern US data center (which would have split the difference nicely between here and the US) doesn’t yet have a caching service available (something we’ll look at in the next post).
For the sake of this example, we’re going to break the cardinal rule of web development and push our deployment straight into production (rather than publishing to staging, testing it and then promoting it from there).
We can also set some credentials to allow us Remote Desktop access to the instances we create, helping us troubleshoot any tricky issues:
And then it should be a simple matter of hitting Publish…
… and sitting back and waiting for VS to deploy the project to Azure:
In the meantime, we can shoot across to the very-handy Windows Azure Management Portal, by logging in at http://windows.azure.com:
This provides access to our Azure subscriptions and services:
From this page, it’s straightforward to perform various tasks such as checking usage and billing, promoting staging to production, and stopping or deleting running services.
Once the project is live, we can access the main web-page (which I went ahead and customized to provide some information about our web-services):
And, of course, the web-services are available below this site, e.g.:
http://apollonian.cloudapp.net/api/circles/5/3
http://apollonian.cloudapp.net/api/spheres/5/3
Now that this site is live, it remains for us to adjust our AutoCAD-specific code to consume the data from the cloud rather than the local service. Once we’ve done that, I’ll post the project for the server deployment as well as our local AutoCAD-based client.
But before that, in the next post we’re going to look at some decisions related to the economics of cloud hosting, particularly around adding a caching service (one of Azure’s PaaS features) and reducing the size of our cloud-hosted VM instances.
Update
While preparing the next post, I decided to adjust the JSON format slightly, shortening “Radius” and “Curvature” to “R” and “C”, respectively. This reduces the data transferred by a reasonable amount (about 8% for spheres and 14% for circles), and I decided to go ahead and do it now, before we create more dependencies on the service and end up with a versioning issue.
