Launching Into the Cloud

If you’ve followed my previous blog posts, as well as the case study paper that Microsoft did on us late last year, you will know that we have been on a trajectory to migrate our existing server middleware and web UI applications to the Microsoft Azure cloud computing platform. I am happy to announce that as of late last week we now have a fully functional instance of our core middleware, system administration tools (web based) and end user web applications all running on Azure.  This puts us pretty much right on schedule in terms of where we had hoped to be according to the original migration plan, though we did end up taking a somewhat different route than expected to get here.

The original plan was to migrate our existing core middleware components in an incremental, staged approach over the Q4 2009 – Q1 2010 time frame. This was to be done in a seamless fashion to avoid any interruptions of service for our existing customers while at the same time greatly expanding our functional capabilities by leveraging some of the key new service components available in the Azure framework.  This plan proved to be quite problematic in practice. As it turned out, the move to Azure became increasingly complicated as we began attempting to engineer gap solutions to enable the smooth transition of a functioning system that customers depend on daily. In fact, it became clear to me in late February that this approach was having the effect of bogging down the effort to get to Azure overall. The bulk of our engineering resources involved in this effort were being devoted to the transitional strategy rather than actually focusing on adapting the core features of our system for the Azure platform.  It became obvious that we needed to shift our strategy if we were going to move fully to Azure within any reasonable time frame.

The route that we ended up taking to was to simply take it on as an isolated task and one that did not include any incremental switch-over provisions or intermediary software solutions. The goal was to bring up a fully functional version of our middleware system in Azure with no real thought for the migration from our existing system.  We simply broke down the functional components, interfaces and services and began replicating them while taking full advantage of the new technologies available in Azure such as table storage, BLOB storage, queues, service bus and worker roles. This turned out to be a very liberating experience and although we had already identified the basic design and architecture as part of the previous migration plan, we ended up making some key changes once unencumbered from the constraints inherent in the transitional strategy. The net result is that in approximately 6 weeks, with only 2 team members dedicated to it (yours truly included), we ended up fully replicating our existing system as a 100% Azure application. We were still able to reuse a large percentage of our existing code base and ended up keeping many of the database-driven functions encapsulated in stored procedures and triggers by leveraging SQL Azure.

The transition plan will now consist of enabling our web UI client applications to access customer data and services from either the new, Azure-based middleware system or from the existing, legacy system. New sites brought online will now be joined to the Azure system exclusively. Over the next few months we will slowly migrate existing sites by re-pointing them to the new Azure interface then follow up by backfilling all historical data associated with these sites into Azure table storage after the fact. While this is somewhat suboptimal due to the fact that there will inevitably be a gap in time between when a customer site is communicating with the Azure-based middleware and when all of the historical data has been transferred from the legacy system and fully available, the benefits of eliminating the more complex transitional strategy seem to more than offset this temporary inconvenience. It is expected that there will be no more than a day in between when the site is migrated and when all historical data is available via the web applications.

The fact that we ended up with a clean, stand-alone instance of our middleware and client applications that are in no way dependent upon or complicated by the previous system design has yet another benefit:  easily enabling key customers to run their own unique server software and data storage instance. This is a request that we have received several times over the past few years and was not easily (or inexpensively) accommodated with our existing server application infrastructure.  Now we can simply deploy a set of packages to a new Azure subscription and enable a unique server system instance with fully isolated data for large customers that desire (and are willing to pay for) this type of separation.

So far I can say that we are very impressed with the Azure cloud computing framework from Microsoft. Over the next few months we will be extending and refining our new Azure-based middleware system -watch for future blog posts that will summarize our experiences.