In this post, I'll cover the migration of this web site from a
long history of local hosting to Widows Azure Web Sites.
I've had my own personal domains (GroupLynx.com followed by
irritatedvowel.com followed by 10rem.net) since the mid 90s. Early
on, I used regular hosts. I've run my personal website out of a
succession of servers in my basement for at least a decade. It used
to be serious geek cred to be running all your own servers. Here's
a photo of my site's hardware in 2003:
Back in 2007 I dumped the old desktops I was using and converted
to a couple IBM 345 Xeon-based eServers in a big old APC rack. One
server was for database, the other for the website. In addition, I
had my own email server and domain controller at the time using old
PCs housed in rack cases.
(Left photo shows top of rack, right photo shows bottom of same
rack. Not shown: the ethernet switch near the top)
With these wonderful servers came increased cooling needs. That
meant putting a window shaker in the utility room. Not only is this
ugly, but pretty sure it was costing me a fair bit over time, even
at the relatively high setting I kept it on. Purchasing a
refrigerated rack wasn't an option. Using a purpose-built unit with
a blower on front also wasn't an option as they just cost too much
to purchase and ship.
Being your own IT guy leaves you with no one to yell at
Being your own IT guy is a pretty thankless job. I've had RAID
drives go defunct, servers die, and the power to the whole house
drop at least twice a year. Each time that happened, my site had
downtime. Sometimes, especially in the case of the power outages,
it was always a question as to whether or not the servers would all
come back online properly, or if I'd find myself scrambling to fix
things.
Also, all this equipment in the utility room made a lot of
noise. That noise was picked up by the uninsulated ducting and
broadcast throughout the house. You could hear the servers if you
were near any of the central heating/cooling ducts on a quiet
night.
Last summer, during the derecho storm and related power outage,
my database server lost another drive. The RAID configuration
couldn't handle that because, as it turns out, one of the other
drives had been bad for a while, and I didn't realize it. That
meant that the entire second logical drive (data drive) was gone.
Luckily, I had a backup of the site data, but I had no spare
drives. So I cleaned up the OS drive and freed up enough room to
store the database there.
I investigated hosts for quite a long time. Even though my
blogging has slowed down with my newer role at Microsoft, my site
still gets enough traffic to put it outside the bounds for most
inexpensive hosts. I looked at Azure at the time and at the Azure
Web Sites preview. However, it had a number of issues at the time
which prevented me from moving to it (not the least of which was
you couldn't have a domain name that began with a number - a simple
regex validation bug that stopped me cold).
So I hung it back up for a while. In the meantime, the site has
been down a number of times due to power outages. I did migrate
email off-site, which is good, as that server eventually died, and
the blacklisting associated with not being a proper host got to be
a bit too much. Oh, and I realized I was starting to be used as an
open relay (which despite all the work I did in patches etc, kept
happening).
Moving to Azure
Earlier this year, I made up my mind to move to Azure Web Sites
during my first vacation. Right after Build, I took two weeks off,
and used a small amount of that for the migration. My wife and kids
were up at my mother-in-law's so the house was quiet and I could
really concentrate on the move.
This site has been running on Windows Azure since the
early morning hours of July 9, 2013. The timing was
perfect, as I had yet another power outage, this one killing the
domain server. No, I didn't have a backup domain server. That made
some server tasks…challenging, but not impossible.
When moving to Azure there were several steps:
- Create the Azure account
- Create a Windows Azure Website instance
- Create a Database server (if required)
- Copy the site files
- Migrate data
- Map domain names
My site runs an old version of Umbraco that I have customized to
better support my blog. There's a fair bit of custom code in there,
so migrating to a newer version would be a chore. I decided for
this move to just bring the whole thing over wholesale. Using an
FTP client, I was able to move the site files over quite easily. In
fact, there's almost nothing interesting about that process. Azure
gives you the FTP address, and you just dump files to it. Simple as
that.
The database was a bit more interesting.
Because I use an external database server, and not just
something simple like vistadb, I had to export data to the Azure
database. If you use a filesystem-based database like vistadb with
your install, this whole process becomes much simpler. I tried many
different ways of getting the data over. Of all the things, this
was the most time consuming. (Note that I'm using a SQL Database
Business edition. Web would work fine, and you can switch between
them as necessary. Currently, they both have the same pricing and
features, as I understand it.)
It's so simple though? Why was it time consuming?
Exporting the BACPAC
The reason was I was running a bare SQL Server 2008 install (no
SP, no R2) and using those client tools. What I didn't realize
until I spoke with another person on the team, is that I needed to
use the SQL Server 2012 client tools and then the migration would
be dead simple. Let me save you that time: if you want to
move a SQL database to Azure, regardless of what version, grab the
SQL Server 2012 client tools.
http://www.microsoft.com/en-us/download/details.aspx?id=35579
Download the full installer (SQLEXPRWT_x64_ENU.exe), not the one
that is oddly named SQLManagementStudio. Because, well, that
package doesn't include the management studio. You want
SQLEXPR_x64_ENU.exe (or the 32 bit version if you are on a 32 bit
OS).
You'll also need to create and configure a windows azure storage
account and a container (go into configure page and then choose
"manage access keys" to get the account key). This is where the
export package will reside.
Once I had the right product, I was able to export what is known
as a "bacpac" file. This is not the same as a "dacpac", and is an
option only available in the 2012 client tools. You'll need to
export (not extract) the BACPAC from the database using the client
tools. This is right on the context menu for the database.
This will then bring you through a wizard. There aren't that
many options. Note that you can have the bacpac uploaded to Azure
automatically. This is the option I recommend you choose.
Because of my old SQL install and the newer standards, I was
missing clustered indexes in the Umbraco database. The export
failed because of that. Stuff like this must drive DBAs mad.
Once I went in and created clustered indexes for all tables, the
export completed without a hitch.
Then, I went into Azure and chose the option to import the
database from the bacpac file. I had created a database prior to
this, but decided to simply delete it and let the import create
everything for me from scratch. After about 10 minutes of Azure
showing me 5% complete (which means you're queued, as I was told),
the import completed and the database was online.
Painless! At that point, you could delete the bacpac if you're
comfortable the database is up and running. I verified the data
using the 2012 client tools - they could connect to Azure as easily
as any other networked database.
The domain
The next step was to map the domain over. I had to do this
because my build of Umbraco 4 includes redirect code which sends
you to the main URL for the site regardless of what you type in.
That makes testing on a non-production URL impossible. I don't
recall if this is something I added to make sure I could use a
naked domain like or if it was something intrinsic in Umbraco
4.
Now, if you're smart, you'll do all this before you even start
with the database import. Why? Because DNS takes time to
propagate.
Before you can map domains, Windows Azure requires that you map
some CNAMES for verification purposes, for each unique
domain, as shown in the above screenshot. You can map the
primary, or use some purpose-named subdomains. Azure is specific
about this, so make sure you have the names mapped exactly as
requested. For example, here's my main 10rem.net zone file with the
Azure-required domains still mapped:
MX Records:
A Records:
10rem.net. IN A 137.117.84.54
www.10rem.net. IN A 137.117.84.54
CNAME Records:
awverify.10rem.net. IN CNAME awverify.10rem.azurewebsites.net.
awverify.www.10rem.net. IN CNAME awverify.10rem.azurewebsites.net.
TXT Records:
You can't map your domain in Windows Azure until those cnames
become visible to Azure. One way to track that is to use this web
site:
http://www.digwebinterface.com/
Using this site, you can see the state of propagation for your
DNS entries. It's quite useful. Simply pick "all" and enter the
host names. Here's what it finds for my main domain:
If you want to just check the authoritative one for your domain,
select that from the options:
It's quite useful to monitor progress as you don't want to wait
two or more hours to find out you messed something up.
Here's the awverify verification:
Note the CNAME entry - that's what Azure requires.
Azure in Production
My Azure Web Site is running in Shared mode, with .NET Framework
4.5, 64 bit with no other special settings.
So far, with just this small shared instance, everything has
been running very smoothly. I'll continue to monitor in case it
makes sense to make more capacity available in the future. I can
see adding perhaps one more instance, but so far, it's quite happy
as it stands today. My CPU time stays low. Memory usage is the
highest number, at about 50% capacity on average.
How's the cost? It's really very reasonable. Here's the cost so
far, from late 7/8 through today
Yes, that's a whopping $7.04, or around a dollar a day. I've
probably saved more than that in electricity just by killing the
server rack and the associated AC unit.
I'm at about half the site visits I had in 2011. Once I pick up
blogging at a pace like I used to, I would expect to see that go
up. However, even at double or triple the cost, that's still a good
deal considering I have a website with 3GB in files and several
hundred MBs of database.
Conclusion
So far, this experiment with Windows Azure Web Sites is going
quite well. Once I had the right tools, getting the database over
was simple. Copying the files over was a no-brainer, and even
though my Umbraco website ran under an older version of .NET
locally, it worked just fine when moved to the server.
My site traffic is not much different from some small businesses
I've seen. For those, especially ones which have seasonal traffic
patterns, going with something like WAWS makes perfect sense.