January 2013

Volume 28 Number 01

Azure Insider - Microsoft Azure Web Sites: Quick-and-Easy Hosting as a Service

By Bruno Terkaly, Ricardo Villalobos | January 2013

Azure Web Sites (WAWS) is a compelling feature of the Microsoft cloud platform. WAWS is a service built on top of the Azure Platform as a Service (PaaS) framework that simplifies the deployment, management and scalability tasks associated with hosting cloud applications. If this makes you think WAWS is just another glorified hosting solution, think again. What’s different is the level of scalability and high availability it provides, backed by multiple datacenters around the world and the failover mechanisms inherited from the PaaS components. Moreover, the Azure platform offers many additional features and capabilities beyond WAWS, allowing developers to enhance their applications as their needs grow, including support for big data, identity, mobile services and more.

Datacenter Deployment Models

The taxonomy shown in Figure 1 illustrates the different models associated with the deployment of a Web application in a public datacenter. The number of layers delegated to the platform or vendor lets us distinguish the terms Infrastructure as a Service (IaaS), PaaS and Software as a Service (SaaS).

Figure 1 Taxonomy for Cloud Deployment Models

The more layers you delegate to the vendor, the easier it becomes to deploy a solution online, though generally the level of customization for the delegated layers decreases. Azure offers both IaaS and PaaS deployment models that, combined with other services, allow companies to create sophisticated and highly scalable cloud architectures. Based on this, where do we place WAWS?

Why You’ll Love Azure Web Sites

As we mentioned, WAWS is built on top of the Azure PaaS framework, which means you only have to worry about maintaining the application and data layers of the deployment stack. The big difference compared with the traditional PaaS model offered by Azure is that some of the deployment and configuration tasks are greatly simplified. This is possible thanks to the provisioning process underlying WAWS, which is based on a combination of stateless worker roles, storage Binary Large Objects (BLOBs) and relational databases.

Figure 2 shows the architecture that supports WAWS. This is an elegant and robust approach to providing a multi-tenant environment for hosting Web applications. The way it works is simple:

1. A client makes a request to host https://foo.azurewebsites.net.
2. The request goes through the Azure Network Load Balancer, reaching the appropriate deployment.
3. The Application Request Routing (ARR) module gets info from the runtime database about foo.com, determines which Web servers should host or are currently hosting the Web site, and forwards the request to the corresponding one.
4. The request is processed by the Web server, aided by the storage controller to reach the specific instance of SQL Server in case data is being read or written.
5. Once the request has been processed, a response is sent back to the client.

Figure 2 Azure Web Sites Under the Hood

Inside each of the Web servers, multiple W3WP.exe processes—or sites—are hosted, monitored by a specific process that oversees resource consumption, errors and logging. Also, the Dynamic Web Activation Service is responsible for site activation and deactivation, quota enforcement and deployment of the application files. Two additional components complete the picture: the deployment servers host the FTP and Web Deploy engines, while the API front end provides an interface for automation purposes.

This architecture is what provides a near-instant deployment experience, with the option of scaling out when required.

There are many great reasons to consider WAWS. One is that this service provides strong support for client-side markup and scripting, including built-in connectivity to SQL Server and MySQL databases. This means you don’t need to worry about implementing back-end Web services and server logic. Another good reason to consider WAWS is its ability to scale up and down to support Web users in both the busiest and quietest of times.

Because you pay for only what you use, you can provide a responsive UX while keeping costs low. The WAWS service also supports continuous development method­ologies, so you can deploy directly from source code repositories, using Git on a client, GitHub, CodePlex, Bitbucket or Team Foundation Server (TFS). It’s possible to instantly upload new code or continuously integrate with an online repository. Thanks to its provisioning model, the WAWS service offers built-in support for WordPress, Joomla!, Drupal, DotNetNuke, Umbraco and more. These templates are categorized in the WAWS gallery, and include blogs, content management, ecommerce, forums and wikis.

Keeping It Real

As with any technology that simplifies a problem, there are always trade-offs. For instance, WAWS doesn’t support a staging environment for testing, or network isolation to bridge cloud applications with on-premises networks (including Azure Connect or Azure Virtual Networks). However, users can choose to use the Service Bus Relay service to bridge the gap with corporate resources. In addition, you can’t run a remote desktop to the compute instances, or kick off a startup task during your deployment. Even so, WAWS is a perfect solution for the development and deployment of Web applications that don’t require a high level of customization.

Hands On

