The challenge of migration – determining Windows #Azure migration complexity
The challenge of migrating any application is, more often than not, a worthy architectural and business exercise. Its worth is in lock step with the value of the application – its usage and importance. It can result in benefits for the users (e.g. access and performance) and the business (e.g. agility and cost).
When considering migrating your applications to the “cloud”, there are several considerations that I believe are universal. For Windows Azure the migration effort could be as little as a packaging (zip-ping) exercise, since you don’t have to change your application to match the platform. Your application will work out of the box, but it may have unexpected side effects. It could be already architected and designed to work well as a Azure application, though the older your application the less likely this is to be the case. In essence your application should deal with two things: traffic being load balancing and data persistence.
Its more likely, that as an application is migrated, that its on premise roots are exposed. So, rather than uproot the application, it is important to consider application migration as part of a process. For example:
When determining migration complexity there are tools to help such as the Migration Assessment Planning Tool. However I propose there is an easier practice for performing a quick check on your application. I use these basic categories:
| Consideration | Action | Description |
| Packaging | Mandatory | Application parts that are required to be unpacked by Azure for setup |
Persistence |
On review |
All data stored should be accessed in a cloud friendly way |
| Stateless | By design | The execution is consistent regardless of which compute instance is runs on |
| Configuration | On Review | Parameters the application leverages that can change periodically |
| Resilience | By design |
The application tolerance to manage failures (e.g. retries) |
| Legacy | On review |
The degree to which the application relies on traditional or unsupported frameworks |
To put this into context, and the topic for my next blog post I’d like to illustrate this in light of my experiences of migrating the .net Pet Shop 4.0 to Windows Azure.
| Consideration | Findings |
Packaging |
Most of the effort was in converting web site to a web application Specifically
|
Persistence |
Since there were multiple SQL databases, some effort was required to:
TODO:
|
Stateless |
For the application to manage state, there were some changes to its use of:
TODO:
|
Diagnostics |
There was very little diagnostics so added logging and performance counters for roles to make user of the Windows Azure diagnostics |
Resilience |
None – TODO! |
Legacy |
There were a few considerations of older frameworks and practices including:
|
In addition there are some migratory considerations in terms of security.For the .Net pet shop this was simply the firewall rules for SQL Azure but it could have included HTTPS portions of the site, and therefore certificates, or indeed payment gateways etc.
All in all the effort in migrating this application was around 1-2 hours but repeatable in roughly 15 minutes. The wider ramifications of management, and proper feature inclusion (such as the CDN) would require some thought and extra time, but I expect it would be nothing too significant.
What I learned from this exercise, was that migration is not trivial, but its also often a mental rather than a heavy lifting exercise. Its also an exercise where you can quickly determine the suitability of migration. Almost all applications could be migrated but some perhaps shouldn't – which us back full circle to the business benefit of migration. If migration to the cloud is too difficult then its probably worth considering how you use Windows Azure rather than how you move to Windows Azure.
For more information on migration the MSDN Azure portal offers quite a bit of advice in addition to the following I read: