In the previous articles we discussed about why we chose Windows Azure over other alternatives as a scaling platform and about the database migration progress to SQL Azure. In this article we will close the series by presenting how we migrated the web portal from a local IIS to the Azure cloud.
We are dealing with a classic web architecture, a web portal developed in ASP.net MVC (3 & 4) backed up by a database running on MS SQL, abstracted by Entity Framework.
This architecture had to be prepared for "scaling" - moved to a configuration that allowed a high number of customers (requests) to be serviced at once.
After analyzing more scaling options (the reasoning backing up this choice can be read in the first article of the series) we chose SQL Azure and Windows Azure as migration platforms.
Windows Azure gives us multiple options/services when it comes to architecture development (e.g. service bus, caching, mobile services etc.) but accessing these services would imply changes to our architecture.
But in our case we did not want to change our architecture but only migrate 1-to-1 the existing architecture (as much as possible) with as little changes as possible to our design, even if this would mean that we would not take full advantage of what Azure has to offer.
We had to migrate a web portal made up of 2 front end websites and a whole "family" of virtual directories containing services.
We needed at least 1 WebRole - a web role is a virtual machine, or an array of virtual machines (when scaling) that host one or more websites.
In one word a web role is a web server. The traffic directed to the web role will be load balanced between all the virtual machines that make up the web role - this way the scaling is achieved: do you need better performance? Add more virtual machines to the web role.
The restriction for scaling is that all the virtual machines have to be identic in configuration - if we started the WebRole with a machine with a modest hardware configuration (say configuration A) we will only be able to scale by adding more machines of configuration A.
As the Azure machines configuration directly affects our costs (better machines = more money) it is important to find the required and sufficient configuration for running our website/application without problems, and then we can scale the system by adding more machines with the same configuration (as a guideline - we find the minimum configuration capable of running our website/application and then we scale horizontally - thus we have more flexibility and we optimize the costs).
Our analysis will take into account: the MSDN documentation, our project"s characteristics (if we optimized for multiple processors, if we are running a RAM intensive application, if we require dedicated processors or if we are ok with using a shared processor, etc.), and, most importantly, the performance tests that we will run with various configurations - this way we will take the most "informed" decision.
After we have decided on a configuration for our web role, we are ready to create and configure the Azure project and WebRole.
Microsoft made our lives considerably easier by integrating (almost) all Azure related operations directly inside Visual Studio. Assuming that we are using Visual Studio 2012 we will need the Azure SDK and we are ready to go.
We open the solution that contained our project/projects and we add a Windows Azure Cloud service project.
We will be adding manually the existing projects to the WebRole so we will leave the Cloud Service project empty.
After the project is created we add all other projects to the WebRole from Solution Explorer:
Defining the website structure and the virtual directories structure
After adding the first project to the WebRole, we will add the next ones by manually editing the ServiceDefinitions file.
This configuration file will describe how the web sites and web directories will be structured and accessible so inside we will add:
Finally we will end up with a configuration like this:
The last step - publishing the WebRole on Azure - only at this step the virtual machines will be created and our code will be transferred to each of these machines. Again, Microsoft made things easy for us: from Visual Studio we chose the Publish option on the Cloud Service project.
The publishing wizard will help us chose and create the required Azure infrastructure (cloud service and storage account) and chose the desired target environment: staging (recommended) or production.
If all went ok and the WebRole was successfully created we will be able to access the website/websites on the address visible on the administration portal (http://manage.windowsazure.com/) - a GUID type address, guid.cloudapp.com, if we published the product on the staging environment or an address like mywebportal.cloudapp.com if we published on production.
The tooling Microsoft provides for us is excellent - they did a great job in making a clean, easy to understand and easy to use, management interface.
With this being said, once you start the migration process you will be running into all sorts of issues (particular to your project/context). And there are a lot of aspects/questions to which I did not answer (nor tried to) - like how to choose between a single WebRole vs multiple WebRoles - so if you would like to ask specific questions you can reach out to me at dragos(at)txtfeedback.net.
Migrating to Azure was not without problems, but now, 3 months after the migration was done we can say that we are completely satisfied with the results (and our return on investment).
Most of the challenges we faced were connected to the know-how - how you translate your local architecture to a cloud architecture, what do you need to change to your database, what is a WebRole, what is your minimum required configuration, etc. .MSDN, Pluralsight trainings, stackoverflow, they all helped but the most useful were the discussions we had with people that underwent a similar process.
I would like to nominate here Radu Vunvulea and Zoli Herczeg (from Microsoft) that found the time to sit with us, answer our questions and point us to the right direction.