I am VP of Technology for a small ISV called GoldMail; all of our applications run on Windows Azure. We are rebranding – changing from “GoldMail” to “PointAcross” – and we will change the company name at some point as well. People think “GoldMail” is an e-mail product (it isn’t), and PointAcross (as in, we help you get your point across) is a more focused brand. We are changing everything except our desktop product, which will remain GoldMail, and will eventually be deprecated. We have been working on a web version of our desktop product for quite some time now, and we’re calling it PointAcross. With our web application, we can accommodate both Windows and Mac users. We’ve also simplified the usability.
Our infrastructure – over a dozen cloud services – runs in Windows Azure. With each update, we have to update the SDK in every project, do regression testing, and then release them to production. Our product roadmap is packed; we are pushing out releases as fast as we can, with some big product features coming in the next few months. The trick is to minimize disruption by combining the SDK updates with new releases. This works pretty well, although some of our products have faster release cycles than others, so not everything gets updated at the same time.
As you know if you’ve read my post about our implementation of Windows Azure, I am a glutton for punishment, so I’ve commited to rebranding everything and upgrading everything to SDK 2.0 in the same release. We updated to SDK 1.8 a few weeks ago, but we are still targeting Storage Client Library 1.7, so we have breaking changes to contend with. Did I mention I committed to completing all of those changes in two weeks?
Now, there are two ways to do a rebranding project of this size. The easy way is to change all the public-facing URLs by just adding DNS entries that point to the goldmail services, storage accounts, etc., using pointacross in the names. This leads to major confusion later, and makes it difficult to get rid of any goldmail artifacts down the line. Plus, if we add more services, do we brand them as goldmail internally (to be consistent), or switch to pointacross?
The harder way is to set up all new services and storage accounts in Windows Azure, and add new DNS entries for them. If we do it this way, we have to change all of the URLs in the configurations (and code) for all of the services, and all of the storage account names and keys we have in the Azure service configurations. But in the end, we end up with an infrastructure that is fully branded with the new name, and there won’t be any slip-ups where the old name will be displayed. Also, we can set up the new services, publish everything, and run the two production systems in parallel, then cut over when we’re satisfied that everything is working correctly. After cutting over, we change any goldmail DNS entries that might be used “out in the wild” (like in HTML pointing to our embedded player) to point to the PointAcross addresses.
Of course, I’ve chosen to do the more difficult way of rebranding. I think of it as “the right way” – I hate to do anything halfway, and we’ll never have time to go back and rebrand internally, so if we don’t do it now, we’ll end up with goldmail services forever. I’m also taking advantage of this opportunity to move all of our services and storage accounts from the North Central data center to the US West data center. I have several reasons for doing this.
First and foremost, the North Central data center is full. If you don’t already have services running in North Central, you can’t select it as an option. This also means that we can’t create VMs and use IAAS in the same location as our other services, because they don’t have that feature enabled for North Central. My second reason is because the new hardware in the newer data centers has the newer, faster hard drives, and our applications will gain performance with no effort on our part. Well, no effort except for the huge effort of moving everything, but that’s a one-time hit, versus the performance gain for our customers.
The other thing I will do is add a new storage account for diagnostics. When we started, we only used one storage account, because our use of Azure Blob Storage was almost non-existent. We have added some usage for blob storage, so it makes sense to use our main storage account for that, and create a new storage account for the diagnostics. Also, we have 2-1/2 years of diagnostics in the storage account that we don’t need to be retaining and paying for, and we can let it go when we delete the old storage account some time down the line.
In my next post, I’ll talk more about this project and how we’re going to move data from one storage account to another, as well as any issues I hit upgrading to SDK 2.0. In the meantime, if you have any advice or comments, please leave them in the comments section!