Migrating a Blog to Windows Azure Web Sites

For many years, I’ve hosted my blog on Orcsweb.  I moved there about 5 years ago or so, after outgrowing webhost4life.  Orcsweb is a huge supporter of the community and has offered free hosting to MVPs and MSFTies, so it seemed like a no brainer to go to a first class host at no charge.  Orcs is also local (Charlotte, NC) and I know many of the great folks there.  But, the time has come to move my blog to Windows Azure Web Sites (WAWS).  (This switch, of course, should be transparent.) This isn’t meant as disappointment with Orcs, but lately I’ve noticed my site throwing a lot of 503 Service Unavailable messages.  Orcs was always incredibly prompt at fixing the issue (I was told the app pool was stopping for some reason), but I always felt guilty pinging support.  Frankly, my blog is too important to me, so it seemed time to take responsibility for it. WAWS allows you to host 10 sites for free, but if you want custom domain names, you need to upgrade to the shared plan at $10/mo.  This is a great deal for what you get, and offers great scalability options when needed.   My colleague, Andrew, recently had a great post on WebGL in IE11, and he got quite a bit of traction from that post as you can see from the green spike in his site traffic: This is where the cloud shines: if you need multiple instances for redundancy/uptime, or simply to scale when needed, you can do it with a click of a button, or even automatically.  Migrating the blog was a piece of cake.  You’ve got a couple of options with WAWS: you can either create a site from a gallery of images (like BlogEngine.net, Wordpress, et al.), as shown in red below, or simply create an empty website to which you can deploy your own code (shown in green). Although I use BlogEngine, I already have all the code locally so instead of creating a site from the gallery, I created an empty website using Quick Create and then published the code.  If you’re starting a new blog, it’s certainly faster to select a blog of your choice from the gallery and you’re up and running in a minute. After clicking Quick Create, you just need to enter a name (your site will be *.azurewebsites.net) and a region for your app to live: Once your site is created (this should only take a few seconds) we’ll see something like this: Since the site I’m going to be pushing up has already been created, all I need right now is the publish profile.  You can certainly publish from source control, but for the time being let’s assume we have a website in a directory we want to publish.  I saved that file in a convenient place. There are two quick ways to bring up the Publish dialog in VS, either through Build – Publish Web Site, or right click on project and select Publish Web Site.  The next step is to locate the publish profile: Once imported, the connection details should be filled and the connection validated: The first deploy can obviously take a little while depending on the size of the solution, and you can see what’s going on in the output window:   The website should launch automatically when done: Easy, huh?  On the configure page, we can add our custom DNS names: For example, on my blog, I’ve got a few domains that I’ve added: When first trying to add a domain name, you may see something like this:   What the message is saying is that before the website will respond to that domain, we need to prove that we, in fact, own the domain name.  We can go about this two ways, either by creating an A record or CNAME.  A CNAME is technically the most appropriate, however, it’s often insufficient because many people try browse to a root domain, such as “http://structuretoobig.com” instead of “http://www.structuretoobig.com” or “http://blog.structuretoobig.com”.  In these cases, you need an A record, but that’s another topic entirely.  Here’s an example of the somedomain CNAME for my blog on my DNS registrar (this is not something you do on Windows Azure – this is to be done by your domain registrar): Once done, you might have to wait a short while for those changes to propagate the DNS cache.  (1 hour TTL is pretty low – typically you’d bump that a bit higher but when doing migrations, it’s best to keep this low so any changes you make are more immediate.) Once done and after waiting about 2 minutes, the domain is verified in the Windows Azure DNS page: In this case I created a CNAME over to this blog, so if we try it, here we are!  How cool is that … I’m writing about what’s on the screen.  Hmmm … this is kind of strange… So what if we wanted to create something from the gallery, instead?  For example, setting up a new BlogEngine site instead of downloading the code and publishing it.  If we clicked on “From Gallery” when first creating our web site, we’ll see something like this: The advantage of this approach is that it copies all of the files for you into your site.  You still have total access to those files, but this is perfect for new blogs and you know you’ll have a working configuration right away.  On the dashboard of the page, you’ll notice you have all the links you need to connect to your site, download a publish profile, set up source control, etc.  You can also configure an FTP password.  If we open this in FileZilla, we can see it has the same directory structure as our code, as the gallery image happens to be using the same version.  If we wanted to, we could pull down this code and redeploy it as necessary with any changes: The bottom line:  this post took a lot longer to write that it did for me to migrate my entire blog.  It’s easy to get going, and scalable to exactly what you need.  If you’re pulling in advertising or have critical uptime needs, you can have 2 or more instances for extra reliability and load capacity, or simply when needed.  If you don’t need a custom DNS name, the free tier gives you some great benefits and liberal usage.  Want to get started with Azure?  Here’s a link to a free trial, and of course, the free stuff remains free after the trial.

Building for Cost Part 2

In the last post, we looked at ways to separate content using different pieces of Windows Azure for the benefit of creating a more cost-effective solution using Windows Azure Web Sites (WAWS) and Windows Azure Storage for storing images and other binary/static files.   Although we’re looking at this just for cost efficacy, frankly that approach just makes sense from an availability and performance aspect, too. Another fantastic service is Windows Azure Mobile Services (WAMS), but unsurprisingly, it has its own cost structure outlined here: Similar to WAWS, you can have up to 10 services for free.  But, the way these services are metered are completely different, and it might change the way we build an application. First, let’s discuss the free tier.  The current metering, limited to 100 devices, means that using an authenticated client (that is, any client using the SDK) renders this tier useless for anything other than testing.  For example, here’s my low-use application: We’re not really incurring many API calls, but our device count is pretty high.  When I designed the app, these meters weren’t in place, but if they were I’d design the app differently.  Hopefully, we’ll see some changes in this as the current plan is a bit inflexible.  What this means, though, is that for my app to keep working, I need to upgrade to the $25/mo plan.  By making a few specific decisions early on, we can build the application to take advantage of both WAMS and WAWS.  For example, in WAMS, custom API calls can be made and invoked over HTTP.  I leveraged this in Brew Finder for several items: brewerydb’s callback, live tiles, and web services that don’t require authentication.  Because these calls are made from “non-devices,” the usage looks like so: I’m not exactly sure why this is showing zero bytes out (it could be for the time duration shown in this graph, it’s not significant enough), but the 0 devices and API calls count is accurate.  We also have the option to deploy another WAWS with node.js, if we’d like to stick with server-side javascript.  Remember, the database that is used can certainly be shared by any number of WAWS, WAMS, etc.  So, if you need to curb back on your API calls, offload that work to a WAWS instead where the calls are not metered if you don’t need WAMS specific features (like authentication).  Summary The biggest challenge in developing a cloud backed app is guesstimating the usage.  The first step, though, is to understand what is being measured – API calls, devices, bandwidth, CPU time, etc.   Keeping the application architecture spread across multiple services for different functions (authentication, live tiles, etc.) is a great way to make the application flexible so you can take advantage of the way each service is metered, bearing in mind this is always subject to change. Having trouble estimating or getting started?  Drop me a note or leave a comment on this post.  I’d be happy to help you work through some ideas. 

My Apps

Dark Skies Astrophotography Journal Vol 1 Explore The Moon
Mars Explorer Moons of Jupiter Messier Object Explorer
Brew Finder Earthquake Explorer Venus Explorer  

My Worldmap

Month List