“Let’s move our web applications to cloud.”
It’s quite scary when managers suddenly said something like that. I migrated several web applications which were previously hosted on-premise to Microsoft Azure previously. In order to have least number of codes to change, we chose to use Azure IaaS Virtual Machines (VMs).
From IaaS to PaaS
Creating and managing VMs, however, requires skills and a lot of efforts. I shared my story in Azure Community Singapore meetup previously regarding how our developers sacrificed our sleeping time and weekends just to handle those cloud hosting tasks. Hence, I am now looking for a solution that our developers can just focus on development, not system administration work. That’s when I start to learn more about Azure Cloud Service, the PaaS solution from Azure.
With PaaS, Azure handles most of the system administration work for us. One thing to take note is that even though the applications are still running in VMs, Cloud Service is PaaS, not IaaS. Hence, the developers can simply focus on the deployment of the applications. The platform management will be handled by Azure.
Using PaaS does sound easy. However, unlike IaaS, we need to modify our codes to turn the project into a scalable Azure Cloud Service project that runs on Azure. Also, the disks used in PaaS VMs are no longer persistent. So storage needs to be handled differently.
If you would like to find out more about IaaS and PaaS, please read the Microsoft Azure Documentation about compute hosting options. You will find out one more interesting hosting option available in PaaS called Website (renamed to Web App Service in 2015).
Slots: Production and Staging
When Windows Azure was first announced in Singapore in 2009, I was still studying in NUS School of Computing. I thus had the opportunity to join the Azure student workshop to learn about this cool technology. At that time, publishing a web application to Azure PaaS took about 20 to 30 minutes.
Today, the deployment speed has been shortened to around 6-10 minutes. The interface of Azure Management Portal has been greatly improved as well. Luckily, some good features, especially the Production and Staging Slots, are still around.
Production and Staging Slots are interesting feature in Azure PaaS. There is no such capability in IaaS because in IaaS, the slot will always be production.
Hence, in IaaS, if we want to upload a new version of codes, normally first we will just go to the live server and then replace the existing applications with the updated version. That normally will make the live web applications go down for a few minutes. This is because the affected websites in IIS may be restarted. In addition, when there is a need to rollback the latest upload on live server, there will be cause troubles for developers too.
In PaaS, we have two slots, Production and Staging. Both of them are given different Virtual IP. The new updates of our code can thus be deployed on the Staging Slot first. Once tested successfully, we simply perform a Virtual IP Swap. The staging environment takes over the VIP of the production environment and then the current production environment takes the staging VIP to become staging environment. The swap happens quickly because the only thing changed is the VIPs. What if we want to rollback the latest upload? Just swap again!
Zero-Downtime Deployment: Slot Swap
The Slot Swap is so interesting that I would like to demo it here.
When we publish the web application to Azure through Visual Studio, we can choose whether to publish it directly to Production Slot or just Staging Slot.
After the code is successfully deployed to Staging Slot, an URL having GUID string will be created and shown in Microsoft Azure Activity Log window in Visual Studio. Click on the link to visit our web application deployed on Staging Slot.
After tested the web application successfully, we can now swap it with Production Slot.
When I did a swap, the entire process took less than 1 minute to complete. This is very impressive.
Is There a Way to Use Different AppSetting and ConnectionString Based on Production or Staging Environment?
When I first started with Azure Cloud Service, I always thought the “Staging Slot” is meant for testing environment. However, later it turns out that the real purpose of having Production and Staging Slots is to achieve zero-downtime deployment. Hence, the word “staging” should be renamed to something like “Pre-Production”.
Hence, it’s clear that we should not change our web.config based on the environment. This is simply because Staging Slot is not designed for testing environment. So, for testing environment, we should not use the Staging Slot. Instead, we have to setup another Azure Cloud Service for testing purpose.
Many people have been discussing this issue on Stack Overflow.
- Staging Slot is only a holding area before production is deployed;
- “If you have need for a persistent staging environment, instead use a different hosted service to fulfill that need”;
- “(Staging environment) provides a rollback mechanism in case there is an issue with your upgrade”.
For me, I will still use the Staging environment for QA. However, to do this, I have to re-configure the web.config in staging before and after VIP swapping. After a swap, I need to publish again the project to staging with testing configuration.
However, if you really, really want to use Staging for QA, please read a code sample which will tell which slot your instance is in. I haven’t tried it yet but it does look promising.
SlotStickyAppSettingNames
For those who are familiar with Azure PowerShell commands, there are actually two commands to make app settings and connection strings not to be swapped together with the slots.
For app settings, we have the following command.
Set-AzureWebsite -Name mywebsite - SlotStickyAppSettingNames @("setting1", "setting2")
For connection string, we use the following command.
Set-AzureWebsite -Name mywebsite -SlotStickyConnectionStringNames @("conn1", "conn2")
In fact, these commands had been recently made available in the new Azure Preview Portal. You just need to choose one of your Azure Web Apps, go to its “Settings” page and then click on “Application Settings”.
Wait… This is for Azure Web App only! Yes, so we now (May 2015) still have no such convenience solution for Azure Cloud Service.
Pricing
Cloud Service offers a lower rate as compared to Virtual Machine. Previously, when we were using just A1 instance VM in Standard Tier, we have to pay about USD 67 per month with a disk size of 40GB (in 2015). However, for Cloud Service, we pay only about USD 60 per month and the C drive comes with it is already 224GB (in 2015). Wow!
Even so, we need to keep the cost of hosting application on Azure PaaS low because it’s always challenging to answer manager’s questions like “how come we pay even more to host on cloud?”.
In additional, it turns out that Staging slot is not free. Both Production and Staging slots will be charged at the same rate. Hence, it’s better to delete the Staging slot if it’s already not in use.
Another of my way to save money is to setup multiple website projects in one web role. By doing so, I don’t have to setup different instances for different website projects. There are many approaches to achieve the goal of multiple websites in one web role. Currently, I have only tried partitioning a domain by using virtual application.
To add a virtual web application to an existing web role, I right-click my solution in Solution Explorer in Visual Studio. After that, I create a new Web Application project.
After that, in the ServiceDefinition.csdef, there should be following lines under the <Sites> element.
<Sites>
<Site name="Web">
<VirtualApplication name="admin" physicalDirectory="..\AdminPortal" />
<Bindings>
<Binding name="Endpoint1" endpointName="Endpoint1" />
</Bindings>
</Site>
</Sites>
To access the newly added virtual web application, I just need to append the value of the name attribute to the URI of the primary website. For example, if my primary website is http://www.mywebsite.com, then the virtual web application above will be accessed at http://www.mywebsite.com/admin.
Yup, so now we can have multiple websites in one web role even though we are using PaaS.
Summer 2015 Self-Learning Project
This article is part of my Self-Learning in this summer. To read the other topics in this project, please click here to visit the project overview page.
cuteprogramming 