Now let’s walk through a simple tutorial. As we do, you’ll begin to realize you don’t need to learn anything new about the cloud. You can focus on creating your Web app and its data just as you always have. The details of moving to the cloud are abstracted away by the service, providing a frictionless deployment experience. You can even write the same classic ASP code you built in 1996 and run it in WAWS.

We’ll explore the basic elements of the WAWS service by creating a simple yet practical ASP.NET MVC 4 application using SQL Server as the back end. This simple application will support Create, Read, Update and Delete (CRUD) operations and will require hardly any code. When we’re through provisioning the WAWS and building the ASP.NET MVC 4 application, we’ll deploy it using Web Deploy from Visual Studio 2012. The only expense is the SQL Database—running the ASP.NET MVC 4 application within WAWS is free. You can run up to 10 sites for free with no expiration date.

Start Visual Studio and Create an MVC Project

To start, open Visual Studio 2012 as Administrator and click File | New | Project. Choose Web from the Installed Templates, then select ASP.NET MVC 4 Web Application. Name the project MVCAzure.Website and click OK (see Figure 3). You’ll need to select a Project Template next. Choose Internet Application here. The View Engine will be Razor.

Figure 3 Creating a New ASP.NET MVC 4 Web Application Project

Code First

A Code First approach means that the classes you create in Visual Studio will define the underlying tables in SQL Server. In an ASP.NET MVC 4 app, this means we’ll add some class modules under the Models folder in Visual Studio Solution Explorer, as shown in Figure 4. The properties defined in the class modules will become SQL Database table structures. This approach is productive because you don’t need to worry about mapping your C#/Visual Basic objects to relational data structures. We’ll leverage the Entity Framework to simplify this object-relational mapping. The Entity Framework is an object-relational mapper that makes interacting with a relational database much easier. It allows you to perform CRUD operations with objects, instead of complex SQL statements.

Figure 4 Adding a Class to the Models Folder

To begin, select the Models folder from Solution Explorer. From the Project menu, choose Add Class. Name the class Person. Paste the following properties into the Person class (these properties will become columns in a Person table in SQL Server):

public class Person
{
  public int PersonID { get; set; }
  public string FirstName { get; set; }
  public string LastName { get; set; }
}

ASP.NET MVC 4 applications require a controller class, which acts as a bridge between the view and the model. You can think of the view as the UI and the model as the data. With a controller added, Visual Studio automatically generates the needed view classes.

Before adding the controller class, though, you need to build the solution so that the project adds the appropriate type information needed in future steps. From the Build menu, choose Build Solution. In Solution Explorer you can right-click on the Controllers folder and choose Add | Controller. The Add Controller dialog shown in Figure 5 will appear, and you’ll need to set the Scaffolding options with the following values:

1. In the Template dropdown list, select the option MVC Controller with read/write actions and views, using Entity Framework.
2. In the Model class dropdown list, select the Person class.
3. In the Data context class list, select <New data context...>. In the dialog box displayed, set the name to Person­Context and click OK.
4. In the Views dropdown list, make sure Razor is selected.
5. Click Add to complete the process.

Figure 5 Adding an MVC Controller Class

Adding the controller to the project generated all the necessary Web scaffolding so CRUD operations can be performed against a SQL Server database, resulting in the addition of several files, as shown in Figure 6. If you open the PersonController class, you’ll be able to see all the action methods that support Create, Edit, Delete and List operations.

Figure 6 Files Added

The Next Step—Deployment

As mentioned earlier, you can deploy Web Sites using continuous delivery frameworks such as Git or TFS, or simple tools like FTP or Web Deploy. In this article, we’ll use Web Deploy from Visual Studio, but you’ll find information for the rest of the deployment methodologies in the Azure Training Kit (bit.ly/Wb0EKZ).

The first step is to log on to the Azure Management Portal. To do so, sign up for a 90-day trial at bit.ly/azuretestdrive. Once you set up your account, log on with this URL: manage.windowsazure.com. Then click on the Web Sites link on the left side of the browser window. Next, click on NEW | COMPUTE | WEB SITE | QUICK CREATE and type in a desired URL, as shown in Figure 7. We used msdnmagazine, which means our site will be live at https://msdnmagazine.azurewebsites.net. You should also select a region.

Figure 7 Quick Provisioning of an Azure Web Site Deployment

At this point, your site is almost ready for deploying your content. The provisioning process is extremely quick. Once you see that the status reads “running,” you can click on the Web site name and begin to manage it. There’s also a dashboard at the portal that shows CPU time, Requests, Data Out, Data In and HTTP Server Errors.

