Migrating to a cloud platform can be a daunting task. There are some key things to consider when using Azure Websites as your hosting solution. This section will showcase the what you need know about the platform when migrating to Azure websites.

1. Globally available

Azure websites is available in multiple datacenters across the world. This makes it easier to bold websites to meet the needs for your geographical markets that concerns you. To see the list of supported regions , click here.

2. Azure Websites has a built-in load balancer

When you setup your website on IaaS based solution, you need to use Ngnix or other solutions to setup our load balancer. With Azure websites, you don’t need to worry about Load balancing your sites across multiple VMs and you can use it with Azure traffic manager to load balance across regions. Note that if you are using FREE tier of Azure websites, then Load balancer is not supported.

Hence you don’t need to build a custom load balancer for your website.

3. Azure Websites uses IIS Web Server

Azure Websites runs on a Windows based Infrastructure with IIS as the Web Server.It support the following frameworks : .NET, PHP, Node JS, Python and Java. Azure websites takes advantage of all IIS features with respect to security , diagnostics and performance. To learn more about IIS , click here.

4. Understanding SLA for Azure websites

No application built on Azure websites can assume that the hosting service will be 100% available. Read and understand the SLA for Azure websites which states that Azure websites will provide a 99.9% monthly availability for your website.

if you are using other Azure services or non-Azure services that are either tightly or loosely coupled with your application such as Database, Azure Storage, CDN service, YouTube service etc. then you need to understand the SLA from their services as well.

If you want to have more than 99.9% up time every month, you must keep in mind what components can fail and understand you can manage failover or disaster recovery for your website.

5. Features per Price tier

Azure Websites is offered in four tiers: Free, Shared (Preview), Basic and Standard.

• Websites Shared (Preview): The price for the Shared tier during preview is $0.013 per hour per website instance (~$10/month). This price reflects a 33% preview discount.
• Websites Basic and Standard: The Basic and Standard tiers offer multiple instance sizes as well as scaling to meet changing capacity needs starting from $56 for a Basic (Single Small instance) and $75 for a Standard ( Single small instance)

For more details on features per price tier , click here.

6. You cannot access the Virtual machine that hosts your website

Azure websites gives you’re the infrastructure to host our applications but you cannot really connect to the Virtual machine and access the machine. This means you cannot install any software on these machines. You application does not reside on a physical device but virtual machines and that can be scaled up or down or replaced when the virtual machine goes bad.

Hence your application must be stateless to work in such an environment.

7. Auto-scaling

Auto-scale feature is available with Standard Website mode . It is cost effective way to scale your website without any manual intervention. Instead of manually increasing or decreasing the instance count of your website, auto-scale will pick the right scale for your website based on the incoming site traffic within your specified range. To learn more , see how to configure Auto-scale.

8. File Server for the Azure Websites is Shared by ALL instances

The file server is shared across all the instances your websites is configured to use. When using multiple instances, and if you want to cache some session data on a machine, not that not all the instances will be able to see this.

Depending on what your application is trying to achieve , use a persistent storage for application when you need the data to be consistent with all the Virtual machine instances your website is running on , if not you can store the data in %TEMP% folder on your Virtual machine instance.

9. Caching

Azure websites provides Wincache for PHP applications and IIS server level caching (output caching) that can be used for any application that can be hosted on IIS and Wincache for PHP applications that can be leveraged.

Most of time this is more than sufficient, but if you need a higher level of caching you need to use:

• Azure Redis cache Preview or
• Azure Managed cache or
• Build our own cache cluster using Azure Virtual machines

10. Staged Deployments and Publishing

Azure websites provides a concept of staged deployments and publishing with site slots which is available for Standard mode sites running on Microsoft Azure Web Sites. It gives you the ability to create development or staging site slots for each default production site (which now becomes a production slot) and swap these slots with no down time. To learn more, see How to configure and deploy to site slots.

11. SSL

When someone visits your web site using HTTPS, the communication between the web site and the browser is secured using Secure Socket Layer (SSL) encryption. This is the most commonly used method of securing data sent across the internet, and assures visitors that their transactions with your site are secure. This article discusses how to enable HTTPS for an Azure Web Site. To learn more, see how to configure SSL

12. Custom Domains

When you create a web site, Microsoft Azure provides a friendly sub-domain on the azurewebsites.net domain so your users can access your web site using a URL like https://.azurewebsites.net. You can also associate a custom domain name, such as contoso.com, with your web site in order to provide a more recognizable domain name for your users. To learn more, see How to add a custom domain to your Azure website.

13. Background Processes with WebJobs (Preview)

Microsoft Azure Web Sites enables you to run programs or scripts in your web site in one of three ways: on demand, continuously, or on a schedule. There is no additional cost to use Microsoft Azure Webjobs unless you wish to enable the Always On feature. To learn more, see how to create webjobs for Azure websites.

14. Auto-Healing

Enabling this for your website will help your site automatically detect certain conditions and recover. As part of “Always ON” feature, there have been some enhancements which will allow you to automatically recycling the worker process (your VM instance) hosting your web application. To learn more, see how to enable auto-healing.

15. Backups and Restore

The Azure Web Sites Backup and Restore feature lets you easily create web site backups manually or automatically. You can restore your web site to a previous state, or create a new web site based on one of your original site’s backups.

For information on restoring an Azure web site from backup, see restore an Azure web site. For more information on configuring backup, see backup an Azure website.

16. Use SendGrid service for SMTP

SMTP is not enabled by default on websites. If you web application requires email service , you can purchase SendGrid service which has plans starting from Free which allows 2500 emails per month to higher plans as described here. To learn more, see how to configure SendGrid.

Checklist to Going Live with Azure Web Sites

• Choose the data center’s) where you would host the site
• Understand hosting plans for Azure websites to plan out if all your websites would be using the same hosting plan or differentiate based on whether the app is production site or staging site
• Choose a deployment solution for meet your need : GIT, Web deploy , Bitbucket, DropBox,Github etc or a custom solution built using the GIT , Web Deploy API
• Setup all the dependent components such as like cache , database etc. if your application requires it
• Setup a development/test website for your web application
  • Either use Site slots or
  • Create a separate website depending on your requirements for the development site for example if your development application is using a different database or different website mode or different hosting plan etc.
• Setup a staging website for your web application
  • Either use Site slots or
  • Create a separate website depending on your requirements for the development site for example if your development application is using a different database or different website mode or different hosting plan etc.
• Setup your production web application. We recommend to run your production application either on Basic or Standard to get the most bang for your buck. Enable Web Server logging to a Azure storage account to be able to debug application issues in production , staging and development sites
• Setup a custom domain on your production site
• If your application requires a lot of media content like images and videos , use other services like Azure storage to host the media content and Azure media services(.NET Apps) or third party services like YouTube for Php/Python/Node JS/Java applications for video streaming
• Setup SSL if your application requires it on your all your sites : development , staging , production
• Setup Auto-healing on all your websites
• Setup automated backups using our backup feature or build your own solution using Web Jobs or Azure VM to host your backup web service process
• Setup Auto-scaling on your production site. It is not required for development and staging sites to be cost effective and can be enabled during scale and performance testing for development or staging sites.

Conclusion

There are many architectural and design considerations to be made to reap the benefits of cost effective, scalable and fault tolerant solution like Azure Websites. The document highlights best practices and understanding of the key aspects of the platform provided by Azure websites that will help you to increase the likelihood of successful deployments and hassle-free operations.