Many of us claim to have cloud based solutions just by leveraging AWS/Azure infrastructure. In order to reap all the benefits of cloud, we should move to PaaS. In our latest product development, we are taking this path. I just wanted to share some of my experiences in this blog.
I have built two products and both of them were hosted in Azure. Essentially, we had VMs on which WE managed SQL Server, IIS, OS etc. Of course we had separate VM for application servers and database servers. Things worked out nice as we had the availability/security of any world class data center.
However, people had to login to these VMs using remote desktop to manage lot of activities such as installing our web apps, web API apps, patch OS etc. As you can imagine, even though this helped a great deal, you still had to perform lot of manual work. For example, if the traffic increased and if you wanted to scale horizontally, it involves lot of manual work.
Now Azure offers a service called “Azure App Service”. I am not sure what is the equivalent service called in AWS. This is where things get very interesting.
All our products are built using Microsoft Stack, so will take this concrete example and describe the scenario. Like most of the modern web applications, our solutions are built using ASP.NET MVC. So in order to move from IaaS to PaaS, you do not have to make even a single change to your MVC application. I hope you understand huge benefit of this. Just like any normal MVC application you develop in your favorite Visual Studio 2015, debug on local IIS or IIS Express. Only when you are ready to deploy this application, there is an additional option to deploy to Azure App Service (You have to have installed Azure SDK 2.9.5 to see all the tooling in Visual Studio 2015). All the magic starts to happen from here onwards. When you choose this option and deploy this to Azure app service, you get an xxxx.azureservice.com url. You will have option to map your domain and SSL certificates through azure portal.
What is different? Why Should I use Azure App Service?
Once the app is deployed, unlike you IaaS scenario, you cannot login to VM using Remote desktop. That is how it should be. Now let us assume a following scenario, traffic to your web site is heavy during certain times of the day. You can login to azure portal and configure how many instances of your web apps needs to be available during different times. When you do this, you do not have to worry about load balancing etc. Out side of those specified periods, azure will bring the number of instances automatically.
Besides, you tell Azure to dynamically scale the number of instances. For example, if the CPU goes above 80%, increase the instances.
Azure App Services has another cool thing called deployment slots.
In a given environment (For example, Dev, QA prod Prod), you can deploy your app to different slots. After deployment, you can test them and perform a hot swap once everything is working fine. I hope you understand the advantages it brings to your deployment process. Imagine a scenario where you cannot afford to have any downtime for your web application. Assuming your application very well tested, you can deploy to “Staging” slot of “Production” machine. You can perform a through testing on production instance to make sure everything works as planned. Once the “staging” slot on production instance is working as planned, you can perform a hot swap to production slot.
Few Minor changes we made to our existing MVC application
All our MVC applications use Enterprise Library for logging purpose. We used both database and file listener for logging. Once you move to Azure App Services, you won’t be able to login to VM, hence no access to file system. We started using Azure diagnostic listener.
Moving from IaaS to PaaS could not have been any easier than this. Happy moving !