A key step to deploying your application is to obtain the publish profile file, which contains the settings that Visual Studio will use to perform the deployment. Depending on your browser, you’ll be given the ability to download the publish profile file. You should save a copy locally so you can use it later from Visual Studio.

Configuring the Database Server

Before you can go live with your ASP.NET MVC 4 application, you need to configure the database, as shown in Figure 8. As you’ll recall, this project is using the Entity Framework Code First paradigm, which means you don’t have to worry about all the data management commands typically needed to create and initialize relational data structures. Entity Framework takes care of this.

Figure 8 Adding a Server to Host SQL Database

When you click on ADD, you’ll be asked to provide a login name and password, as well as the region where you wish to locate your Azure SQL Database deployment. It’s highly recommended you select the same datacenter where your WAWS is running, to minimize latency and avoid bandwidth charges. In our case, the login name is DBAdministrator. This can be important later if you wish to remote in or if you need to build a connection string. Also note that a server name has been provisioned for you (in our case it is ccek4yihqf). You can click on the server name to get more details from the portal (see Figure 9).

Figure 9 Server Details

An important goal here is to protect your database server information, allowing only specific IP addresses for inbound connections. Click on Configure at the top of the screen. You’ll see your current IP address, which you can then use to create a rule and connect to the server directly from that IP address.

Performing a Web Deploy from Visual Studio

We’re now ready to finalize this project by deploying it and simultaneously creating a database on the server we just provisioned. Go back to Visual Studio and select View | Solution Explorer. Right-click on MVC­Azure.WebSite and choose Publish. The Publish Web dialog box will appear. The process is wizard-based and the first step is to load the publish profile file into Visual Studio, allowing you to dramatically simplify the deployment process. You’ll go through several steps specifying the details of your publishing profile for your ASP.NET MVC 4 application, providing information about how you’d like to deploy your application inside a Microsoft datacenter, including the destination URL and the location of your Azure SQL Database server.

You can specify the Azure SQL Database server your ASP.NET MVC 4 app will use by first clicking Settings on the left side of the dialog box and then clicking on the ellipsis next to PersonContext, as shown in Figure 10.

Figure 10 Configuring the Database Connection

Now you’ll need the information you received from the portal when you created the database server. In our case, the server is tcp:siqxqgihiy.database.windows.net, as shown in Figure 11. Note that we prepended tcp at the front of the server name. You’ll also need to enter the administrator name (we entered DBAdministrator in an earlier step) and the password.

Figure 11 Connecting to the Server and Creating the Database

Clicking OK physically creates the SQL Database on the server you entered. You’ll be asked to confirm this step. Once the database is built, you can choose Publish from the Publish Web Application dialog box. To view exactly what’s taking place during the deployment, you can select View | Output window in Visual Studio.

The entire application is now finished, and you’ll find our version at msdnmagazine.azurewebsites.net/Person. Keep in mind that we hardly had to write any code at all—it took just a few minutes to accomplish something practical and polished.

What’s Next After Deployment?

Once your application has been deployed, it’s easy to accomplish tasks such as monitoring, scaling or upgrading your Web site. The first approach is to use the Azure portal, which provides an easy-to-use dashboard that can be accessed from multiple devices. Starting with version 1.8 of the Azure SDK, it’s also possible to automate some of these tasks—including management of connection strings and application settings, changing the number of instances or downloading the latest log—by using Windows PowerShell cmdlets or direct Representational State Transfer (REST) API calls.

Wrapping Up

WAWS gives you a way to deploy Web applications almost instantly—with little or no cloud experience. As your requirements grow, you can incorporate other aspects of Azure cloud technologies, such as caching, Service Bus, storage and other value-added services. Backed by Azure PaaS components, there’s no easier way to host scalable, highly available Web applications in the cloud. These features, combined with pre-built frameworks such as WordPress, Drupal, DotNetNuke, and Umbraco, allow developers to focus on building rich Web applications and data repositories, delegating the infrastructure tasks to the Azure platform.

Bruno Terkaly is a developer evangelist for Microsoft. His depth of knowledge comes from years of experience in the field, writing code using a multitude of platforms, languages, frameworks, SDKs, libraries and APIs. He spends time writing code, blogging and giving live presentations on building cloud-based applications, specifically using the Azure platform.

Ricardo Villalobos is a seasoned software architect with more than 15 years of experience designing and creating applications for companies in the supply chain management industry. Holding different technical certifications, as well as a master’s degree in business administration from the University of Dallas, he works as a cloud architect in the Azure CSV incubation group for Microsoft.

Thanks to the following technical expert for reviewing this article: Nir Mashkowski