Here’s a couple of quick observations and reminders that came to mind while doing some recent work to convert a legacy application from being hosted on a customer’s VPS up into Azure.
Working with Azure places a large emphasis on your DNS registrar of choice
Your domain names are important, you want to protect them and choose a good registrar. Your #1 criteria should probably be security (which I something I’ve talked about before), but you also want a good and flexible user interface.
A number of registrars have UIs that try to hide the complexities of how domain names work from their customers. They don’t provide full zone editing capabilities and instead they focus on making the most common operations simple. This can cause trouble with Azure, as the chances are that depending on what you’re doing, you may need access to the full array of record types.
There are some awful registrar sites out there – when you have to use them to change one or two A name records once every few years then it’s not a big deal to get what you need done quickly and get out of there, but when you need to use that same UI to create a wider range of records (including Azure’s auth records) for multiple application components on multiple domains and then do the same again for a test environment then that same UI can become very frustrating to use.
For all the domains I manage I use a service that gives me full control, unfortunately sometimes you’re forced to use the customer’s registrar, and somehow I’ve got a couple of customers who don’t put a powerful UI on their shopping list when choosing where to host their domains.
Azure really forces you to pay attention to your deployment practices
Web.config transforms have been around for a while, but even when you’re actively using them it can be surprisingly easy to slip into the habit of editing a file on the server for some changes, or not having every single thing handled properly.
That obviously gets a lot harder with Azure, and your transforms become a lot more important. You want absolute certainty that they’re doing what you think they are, because it can be a bit of a painful process if you need to use the FTP credentials to verify whether your app has a problem or if it’s just a slightly messed up transform variable.
Of course, it’s a really good thing that you’re forced to do this, but you need to plan time for it into your project – it can’t be something that’s tidied up after the project when you have time as you can’t deploy without having them sorted.
Won’t someone think of the Timezones
Services such as Azure Web Sites and SQL Azure are all set to use UTC. If your app uses DateTime.Now in C# or GETDATE() in SQL then stop and think about how it’s going to behave when you push it up into Azure.
Remember that working with timezones is hard!