In my profession, I get to sit at Peet's Coffee at 6:30am and watch action-packed videos like this:

I know what you're thinking: "slow down, tigerblood. Slow down."

I'm also pushing a new build of customer software up to production, and waiting for my coffee to kick in.

At least I'm not blowing three runs in the 10th with a damned balk, like other people I could name.

Back in November, Chicagoans voted to buy electricity in the aggregate from Integrys rather than the quasi-public utility Exelon. As predicted, the big savings only lasted a few months:

And Chicago, where residents saw their first electric-bill savings this month under a 5.42-cent-per-kilowatt-hour deal completed in December with Integrys, will see its energy savings shaved to just 2 percent.

ComEd's new price is not yet official. But utility representatives have filed their new energy price of 4.6 cents per kilowatt-hour with the ICC and have told the commission they expect forthcoming transmission charges to be about another 0.95 cents per kilowatt-hour. That will make the ComEd "price to compare" cited by competing suppliers when marketing their offerings about 5.55 cents.

That said, between the new Integrys rate that hit me on my last electricity bill, and moving to the cloud, my March bill was only 54% of my average bill from 2009 to 2012. So ComEd is lowering rates too? Good. It'll still be higher than Integrys.

Too much going on:

• Paul Murphy at Financial Times thinks Cyprus will do the right thing
• Microsoft released figures about national security letters the FBI has sent it
• .NET 4 introduced the System.Numerics.Complex type
• Microsoft's Channel 9 posted a video about migrating applications to Azure virtual machines
• Jeff Atwood makes a case for the Ruby language
• BuzzFeed imagines Twitter's 7th anniversary promo video with the Inception theme
• No one really cares about LinkedIn endorsements
• T-Mobile has put up an animated graphic showing cyber attacks in real time

Now, I will go back to drafting documentation while I wait for AT&T to reconfigure my DSL and kill my landline. I've had a POTS ("plain old telephone service") twisted-pair line longer than most people on earth have been alive. After today, no longer. I don't think I'll miss it, either. I only have it because I have a business-class DSL, which I don't need anymore, and the only people who call it want money from me.

I've fixed seven annoying bugs and added three minor features to Weather Now, including:

• Fixed searching from the search box so you can enter an airport code directly;
• Fixed the Last 24 hours page to show day and night icons properly;
• Added a status page so users can peek under the hood; and
• Tweaked a few things in the background worker process around logging and status update alerts.

A minor bug fix release like this used to take a couple of hours to deploy, because I had to update the code running on the web server file-by-file. I got the process down to about an hour—but I still had to bring the application offline to make the update.

Since I put it up in Microsoft Windows Azure, publishing an update takes about 15 minutes, is completely automated, and doesn't require taking the site down. The great Inner Drive migration continues to pay dividends.

Regular blog readers know that since moving to my current apartment in February 2008, the Inner Drive Technology International Data Center has occupied a couple square meters of my home office. I've also mentioned lower energy use since I started to move everything out of the IDTIDC and into Microsoft Azure.

Something else has happened to my electricity bill. In November, we citizens of Chicago voted to pool our electricity buying to get the lowest electricity cost possible. Well, the new regime kicked in last month, and the 660 kw/h I used in February cost 25% less than the 610 kw/h I used in January—which was the lowest use ever for this place.

It helps, also, that since moving my email to the cloud in June, I've used an average of 224 kw/h less electricity each month year-over-year.

I can't wait to see my bill for March. They read my meter on the 7th or 8th to prepare the bill I just got; the IDTIDC shut down on the 10th.

I'm paying 90% of my attention right now to a Windows Azure online training class. I already knew a lot of the material presented so far, but not all of it. It's like re-taking a class you took as an undergraduate; the 10% you didn't know is actually really helpful.

Like next week's class, which will go over Infrastructure as a service: a lot has changed in the last year, so it should be valuable.

Apparently, though, my homework is to build an Azure web site this week. Not a multi-tier application with a worker role. Just a web site. How adorable.

The Inner Drive Technology International Data Center is no more.

This morning around 8:15 CDT I updated the master DNS records for Weather Now, and shut down the World Wide Web service on my Web server an hour later. All the databases are backed up and copied; all the logs are archived.

More to the point, all the servers (except my domain controller, which also acts as a storage device) are off. Not just off, but unplugged. The little vampires continue to draw tens of Watts of power even when they're off.

The timing works out, too. My electric meter got read Thursday or Friday, and my Azure billing month starts today. That means I have a clean break between running the IDTIDC and not running it,* and by the beginning of May I'll have more or less the exact figures on how much I saved by moving everything to the Cloud.

Meanwhile, my apartment is the quietest it's ever been.** The domain controller is a small, 1U server with only one cooling fan. Without the two monster 2U units and their four cooling fans (plus their 12 hard drives), I can suddenly hear the PDC...and now I want to shut it down as well.

