Migrating .NET App to Azure VM (Part 3)

So in part 1 and 2 of this post (Migrating .NET app to azure), we looked at migrating the application to Azure App Service and Azure Scale Sets

If there was a case that we were unable to make any code changes or in-fact configuration changes, then we could look at a lift and shift scenario. Its a really quick way while making no application changes and yet allows you to move your application to the cloud. However its likely that the requirements set out initially will not be meet.

High availability Possible options
Automatically scale No, but perhaps some manual options
Minimal maintenance overhead All windows updates, patching etc.. are manual
Low Cost Potential cost savings

So in this post we will have a look at some possible configurations we can use.

The first option is to just migrate the application to a single VM in Azure, essentially you are just moving the current infrastructure to a cloud based infrastructure.

You can use tools such as Azure Site Recovery to assist with this migration. This could be a good starting point, just get the application to the cloud and then progress from there.

Alternately the other option, to try meet the high availability and scalability demands, might be to create an Azure Load Balancer that will sit in front of 2 Azure VMs. You would also have the option of then additionally adding further VMs manually if load increases over time or if for example known high usage periods are upcoming.

So while the solution might not allow for the application to automatically scale, it will be much easier to manually scale, than if it was still in an on-premise environment.

Some technical information on getting started deploying this solution can be found here

In the case of our sample application, it allows users to upload files, so we do have an issue with this solution as the file will get uploaded to either of the VMs, there wont be a common storage location. In order to resolve this issue perhaps a solution of syncing the files across servers to keep them in sync would also be required, its really about weighing up the pros and cons and deciding what is most important. 

This absolutely isn’t an ideal solution, ideally we would be able to modify the application to suit one of the other options reviewed. But if there is one thing I have learned as part of this process is migrations take time and everything cannot be done all at once. Sometimes the quickest way to get to where you want to is to incrementally work towards it.

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *