Migrating an application to Azure - Part 1: Introduction

Way back in the mists of time (ok, 2011 so not exactly the age of the dinosaur!) I built an employee recognition and reward platform for an FTSE 100 company. Why's that even remotely interesting, I hear you ask? Because it was specified and developed when Azure was very much in its infancy so a self-hosted solution was decided upon. In fairness, there were many reasons that a self-hosted solution was opted for, the level of maturity Azure had reached was but a tiny factor in the decision!

As I've been working my way through the course material for Microsofts 70-534 certification (soon to be 70-535), it seemed like a good way to reinforce the theory with some practice would be to (a) consider how the solution could be re-architected to make use of Azure, and (b) actually re-architect the solution so that it can be hosted in Azure. I'm going to break this up into a couple of posts, but they're probably not going to come out particularly quickly due to the time needed to bring them together so they'll almost certainly be interspersed with posts on other subjects.

I'll try to make sure and link back all the parts here though:

• Migrating an application to Azure - Part 1: Introduction

What the solution does

Before I can describe how the solution is composed, and ultimately how I'd re-architect it to host it in Azure, it's a good idea to outline what the system does and how it's used day to day. In a nutshell:

The solution provides a way for employees to recognise colleagues for positive things they've done, for customers, colleagues or customers so that recognition can be seen by the recipient, their manager and optionally by everyone within the company. There's also a facility for recognition to be given that's been received via a customer contact channel, e.g. a website feedback form or a call made into a call centre. Data extracts can also be used for out-of-band recognition of employees, for example award ceremonies or other public recognition of positive feedback that an employee has received.

The company using the solution has c. 7,000 employees, some use it regularly, some occasionally and some never

The current solution architecture

As currently implemented, the solution makes use of three core components:

1. An ASP.net MVC web application that handles all data collection and display
2. A SQL Server 2008 R2 instance that stores the data for the system
3. A Windows Service that periodically checks for new emails to send (in a database table) and sends them

There is also a writable area on the web server where user profile pictures are stored, these are uploaded by users via the web application, and a data import tool to handle the bulk creation of new users from input data provided by the companies HR systems. Both of these functions are important, but in their absence the system would keep running and alternative ways of handling their duties (switching off profile pictures and manually entering details of user changes) could be found.

Moving the solution to Azure

Of course, the worlds "easiest" way to do this would be to simply "lift and shift", moving the web application, SQL instance and Windows service into an Azure VM. Given that it already runs in a VM, albeit self-hosted that wouldn't be much of a change and would also make for a very short blog post series. It would be a starting point, however, which would take some of the complexities around the usual subjects (e.g. punching holes in firewalls) out of the picture. It would cause issues if the application used any other on-premises resources to complete its functions, though that could be eased by the use of a Site-to-Site VPN and security concerns could be mitigated by using features like Firewalls and Virtual Networks.

For this series of posts, the approach I'm going to take is to document the process of re-working the solution so that it runs in Azure piece-by-piece. The intention at the end is to have a solution that will work both in Azure and on-premises (as that's where it lives now), with a documented path and process for migrating into Azure. The outline steps I'm going to document, though these may change as the series goes on, are:

1. Replace the Windows Service that sends emails with an Azure based solution
2. Replace the storage of profile pictures with an Azure based solution
3. Migrate the SQL Server instance into Azure SQL Database
4. Move the web application into Azure

None of that is particularly difficult, or complex, but maintaining the running application during the process by treating it as a phased migration does add some complexities.

The first step: The Windows Service

I've not started this process yet, but I'm pretty confident that the Windows Service that polls for, and then sends emails will get replaced with the triggering action (pretty much always the web application) creating something in Azure storage (table, queue, blob, who knows!) that an Azure Function reacts to and sends the email. A blob has a certain appeal, as I've already got code for that, but it is about choosing the right tool for a task, so that's a decision that'll need to be made in the next part of the series.