Change Datacenters for Your Microsoft Azure Web Site

If you've ever created a Microsoft Azure Web site, you know how easy it is to get up and running. Given this simplicity, it's easy to get ahead of yourself and create your site without giving much thought to the datacenter where it will be hosted. For example, if the majority of your Web traffic will originate on the West coast, but you set up your site on the East coast, you'd benefit significantly by the reduced latency of moving to a datacenter closer to your users.

Another reason to change datacenters is if you're using a database or other linked resource residing in a datacenter different than that of your Web site. In this case, you'd pay for outbound bandwidth which otherwise would be free if all assets were hosted in the same datacenter. There's no easy way to make this change. It can also be problematic if you've set up a custom domain name for your site.

Fortunately, all is not lost. You can get to the same destination in just a few steps. First, create a new Web site, give it a unique name, and select the region to which you want to "move" your active site. Next, deploy your application to the new site using your preferred deployment method (such as Git, GitHub, WebDeploy, Dropbox and so on). Once you've deployed your app, test it using the URL assigned to your app.

Next, follow my simple four-step guide for assigning a custom domain to your new site. This time, replace the current A record (pointing to the IP address for your current site) in your registrar's DNS settings with the new IP address provided by Azure when you select Manage Domain for the new site. You'll also want to update the awverify, awverify.www and www key/value pairs with the new value for your assigned URL. For example, if your old site is named oldsite.azurewebsites.com, replace "oldsite" with your new site name. Follow the rest of the steps on my post for completing the set up on your new site.

As you're probably aware, DNS entries can take up to 48 hours to propagate, but often update much quicker than this. During this time, requests can bounce between your old and new site. To minimize downtime and disruption to your new site, set the TTL on your registrar's domain settings to the lowest value possible (GoDaddy is 10 minutes). After a few minutes, try stopping your old site and using your custom domain URL; see if traffic is directed to your new site. If you get a pretty looking Azure page, it means that traffic is still flowing to your old site (which is now stopped).

Restart the old site, give it some time and perform this test again. Within an hour or so, traffic should be going to your new site, as evidenced by your custom URL resolving despite your old site being stopped. If you have a highly critical production site and can't afford any downtime, you'll want to look at tools like Azure Traffic Manager to keep downtime to an absolute minimum. After it's resolved, remove your old site and enjoy your site running on your shiny new datacenter.

Rick Garibay is a developer, architect, writer and speaker. He's passionate about distributed technologies and Application Lifecycle Management.

Posted by Rick Garibay on 04/15/20150 comments


Control the Scope of JavaScript Declarations with IIFEs

One of the most common mistakes people make with JavaScript is polluting the global namespace with too many low-level function and variable declarations and then running into subtle bugs when one declaration stomps on another.

For example, if you declare something like var foo = "value"; in a JavaScript file that gets pulled into your HTML page through a script tag, that foo variable is now in the global namespace. You could have some other JavaScript file that also gets pulled in that also declares a foo variable, puts a different value in it, and then your code could start doing unintended things because of the value supplied by that other JavaScript file. If your foo variable is only intended to be used by other code in the same JavaScript file, there's a simple and common structure to be aware of for controlling that scope: Immediately Invoked Function Expressions (IIFEs), also sometimes referred to as automatically invoked functions, or self-invoking functions.

All you need to do is wrap the contents of your JavaScript file in the following syntax:

(function()  
// Your code  here 
})(); 

Now, any variables you declare inside that function are local variables that won't pollute the global namespace and can't be stomped on by other JavaScript files being executed in the same page or scope. Those variables can still be used by any functions declared within that "Your code here" scope through the magic of closures, so you have a nice atomic, modular approach to declaring your chunks of functionality. You'll see this as a common approach to declaring things such as modules, controllers, directives and services in Angular code, for example.

Posted by Brian Noyes on 02/23/20150 comments


Using HTML5 Microdata for Better Search Engine Results

Have you ever noticed when using search engines that some of the results look much better than others? Why do some of the results have pictures and other specific information and links?

A good way to provide this additional information to search engines is using microdata, which adds extra metadata to HTML to better describe the content. A repository of some common vocabularies (schemas) is available at schema.org. The "person" schema could be used to further describe information about a blog:

<!DOCTYPE html>
<html>
<head>
  <title>Robert Boedigheimer</title>
</head>
<body>
  <section itemtype="http://schema.org/Person" itemscope>
    <h3 itemprop="name">Robert Boedigheimer</h3>

    <img src="/images/robert.jpg" width="206" height="250" itemprop="image" /><br />
    <nav>
      <a itemprop="url" href=" http://aspadvice.com/blogs/robertb/">Blog</a><br />
      <a itemprop="url" href="http://tinyurl.com/boedie-mvp">MVP Profile</a>
    </nav>
  </section>
</body>
</html>
 

The itemscope designates the area in the document where a particular schema is used. In this case it's using the http://schema.org/Person schema. The schema provides specific properties that can be attached to the content. The itemprop attribute with value of "name" indicates that this content represents the person's name. The <img> tag has added the itemprop of "image" so that search engines understand which of the various images on the page is a photo of the given person.

Adding microdata is really easy to do, and it's a great way to distinguish your products in search engine results and bring you new customers!

Posted by Robert Boedigheimer on 02/23/20150 comments


Keep Up-to-Date with Visual Studio Live!

Email address*Country*
Upcoming Events