* Except for the DSL and land-line, which should be down in a couple of weeks. I'll still have all the expense data by May.

** Except for the two blackouts. Now, of course, I never need worry about a blackout again—unless it hits the entire country at once, which would create new problems for me.

Weather Now is fully deployed to the Cloud. As soon as the Worker Role finishes parsing the last few hours of weather, I'll cut over the DNS change, and it will be live.

Actually, that's not entirely true; I'm going to cut over the DNS in the morning, after I know I fixed the bugs I found during this past week's shake-down cruise.* So if you want to see what a weather site looks like while it's back-filling its database, you can go to its alias, http://wx-now.cloudapp.net. (Because of how Azure works, this will remain its alias forever.)

Time to meet my friends, who are wondering where I am, no doubt.

* Bugs fixed: 13. Total time: 6.9 hours (including 2.4 to import and migrate the Gazetteer).

The final deployment of Weather Now encountered a hitch after loading exactly 3 million (of 7.2 million) place names. I've now kludged a response for the remaining 4.2 million rows, and a contingency plan should that upload fail.

Meanwhile, I have a saturated Internet connection. So rather than sit here and watch paint dry, so to speak, I'm bringing back some of the bugs that I decided to postpone fixing. The end result, I hope, will be a better-quality application than I'd planned to release—and a rainy Saturday made useful.

Tomorrow morning, shortly after I have my coffee, I will finally turn off the last two production servers in my apartment the IDTIDC. The two servers in question, Cook and Kendall, have run more or less continuously since November 2006*, gobbling up power and making noise the whole time.

As I write this, I'm uploading the production Weather Now deployment along with the complete Inner Drive Gazetteer, a 7.2-million row catalog of place names that the site uses for finding people's local weather. It takes a while to upload 7.2 million of anything, of course; and it's only 35% done after two hours. Trying to deploy the Cloud package at the same time may not have made the most sense, but I need the weather downloader to start running now so that when I cut over to the new site, it has actual weather to show people.

I started this project on November 3rd, logging almost exactly 100 hours on it until today. I'm through the tunnel and almost done climbing up the embankment. One more night of whirring fans and then...quiet.

Update: Crap. The Gazetteer upload crashed after 3 million rows. Now Plan B...

* Yes, I did just link to the Wayback Machine there. The original Inner Drive blog is offline for the time being. I have a task to restore it, as I haven't updated it since 2008, it's not a priority.

Another update: the original link at (*) pointed to Wayback Machine, but after reconstituting the old blog I corrected the link. That's why the footnote above no longer makes a lot of sense.

I don't have time to read these must-read articles:

