In the last post in this series I covered Azure’s Infrastructure as a Service or IaaS execution model that allows users “bare metal” access to create and manage VMs within the cloud. With this power comes great administrative responsibility that may not always be desirable or even necessary. What if you don’t need this degree of control? In that case, the IaaS approach may be overkill. If you are simply looking to deploy a web application to the cloud and let Azure’s built-in infrastructure handle the majority of the maintenance for you then Azure’s Web Sites option may be the right choice for you. Azure’s Web Sites feature is the cornerstone of Azure’s Software as a Service or SaaS offering that provides a rich IIS-based environment for hosting easily managed, massively scalable web applications.
In order to better understand this offering it’s often helpful to draw comparisons to traditional web hosting. With traditional web hosting the user is not typically concerned with or even able to directly access the hardware, operating system, web server or networking infrastructure that their applications are hosted on; these aspects are normally managed internally by a third-party hosting provider. The same is true with Azure’s Web Sites service. With SaaS the user gives up some degree of control in order to be relieved of the vast majority of administrative burden. Unlike the hands-on IaaS approach offered by Azure, patching, load balancing, deployment and hosting with IIS are all handled for you automatically. It is important to note that in this model Remote Desktop functionality is not available.
With Web Sites you have the option of providing a custom web application built on a variety of frameworks including Node.JS, ASP.NET and even Classic ASP or choosing from an online gallery of popular open-source web platforms such as Drupal, Joomla or Wordpress. One thing that you may notice here is that updates to your web application are wicked fast. The reason that updates are so rapid is that, unlike the IaaS offering covered in the last post, web applications by default run on shared instances. This means that new instances do not typically need to be created. So, with Azure Web Sites, updates typically take seconds not minutes.
Like the other offerings that Azure provides, the Web Sites service is extremely scalable. As I mentioned before, by default, an application runs on an instance of IIS potentially shared with other sites. Even in this model users have the option of scaling up to a maximum of three shared instances. It’s important to note here that scaling up or down with Azure Web Sites is nearly instantaneous and does not cause a disruption in service as the underlying infrastructure automatically load balances requests between running instances of the application. Even with the relatively limited amount of control afforded to users of the SaaS offering this ability to dynamically scale horizontally means that users can scale up during peak hours then scale down as needed to save money. While running on shared instances is fine for most scenarios some applications require a little more horsepower from the underlying VM. In these scenarios, users can opt to run their application in reserved mode. In reserved mode, an application is hosted within its very own dedicated instance. In keeping with the same spirit of scalability, users can choose to run their application on up to three dedicate instance. Unlike the shared capability, users can also choose the size of the instance, small, medium or large that they wish to host their applications on.
Since most web applications beyond the simplest static sites rely on some type of database Azure provides the option of creating and linking a managed SQL Server or MySQL database instance, made possible through a partnership with provider ClearDB, to your application. When used in combination with Entity Framework and SQL Database Migrations this can be an especially powerful feature as you can deploy your web application and database in one fell swoop asoutlined in this article. If you’re looking for a NoSQL approach you can also take advantage of Azure’s Table storage offering by setting up a storage account.
With the option of deploying from a gallery of common open-source applications, directly from Visual Studio, via FTP or even from your favorite source control tool including Team Foundation Server and Git, moving your web applications to the cloud has never been simpler. Azure Web Sites provides impressive support out of the box for both the new Team Foundation Service and the increasingly popular GitHub allowing you to configure automatic deployments to an Azure Web Site on commit. With both of these services you also have the ability to rapidly roll back to a previous deployment which can come in very handy when promoting to staging and production environments. A common and recommended pattern, especially with Git, is to create a branch (by default Azure Web Sites is configured to use the master branch) for each environment (Development, QA, Staging, Production, etc.) and tie each branch to an Azure Web Site deployment. With this model continuous integration and promoting features to different environments is a breeze.
We have covered quite a bit of ground on Azure’s SaaS offering, Web Sites, in this post. To learn more about Azure Web Sites and sign up for a free 90-day trial that includes 10 free web sites go to http://aka.ms/thecloud and sign up today.
In my next and final post in this series I will be covering Azure’s Platform as a Service or PaaS offering that provides a happy medium between the “hands on” IaaS approach and the nearly completely managed SaaS approach covered in this article. Until then, stay cloudy my friends!