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.

Taking your Apps to Market

I’ve written a lot of apps (and have used a lot of apps) so one thing I’m always on the lookout for is what is working when it comes to top apps – getting users, feedback, and ultimately monetizing your apps.  The market is always changing and the trends are different in different app categories, and the key seems to be able to adapt quickly. Pricing and Making Money Games are completely different than productivity apps, which are entirely different than entertainment apps, just to name a few broad categories.  In gaming, an upfront purchase is certainly the tried and true method, but as the market has saturated with $0.99 games, the most successful models have shifted to in-app purchases (IAPs) that extend the value of a free game.   These IAPs can be either for additional game content or levels, or for in-game items that enhance the value of playing the game. There are exceptions.  Dan Russell-Pinson, the developer of the hugely popular Stack the States game available on iOS (often in the top 100 of top grossing apps) and Windows Phone, has discussed the monetization of kids games extensively in the Charlotte Game Meetup group.   (If you’re reasonably to the Charlotte, NC area, you really should make it out to this meetup!  Some app devs are amateurs, some are seasoned professionals!)  The challenge with educational and children’s games, according to Dan, is that most institutions (and, in many cases, parental controls) prevent in-app purchases, so to be successful, the purchasing has to be simple/upfront.  Other games have more freedom.  John O’Neill, founder and chief wizard at Sparkplug Games, has discussed this at length at a number of the Raleigh-area meetups.  Effectively testing your app and gathering initial feedback by micro-launching an app can be a useful way to test a small market segment before going worldwide. When it comes to pricing, however, starting at a high price point (within reason, of course, which is dictated by the current market) is usually the best approach.  Many apps are put on sale at regular intervals, and if you stick with the lowest possible price point you lock yourself out of promotion opportunities.  Besides, you can always lower the price of an app.  Raising it – while technically possible – is seldom helpful. Advertising Placing ads in apps is a great way to bring in revenue, as Kevin Ashley discusses in this post.  The key to make advertising successful, though, is that you need lots of users using your app for long periods of time.  If users are in and out of your app, the amount of revenue your app will bring in will be disappointing. For Windows apps, check out the Microsoft pubCenter.  An SDK is available that makes it easy to plug into Windows 8 and Phone applications.  Publishing While it’s a good idea to consider how you can make money with your apps, it shouldn’t be the main focus.  The primary focus should be on creating a compelling application – and if that’s successful, the money will follow. At our events we often rush the publishing process -- but in reality, this is something we should spend some time focusing on.  When publishing an app, you’re presented with the following portal: By the time you get all the way down to description, all you want to do is hit publish and be done with it.  To further complicate the scenario, the Description section isn’t enabled until packages are uploaded (and, that’s not enabled until the previous steps are complete).  First suggestion: upload a package file that you are using for testing in order to enable the description section.  You won’t submit this for certification as you can simply upload the finished package when ready, but you want to start filling out the description section early: Now that you’ve got the description field enabled, start filling it out.  Revise it.  Think about it.  Create compelling screenshots.  Create the promotional images.  Think about the keywords.  Have this section done ahead of time so when you are ready to submit your app for certification, this isn’t an afterthought.  The reason why this is critical is because this is the first interaction – the curb appeal – of your app.  This is your one chance to convince them to install your app. Get the Word Out You got the email: Now it’s time to get the word out.  Include a link to the app in your email signature.  Include it in your blog.  Send an email to your developer friends, local user group, or app dev club and ask, politely, for some peer reviews.  Post in the developer forums that you just completed the app.  Be proud of your work.  Why is this important?   You want to hit the ground running.  A few days after launching Brew Finder, I was seeing pretty good traction: Looking at the downloads, I noticed a spike shortly after launch: When I opened the Food & Dining category on the store, I saw the reason for the nice uptick: This was great to see!  The app is on its way – but a big part in making this happen is to get the word out early.  Drive as much usage to your app in as short a period of time as you can.  The other thing we want to do is encourage ratings.  One way to do this is to add a ‘nag’ screen in the app.  For example: The above box shows up once every few launches and allows the user to permanently dismiss the box.  When I look at the number of ratings I’ve received (15 ratings, as you can see in the screenshot higher on the page), I’m getting a 1:30 rating to download ratio.   If I look at the apps where I did not ask for ratings: That’s 1:192, 1:131, and 1:180 ratings to downloads.  There is no question that asking users – politely – to rate your app will drive your ratings to download ratio.  You can also add whatever logic you’d like into your rating reminder dialog.  For example, only ask after so many minutes of usage or after a certain number of app launches. So what about making money on the app?  I ruled out charging for the app,  While visiting my dad and describing the app, he looked up a similar app on his phone that charged a measly $0.99, and he didn’t buy it.  I realized that this is a typical reaction – an up front purchase will turn away many users.  In-app advertising is also a possibility, but, because of the specific nature of the app (breweries, beer, etc.), using an ad platform is likely to be detrimental to the app – it will bring in a little revenue, but potentially discourage use.  The ultimately goal is to create a great app, encourage use, and find a way (perhaps through a partnership with breweries) to drive value and revenue.  Is this information useful?  If so, let us know (comments, contact me, etc.).  We’re getting a lot of feedback lately that marketing, monetization, and similar topics are really helpful.   Good luck on your app, and if you publish an app, post a link in the comments and I’ll check it out!

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