• Noam Schreiber on Aaron Swartz
• Marlene Zuk on our fascination with the paleolithic
• Sean Flynn on Pope Benedict's butler
• Microsoft on the Azure outage a year ago (interesting because it may be related to last week's outages
• Jennifer Lawrence rocks

Back to the mines...

Microsoft has suffered some unfortunate outages this week, first affecting SQL databases on Monday, and then yesterday storage:

On Friday, February 22 at 12:44 PM PST, Storage experienced a worldwide outage impacting HTTPS traffic due to an expired SSL certificate. This did not impact HTTP traffic. We have executed repair steps to update SSL certificate on the impacted clusters and have recovered to over 99% availability across all sub-regions. We will continue monitoring the health of the Storage service and SSL traffic for the next 24 hrs. Customers may experience intermittent failures during this period. We apologize for any inconvenience this causes our customers.

The outage caused problems throughout the Azure universe, because SSL-based storage underpins just about everything. Without Storage, for example, any VM that goes offline can't restart, because its VHD is kept in Storage. Web sites and Service Bus were also hosed. My customers were annoyed.

These problems can affect any computing system. The problem with Azure Storage going down was the scope of it: millions of applications. Even the largest colo data center only has tens of thousands of computers. With so many people affected, the outage looks like a disaster.

I'll be watching Microsoft closely over the next few days to see what more they can tell us about the outage. But if this was all do to certificates expiring, wow.

Over the past two days, Microsoft Azure had two outages they're still investigating. The first, from 18:26 CST through 20:00 CST Monday (0026 to 0200 UTC Tuesday), and the second, from 13:50 to 15:27 CST (1950-2127 UTC) yesterday, affected SQL Database and related services in the Azure datacenter outside Washington, D.C.

I noticed the Monday evening outage as it happened, because when a database goes down, a number of applications start sending me emails. A couple of people had minor inconveniences, but as it happened on a holiday evening, the damage wasn't too severe.

I did not notice the Tuesday afternoon outage, which did affect a lot of people and made some of my clients very angry, because I was on an airplane. When I landed and turned on my phone, I had 300 emails from various applications and mercifully only 4 from angry clients. (Welcome home!)

Microsoft hasn't determined reported the cause yet, but given the maintenance they had planned, started, and then backed out on Sunday night, they may have a clue. They have a second round of maintenance planned for tonight at midnight CST (0600 UTC). I'll be watching carefully tomorrow morning.

Last night I made the mistake of testing a deployment to Azure right before going to bed. Everything had worked beautifully in development, I'd fixed all the bugs, and I had a virgin Windows Azure affinity group complete with a pre-populated test database ready for the Weather Now worker role's first trip up to the Big Time.

People interested in those sorts of things can continue to read some helpful Azure debugging tips. Otherwise, stay tuned for a whinge about trying to do work on an airplane.

This is a more-technical follow up to my most recent post. If you're interested in how the next version of Weather Now will use Microsoft Windows Azure technology to provide real-time weather information, keep reading.

This is another post about Azure software design, which not everyone will find especially interesting. I promise to post more Parker photos soon. Meanwhile, if you want to read about how the Weather Now parsing system will work in version 4, keep reading.

My efforts to move Weather Now up to Microsoft Azure took on some new urgency today when I noticed this:

That particular error code means the RAID battery has less than 24 hours of charge in it. Fortunately, this means only that the disk will slow down if the battery dies, unless there's a sudden power failure, in which case I could lose the entire RAID volume.

This is exactly the sort of thing that made me want to move all my applications to the Cloud in the first place.

I just hope I can finish the port before...well, before ol' Sparky dies...

This is about C# development. If you're interested in how I got a 60-fold improvement in code execution speed by adding a one-line Entity Framework configuration change, read on. If you want a photo of Parker, I'll post one later today.

As I've noted before, only one Web application still lives in my living room the Inner Drive Technology Worldwide Data Center: Weather Now. In the last few days, it's showing one more good reason that it needs to get to Windows Azure pronto.

Take a look at my Google Analytics view of incoming visitors:

What is going on? How do I go from 300 daily unique visitors to 1,800 in two days? Take a look at where they're coming from:

Yes, that's right. Close to 40% of Weather Now's traffic came from the Yukon Territory yesterday. And another 40% came from Alaska. And they're all going to this page for some reason. This might be why:

So how does Azure enter into it? Simply, if you have a Web application running on your own server, and you get a 750% increase in traffic, your server may not be able to handle it. Or, worse in a way, you might have been running the server capable of handling the peak load all the time, at great expense in electricity and hardware.

With Azure, you can simply bring another instance online, or increase the size of your running instance, or do any number of things to adapt quickly to the increased load, without having to buy or move the hardware. Then, when the load returns to normal, you can spin down the idle capacity. The trick is, you only pay for the capacity you're actually using.

I'm getting a lot closer to moving Weather Now, but a deadline looming at my paying job tomorrow has my attention at the moment. So more on this stuff later. Meanwhile, if you're in the Yukon or in central Alaska, stay warm, folks!

I've just spent three hours debugging something caused by a single missing line in a configuration file.

At 10th Magnitude, we've recently upgraded our framework and reference applications to the latest Windows Azure SDK. Since I'd already done it once, it didn't take too desperately long to create the new versions of our stuff.

However, the fact that something works in an emulator does not mean it will actually work in production. So, last night, our CTO attempted to deploy the first application we built with the new stuff out to Azure. It failed.

First, all we got was a HttpException, which is what ASP.NET MVC throws when something fails on a Razor view. The offending line was this:

@{ 
   ViewBag.Title = Html.Resource("PageTitle");
}

This extension method indirectly calls our custom resource provider, cleverly obfuscated as SqlResourceProvider, which then looks up the string resource in a SQL database.

My first problem was to get to the actual exception being thrown. That required me to RDP into the running Web role, open a view (I chose About.cshtml because it was essentially empty), and replace the code above with this:

@using System.Globalization
@{
  try
  {
    var provider = new SqlResourceProvider("/Views/Home/About.cshtml");
    var title = provider.GetObject("PageTitle", CultureInfo.CurrentUICulture);
    ViewBag.Title = title;
  }
  catch (Exception ex)
  {
    ViewBag.Error = ex + Environment.NewLine + "Base:" + Environment.NewLine + ex.GetBaseException();
  }
}
<pre>@ViewBag.Error</pre>

That got me the real error stack, whose relevant lines were right at the top:

System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.WindowsAzure.ServiceRuntime, Version=1.7.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
File name: 'Microsoft.WindowsAzure.ServiceRuntime, Version=1.7.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
at XM.UI.ResourceProviders.ResourceCache.LogDebug(String message)

Flash forward an hour of reading and testing things. I'll spare you. The solution is to add a second binding redirect in web.config:

<dependentAssembly>
  <assemblyIdentity name="Microsoft.WindowsAzure.ServiceRuntime" 
    publicKeyToken="31bf3856ad364e35" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-1.0.0.0" newVersion="1.0.0.0" />
  <bindingRedirect oldVersion="1.1.0.0-1.8.0.0" newVersion="1.8.0.0" />
</dependentAssembly>

Notice the second line? That tells .NET to refer all requests for the service runtime to the 1.8 version.

Also, in the Web application, you have to set the assembly references for Microsoft.WindowsAzure.Configuration and Microsoft.WindowsAzure.Storage to avoid using specific versions. In Solution Explorer, under the References folder for the web app, find the assemblies in question, view Properties, and set Specific Version to false.

I hope I have saved you three hours of your life. I will now go back to my deployment, already in progress...

Update, an hour and a half later: It turns out, there's a difference in behavior between <compilation debug="true"> and <compilation> on Azure Guest OS 3 (Windows Server 2012) that did not exist in previous guest OS versions. When an application is in debug mode on Azure Guest OS 3, it ignores some errors. Specifically, it ignores the FileNotFoundException thrown when Bundle.JavaScript().Add() has the wrong version number for the script it's trying to add. In Release mode, it just barfs up a 500 response. That is maddening—especially when you're trying to debug something else. At least it let our app log the error, eventually.

Well, that was fun. I've just spent the last three days organizing, upgrading, and repackaging 9,400 lines of code in umpteen objects into two separate assemblies. Plus I upgraded the assemblies to all the latest cool stuff, like Azure Storage Client 2.0 and...well, stuff.

It's getting dark on the afternoon before the U.S. Thanksgiving holiday, and I'm a little fried. Goodbye, 10th Magnitude Office, until Monday.

Oh, Azure Storage team, why did you break everything?

Software people will want to continue for some specific tips on how to do the upgrade.

Last month I used less electricity than ever before at my current address, mainly because two of the five servers in the Inner Drive Technology Worldwide Data Center have had their duties migrated to Microsoft Windows Azure.

It wasn't my smallest-ever bill, though, thanks to Exelon's recent rate increases. But still: here's some more concrete evidence that the Cloud can save money.

And before people start pointing to the New York Times article from September about how wasteful the Cloud is, I can't help but point out that the writer left out the part where moving to the cloud lets businesses turn off their own on-premises servers. And given the way Azure works (and, I assume, Amazon's and Google's equivalents), instead of dedicated servers doing just about nothing all day, you have shared servers handling sometimes dozens of different virtual machines for a fraction of the cost.

Anyway, except for the part where I fly 100,000 km every year, I feel like moving to the Cloud is helping everyone.

Voters in the City of Chicago (including me) passed a referendum giving the city the authority to negotiate electricity prices on behalf of everyone. Implementation will be swift:

The timing of the deal is important because Chicagoans stand to save the most money over Commonwealth Edison's rate between now and June 2013, when ComEd's prices are expected to drop because pricey contracts they entered into years ago will expire. The timeline has Chicagoans moving to the new supplier in February 2013.

Michael Negron, deputy chief of policy and strategic planning for the mayor's office, said electricity suppliers have shown great interest in snagging Chicago's service. Nearly 100 people packed a conference Monday for the city's "request for qualifications" process. The bidders ranged from multi-billion corporations to smaller providers from all over the country, he said. Industry analysts say the deal could be worth hundreds of millions of dollar to the winning supplier or suppliers.

Residents and businesses may opt out of the scheme and negotiate supply prices separately. As readers of this blog know, I'm desperate for lower prices, and eagerly looking forward to my electric bills next year after the new rate deal hits right after I shut down the Inner Drive Technology Worldwide Data Center.

I mentioned a few weeks ago that I've had some difficulty moving the last remaining web application in the Inner Drive Technology Worldwide Data Center, Weather Now, into Microsoft Windows Azure. Actually, I have two principal difficulties: first, I need to re-write almost all of it, to end its dependency on a Database of Unusual Size; and second, I need the time to do this.

Right now, the databases hold about 2 Gb of geographic information and another 20 Gb of archival weather data. Since these databases run on my own hardware right now, I don't have to pay for them outside of the server's electricity costs. In Azure, that amount of database space costs more than $70 per month, well above the $25 or so my database server costs me.

I've finally figured out the architecture changes needed to get the geographic and weather information into cheaper (or free) repositories. Some of the strategy involves not storing the information at all, and some will use the orders-of-magnitude-less-expensive Azure table storage. (In Azure storage, 25 Gb costs $3 per month.)

Unfortunately for me, the data layer is about 80% of the application, including the automated processes that go out and get weather data. So, to solve this problem, I need a ground-up re-write.

The other problem: time. Last month, I worked 224 hours, which doesn't include commuting (24 hours), traveling (34 hours), or even walking Parker (14 hours). About my only downtime was during that 34 hours of traveling and while sitting in pubs in London and Cardiff.

I have to start doing this, though, because I'm spending way too much money running two servers that do very little. And I've been looking forward to it—it's not a chore, it's fun.

Not to mention, it means I get to start working on the oldest item on my to-do list, Case 46 ("Create new Gazetteer database design"), opened 30 August 2006, two days before I adopted Parker.

And so it begins.

Last week, I bought an ASUS Transformer TF700, in part to help out with our seriously-cool Galahad project, and in part so I could read a bunch of heavy technical books on tonight's flight to London. And yes, I had a little tablet-envy after taking the company's iPad home overnight. It was not unlike fostering a puppy, in the sense that you want to keep it, but fortunately not in the sense of needing to keep Nature's Miracle handy.

Then yesterday, Scott Hanselman pointed out a great way to get more use out of the pad: Instapaper. I'm hooked. As Hanselman points out,

Here's the idea. You get a bunch of links that flow through your life all week long. These are often in the form of what I call "long-form reading." Hackernews links, NYTimes studys, academic papers, etc. Some folks make bookmarks, have folders called "Links" on their desktops, or email themselves links.

I have these websites, papers and interesting links rolled up and delivered automatically to my Kindle every week. Think about how amazing that is and how it can change your relationship with content on the web. The stress and urgency (and open tabs) are gone. I am naturally and organically creating a personalized book for weekend reading.

I have a bookmarklet from Instapaper that says "Read Later" on my browser toolbar. I've put it in every browser I use, even Mobile Safari. I've also logged into Instapaper from all my social apps so that I can Read Later from my iPhone Twitter Client for example. You'd be surprised how many apps support Instapaper once you start looking for this.

What this means it is that Instapaper is ready and waiting for me in every location where an interesting piece of long-form reading could present itself. I don't stress, I click Read Later and the document is shipped off to Instapaper.

I'm sold. I actually have it updating my tablet every 12 hours, because I do a lot of my reading on the 156 bus. Or, today, British Airways 226.

I still haven't moved everything out of the Inner Drive Technology Worldwide Data Center to Microsoft Windows Azure, because the architecture of Weather Now simply won't support the move without extensive refactoring. But this week I saw the first concrete, irrefutable evidence of cost savings from the completed migrations.

First, I got a full bill for a month of Azure service. It was $94. That's actually a little less than I expected, though in fairness it doesn't include the 5–10 GB database that Weather Now will use. Keep in mind, finishing the Azure migration means I get to shut off my DSL and landline phone, for which AT&T charges me $55 for the DSL and $100 for the phone.

I also found out how much less energy I'm using with 3 of 5 servers shut down. Here is my basic electricity use for the past two years:

The spikes are, obviously, air conditioning—driven very much by having the server rack. Servers produce heat, and they require cooling. I have kept the rack under 25°C, and even at that temperature, the servers spin up their cooling fans and draw even more power. The lowest usage periods, March to May and October to December, are cool and moist, so I don't use either air conditioning or humidifiers.

Until this month, my mean electricity use was 1100 kWh per month overall, 1386 kWh in the summer, and 908 kWh in the shoulder seasons. In the last two years, my lowest usage was 845 kWh.

Last month it was 750 kWh. Also notice how, during the much hotter summer in 2012 (compared with 2011), my electricity use was slightly lower. It was just harder to see the savings until now.

Including taxes, that means the bill was only $20 less than the usual shoulder-season bill. But I'm not General Motors; that $20 savings is 20% of the bill. Cutting my electricity bills 20% seems like a pretty good deal. And next summer, with no servers in the house, I'll be able to run less air conditioning, and the A/C won't have to compete with the heat coming off the server rack.

Now I've just got to figure out how to migrate Weather Now...

My latest entry is up on the 10th Magnitude tech blog.

You can also read it right here.

Last night, around 11:30pm, the power went out in my apartment building and the ones on either side. I know this because the five UPS units around my place all started screaming immediately. There are enough of them to give me about 10 minutes to cleanly shut down the servers, which I did, but not before texting the local power company to report it. They had it on again at 1:15am, just after I'd fallen asleep. I finally got to bed around 2 after bringing all the servers back online, rebooting my desktop computer, and checking to make sure no disk drives died horribly in the outage.

But unlike the last time I lost power, this time I did not lose email, issue tracking, this blog, everyone else's site I'm hosting, or the bulk of my active source control repositories. That's because they're all in the cloud now. (I'm still setting up Mercurial repositories on my Azure VM, but I had moved all of the really important ones to Mercurial earlier in the evening.)

So, really, only Weather Now remains in the Inner Drive Technology Worldwide Data Center, and after last night's events, I am even more keen to get it up to the Azure VM. Then, with only some routers and my domain controller running on a UPS that can go four hours with that load, a power outage will have less chance of waking me up in the middle of the night.

My latest 10th Magnitude blog post is up, in which I dig into Microsoft's changes to Azure Web Sites announced Monday. The biggest change is that you can now point your own domain names at Azure Web Sites, which solves a critical failing with the product that has dogged them from its June release.

Since this Daily Parker post was embargoed for a day while my 10th Magnitude post got cleared with management, I've played with the new Shared tier some more. I've come to a couple of conclusions:

• It might work for a site like Inner Drive's brochure, except for the administrative tools lurking on the site that need SSL. Azure Web sites still have no way to configure secure (https://) access.
• They still don't expose the Azure role instance to .NET applications, making it difficult to use tools like the Inner Drive Extensible Architecture™ to access Azure table storage. The IDEA™ checks to see whether the Azure role instance exists (using RoleEnvironment.IsAvailable) before attempting to access Azure-specific things like tables and blobs.
• The cost savings isn't exactly staggering. A "very small" Web Role instance costs about $15 per month. A Shared-level Web Site costs about $10. So moving to a Shared Web Site won't actually save much money.
• Deployments, however, are a lot easier to Web Sites. You can make a change and upload it in seconds. Publishing to a Web Role takes about 15 minutes in the best circumstances. Also, since Web Sites expose FTP endpoints, you can even publish sites using Beyond Compare or your favorite FTP client.

I did upgrade one old site from Free to Shared to move its domain name off my VM. (The VM hosted a simple page that redirected users to the site's azurewebsites.net address.) I'll also be moving Hired Wrist in the next few days, as the overhead of running it on a VM doesn't make sense to me.

In other news, I've decided to go with Mercurial for source control. I'm sad to give up the tight integration with Visual Studio, but happy to gain DVCS capabilities and an awesomely simple way of ensuring that my source code stays under my control. I did look at Fog Creek's Kiln, but for one person who's comfortable mucking about inside a VM, it didn't seem worth the cost ($299).

Crain's Chicago Business yesterday ran the first part in a series about How Chicago became one of the nation's most digital cities. Did you know we have the largest datacenter in the world here? True:

Inside the former R.R. Donnelley & Sons Co. printing plant on East Cermak Road, next to McCormick Place, is the world's largest, most-connected Internet data center, according to industry website Data Center Knowledge. It's where more than 200 carriers connect their networks to the rest of the world, home to many big Internet service providers and where the world's major financial exchanges connect to one another and to trading desks. "It's where the Internet happens," Cleversafe's Mr. Gladwin says.

Apparently Chicago also hosts the fifth-largest datacenter in the world, Microsoft's North Central Azure hub in Northlake. (Microsoft's Azure centers are the 5th-, 6th-, 9th-, and 10th-largest in the world, according to Data Center Knowledge.) And then there's Chicago's excellent fiber:

If all of the publicly available fiber coming in and out of the Chicago area were bundled together, it would be able to transmit about 8 terabits per second, according to Washington-based research firm TeleGeography. (A terabit per second is the equivalent of every person on the planet sending a Twitter message per second.)

New York would be capable of 12.3 terabits, and Washington 11.2 terabits. Los Angeles and San Francisco are close behind Chicago at 7.9 and 7.8 terabits, respectively. New York is the primary gateway to Europe, and Washington is the control center of the world's largest military and one of the main connection points of the Internet.

Chicago benefits from its midcontinent location and the presence of the financial markets. "The fiber optic lines that go from New York and New Jersey to Chicago are second to none," says Terrence Duffy, executive chairman of CME Group Inc., who says he carefully considered the city's infrastructure when the futures and commodities exchange contemplated moving its headquarters out of state last year because of tax issues. "It benefits us to be located where we're at."

Now, if I can just get a good fiber to my house...

Remember how I've spent the last three months moving stuff into the Cloud? And how, as of three weeks ago, I only had two more services to move? I saved the best for last, and I don't know for sure now whether I can move them both without some major changes.

Let me explain the economics of this endeavor, and why it's now more urgent that I finish the migration. And then, as a bonus, I'll whinge a bit about why one of the services might have to go away completely.

I should really learn to estimate networking and migration tasks better. The last time I upgraded my FogBugz instance on my local web server, it took about 20 minutes. This led me to estimate the time to migrate it to a Microsoft Azure Virtual Machine at 2 hours.

Well, 2½ hours later, I'm a little frustrated, but possibly closer to getting this accomplished.

The title says it all. I've moved Hired Wrist, my dad's brochure site, up to my Azure VM, leaving only Weather Now, plus my bug tracking and source control applications, in my living room the Inner Drive Technology Worldwide Data Center.

I'll move the two third-party apps next weekend. My experience moving Hired Wrist this morning suggests that moving Weather Now will be, as we say, "non-trivial" (i.e., bloody hard).

If one of the developers on one of my teams had done this, I would have (a) told him to get some sleep and (b) mocked him for at least a week afterwards.

Saturday night I spent four hours trying to figure out why something that worked perfectly in my local Azure emulator failed with a cryptic "One of the request inputs is out of range" message in the Cloud. I even posted to StackOverflow for help.

This morning, I spent about 90 minutes building a sample Cloud application up from scratch, adding one component at a time until I got to the same failure. And, eventually, I got to the same failure. Then I stepped through the code to figure out

And I immediately saw why.

The problem turned out to be this: I have two settings:

    <?xml version="1.0" encoding="utf-8"?>
    <ServiceDefinition name="Cloud" ...>
      <WebRole name="WebRole" vmsize="Small">
        <ConfigurationSettings>
          <Setting name="MessagesConfigurationBlobName" />
          <Setting name="MessagesConfigurationBlobContainerName" />
        </ConfigurationSettings>
      </WebRole>
    </ServiceDefinition>

Here's the local (emulator) configuration file:

    <?xml version="1.0" encoding="utf-8"?>
    <ServiceConfiguration ...>
      <Role name="WebRole">
        <ConfigurationSettings>
          <Setting name="MessagesConfigurationBlobName" value="LocalMessageConfig.xml"/>
          <Setting name="MessagesConfigurationBlobContainerName" value="containername"/>
        </ConfigurationSettings>
      </Role >
    </ServiceConfiguration>

Here's the Cloud file:

    <?xml version="1.0" encoding="utf-8"?>
    <ServiceConfiguration ...>
      <Role name="WebRole">
        <ConfigurationSettings>
          <Setting name="MessagesConfigurationBlobName" value="containername" />
          <Setting name="MessagesConfigurationBlobContainerName" value="CloudMessageConfig.xml"/>
        </ConfigurationSettings>
      </Role >
    </ServiceConfiguration>

I will now have a good cry and adjust my time tracking (at 3am Saturday) from "Emergency client work" to "Developer PEBCAK".

The moral of the story is, when identical code fails in one environment and succeeds in another, don't just compare the environments, compare *everything that could be different in your own code* between the environments.

Oh, and don't try to deploy software at 3am. Ever.

While trying to move a customer's app into the cloud yesterday (and well into this morning), I encountered a problem that doesn't make any sense. I now very much want to find the guys who wrote Microsoft Azure's error handling and punch them in their faces.

When you access an Azure storage container, you have to use only lower-case letters, or Azure will throw a StorageClientException with the thoroughly unhelpful message "One of the request inputs is out of range." So, in all the code I've written that uses Azure storage, it makes sure everything that needs to be lower-case is actually lower-case.

So why am I getting the exception now? No one seems to know.

Worse, the exception only happens in actual deployments, not in the Azure emulator (which you use to test your code on your own computer).

I hope to have this figured out soon. Because I'd really like to get some sleep.

Remember all those Azure migrations I've done over the past month? Well, I have another one that I wasn't expecting, and for a variety of reasons including a failed web server, it must be completed by Monday morning.

Remember I'm going to San Diego tomorrow? Good thing the airplane has WiFi.

And people wonder why I eat chalk a lot...

Sometimes things just work.

Last weekend, I wrote about moving my last four web applications out of my living room the Inner Drive Technology International Data Center and into the cloud via a Microsoft Azure Virtual Machine.

Well, if you're reading this blog entry, then I've succeeded in moving The Daily Parker. Except for transferring files (the blog comprises 302 megabytes over 13,700 files), which happened in the background while I did other things, it only took me about 45 minutes to configure the new installation and make the necessary changes to DNS.

Despite the enormous volume of data, this was the easiest of the four. DasBlog has no dependencies on outside services or data, which means I could move it all in one huge block. The three remaining applications will take much more configuration, and will also require data and worker services.

I'm still surprised and pleased with the smoothness of the transfer. If the other three migrations go anywhere nearly as easily as this (taking into consideration their complexities), I'll be an Azure Evangelist for years.

My latest missive for my employer, "When to use Microsoft Azure’s IaaS instead of PaaS", is now available on the 10th Magnitude blog. It's similar to a post from last weekend, but with better writing and editing.

In every developer's life, there comes a time when he has to take all the software he's written on his laptop and put it into a testing environment. Microsoft Azure Tools make this really, really easy—every time after the first.

Today I did one of those first-time deployments, sending a client's Version 2 up into the cloud for the first time. And I discovered, as predicted, a flurry of minor differences between my development environment (on my own computer) and the testing environment (in an Azure web site). I found five bugs, all of them minor, and almost all of them requiring me to wipe out the test database and start over.

It's kind of like when you go to your strict Aunt Bertha's house—you know, the super-religious aunt who has no sense of humor and who smacks your hands with a ruler every time you say something harsher than "oops."

End of complaint. Back to the Story of D'Oh.

I hope to finish moving my websites into the cloud by the end of the year, including a ground-up rewrite of Weather Now. Meanwhile, I've decided to try moving that site and three others to an Azure Virtual Machine rather than trying to fit them into Azure Cloud Services.

For those of you just tuning in, Azure Cloud Services lets you run applications in roles that scale easily if the application grows. A virtual machine is like a standalone server, but it's actually running inside some other server. A really powerful computer can host a dozen small virtual machines, allocating space and computing power between them as necessary. You can also take a virtual machine offline, fold it up, and put it in your pocket—literally, as there are thumb drives easily as big as small VMs.

If you're interested in PaaS, IaaS, and the future of my living room the Inner Drive Technology Worldwide Data Center, read on.

Long-time readers will know how I feel about Microsoft certification exams. When it came time for 10th Magnitude to renew its Microsoft Partner designation, and that meant all of us had to take these tests again, I was not happy.

So, against my will, I took exam 70-583 ("Designing and Developing Windows Azure Applications") and passed it. I am once again a Microsoft Certified Professional.

Fwee.

(Another post originally appearing on the 10th Magnitude blog.)

Last week I offered developers a simple way to simultaneously deploy a web application to a Microsoft Azure web site and an Azure Cloud Services web role. Today I'm going to point out a particular pain with this approach that may make you reconsider trying to deploy to both environments.

In my last post, I talked about using Azure web sites to save beaucoup bucks over Azure Cloud Services web roles on nonessential, internal, and development web applications. In this post I'll go over a couple of things that bit me in the course of deploying a bunch of applications to Azure web sites in the last two weeks.

Read more for the technical details.

(Cross-posted to my company's blog.)

If you’ve looked at Microsoft’s Azure pricing model, you’ve no doubt had some difficulty figuring out what makes the most economic sense. What size instances do I need? How many roles? How much storage? What will my monthly bill actually be?

Since June 7th, Microsoft has had one price for an entry-level offering that is completely comprehensible: free. You can now run up to 10 web sites on a shared instance for free. (Well, you have to pay for data output over 165 MB per month at 12c per gigabyte, and if the site needs a SQL Database, that’s at least $5 a month, etc.)

At 10th Magnitude, we’ve switched to free Azure websites for our dev and staging instances of some internal applications and for our brochure site. And it’s saving us real money.

The full post explains why.

I've just completed my fourth Windows Azure deployment this month, and this time, it's a non-trivial site. The Inner Drive Technology corporate website now lives up in the Cloud. Actually, it lives in two places: as an Azure Website for testing, and in Azure Cloud Services for production. All I have to do to complete the task is publish the "production" instance (I've successfully published the "staging" instance) and configure DNS.

This deployment gave me the most trouble, mainly because it has a lot of stuff in it: all my code demos, especially time zones. I also discovered a couple of things about deployments to Azure Cloud Services, in particular that the default staging deployment hits a different port than the production deployment.

It took me about 7 hours to convert the existing Inner Drive code into an ASP.NET Web application and get it working in an Azure website. I had a major hiccup trying to get the time zone data to load, because on an Azure website (but not in Cloud Services), the IANA tzinfo database files live in the file system.

Moving it to Cloud Services only took me about 90 minutes, though. As I've discovered, there are differences between the two, and it's a pain in the ass to alter the project and solution files every time you want to deploy it to a different environment. So, I copied the project and solution files, and voilà! Easy deployment to either environment.

I'll write more about this later. At the moment, I'm waiting for the enormous Inner Drive Extensible Architecture SDK to upload to the Cloud. This could take a while...time to walk the dog.

Update, 21:15 CDT: Inner Drive is live on Azure, including the entire SDK. It took 25 minutes to deploy, which, believe it or not, isn't much more than it usually takes. But the total time to add a Cloud Services role and deploy the site—not counting when I walked away to do something else—was just under two hours.

By Wednesday afternoon I'd migrated two Web sites from the loud and hot server rack in my home office to Microsoft Azure web sites. Then I popped off to New York for last night's game, and when I got back to my hotel room I encountered yet another reason I like the Cloud: I couldn't get to any of the sites back home.

It turned out that a brief power failure had caused the firewall to reboot—I think a UPS didn't last as long as expected—and in the process it caused the Web server's network adapter to fail.

Keep in mind, all I knew was I didn't have most of my Web sites, including the Daily Parker. I did have email, because I'd already moved that to the Cloud. But I didn't know whether I'd blown a circuit breaker, whether someone had cut my home Internet cable, or whether someone had burgled my house.

So, I'm going to continue migrating sites as quickly as I can. And by autumn, mysterious outages will, I hope, not happen again.

I've finished two complete migrations from my living room the Inner Drive Technology Worldwide Data Center to Microsoft Windows Azure web sites. Astute readers may remember that in one case I moved to the Web site offering and then moved it to a full-fledged Web role. Well, today, I moved it back. Even though I'm still on the free trial, it turned out that the Web role would cost $15 per month, which, for a site that gets one or two visitors per day, simply wasn't worth it.

Moving the second site, a silly thing from 2004 created to share photos and commentary about a 10-year series of Presidents Day parties a friend of mine hosted back in the day, went a lot more smoothly. Click through for a rundown of what went well and what didn't.