Chapter 1

Introduction to Windows Azure and Fundamental Concepts

IN THIS CHAPTER:

• The role of Windows Azure Web Sites and how it may find a place in your workflow
• An introduction to the Windows Azure Management Portal in the context of a website developer
• The basics of creating a simple site
• How application state management differs from IIS
• Setting deployment credentials

References to “the cloud” seem to be everywhere. Targeted developer advertisements, corporate messaging, and even consumer marketing have all been invaded by this new use of a common word. You can’t drive by a bank of city billboards or walk down the corridor of an airport terminal without seeing mention of cloud computing in some form. Heck, by the end of this book, “cloud” won’t even sound like a real word anymore!

Indeed, at this point in the Internet’s history, it’s almost impossible to have any kind of Internet presence without being “in” the cloud, even if you were unaware of it. The most popular mail services have all been cloud-based for some time, as have music and movie services. Nearly every smartphone vendor offers some kind of cloud feature set that it tries to leverage as a marketing point to distinguish itself from the competition. Even the latest versions of document- and photo-editing software have built-in cloud features, or are themselves built on top of the cloud fabric. It’s not surprising that the same can be said about our operating systems as well.

By now you have likely wrestled through some of what it means to be “in” the cloud — perhaps you’ve even tried to host an application or two on a cloud server. However, neither marketing blurbs from vendors nor water cooler talk about the “cloud” among developers will answer all your questions. This book will guide you, as a web developer, from the initial steps of creating a website in the cloud to some of the more advanced operations you will need to manage a successful application. However, before diving into what the cloud means to the solution you’re creating, first take a moment to understand what the cloud is not, then circle back to what the cloud is and how it can work for you. I’ll keep this short, and I’ll make no attempt to sugar coat it. The cloud is not right for all scenarios. It isn’t an assurance that your app will scale without issue, nor does it fix any bugs. It should not be viewed as the go-to solution when, for myriad other reasons, you’re having trouble keeping your app up to the expectations of your users. It does not automatically make your app more performant, more popular, or more profitable.

“Great,” you’re thinking, “now what?”

Don’t worry. The cloud still offers quite a few benefits to kick around, especially as they relate to web developers. For example, one more thing the cloud doesn’t do is throw away everything you’ve learned about development to date! Recent advancements in the developer experience have made it much easier to get started. It’s relatively simple to hook into a variety of continuous integration systems, and deployment is straightforward. You can tie into other cloud features such as storage, content distribution networks, identity, and caching without having to overhaul your app, and the flexibility to scale is also possible. You don’t have to perform any significant amount of server admin to get a website turned on, and you can start applying your skills as a .NET web developer by simply clicking File New Project.

To paint a picture: At this point you’re a web developer who has an idea about what the cloud is and what it’s not. The following sections dive deeper to give a more expansive, detailed picture of how Windows Azure Web Sites will fit into your toolkit.

UNDERSTANDING WINDOWS AZURE WEB SITES

There have been a lot of promises made about how cloud computing will change the software developer’s life. To sort the chaff out, it’s useful to step back and assess what you have grown accustomed to as you build, deploy, and manage websites. In that vein, let’s remove cloud and Azure from the conversation for a moment, and define some of the main aspects of web development to which you have likely become accustomed to throughout your career. As a starting point, this discussion assumes that you have worked with “traditional” deployments to a server that you or your company owns and manages.

What are the advantages of running your own server? First of all, you have the freedom to pick whatever operating systems and languages you’ll use and how you’re going to implement them. Second, you can manage files at a low level, working right against the file system. Third, you have the capability to connect to databases from whichever vendor or open-source offering you choose — and speaking of open source, it’s easy to kick-start a project using myriad templates, including CMS, blogging, shopping cart, payment processors, or other project templates available from the developer community. These are all valuable assets in your developer arsenal and they enable you to remain flexible as you address your clients’ requirements.

However, I would be remiss to not identify the ramifications of running one’s own server, and certainly we need to understand these implications as developers. First and foremost are the costs. If you’re going to run your own server you must pay for the metal, the physical presence (whether on- or off-premises), and the bandwidth. There are also costs associated with power, cooling and Internet connectivity. You might even be inclined to purchase a great server, to allow for scaling.

But with good hardware alone are you really ready? Who’s going to maintain the security patches? How will you handle load balancing? What if you want to incorporate a service bus layer, or improve performance overseas if your website takes off in Asia or Europe? You also have to consider redundancy, security, and caching; and even if you get all that right, when it’s time to scale you will have to buy more hardware. I don’t argue that having your own server in place isn’t without its freedom, but it doesn’t guarantee that you’ll be home free!

Your website isn’t going to write itself, so it would be great if the aforementioned list of potential limitations were available without the consequent list of costs and responsibilities. And this is exactly where Windows Azure Web Sites comes into play. It essentially removes the operating system and physical hardware of a traditional server from the equation while adding robustness and scalability. Well played, Windows Azure, well played.

Though you will have opportunity to scale later, the default configuration of a Windows Azure Web Site is the equivalent of a website you would create in IIS. There is a chunk of file system set aside for your app, and a portion of memory and processor utilization are sliced off for your application. A host header and corresponding DNS entry are aligned with the site so that you can start browsing right away. Your website is simply a set of files on a file system. Sounds familiar, doesn’t it?

To the point of this topic, you need to know where the Web Sites product fits into the spectrum of Windows Azure offerings. If you have previous experience with cloud computing, you know there are many different approaches you can take; and with previous Windows Azure experience, you may choose to spin up a compute instance and walk through some deployment preparation and configuration.

Another approach would be to set up a VM with IIS running on it — but that parallels running on a server you own, and all the responsibilities noted earlier fall back on you!

Windows Azure Web Sites do indeed fall into the category of “compute,” but they are now highlighted as a separate execution model. This model enables you to share IIS on a VM with other websites, each in its own app domain, and eventually scale up to a dedicated virtual machine or a bank of 10 virtual servers, each of which has 4 cores and 7GB of memory. You definitely have options.

UNDERSTANDING THE WINDOWS AZURE PORTAL

You’re already aware that Windows Azure provides much more than just a way to deploy and manage websites, so it will come as no surprise to find a lot more tooling on the Windows Azure Portal than what you require to manage your application, but once you are comfortable with the layout you’ll find that most options you need are fairly close at hand.

The main area of the window presents a list of all items on your account from all the feature areas, as shown in Figure 1-1. A command bar is located along the bottom, which updates itself to present options relevant to the area or item you’ve selected.

FIGURE 1-1

Selecting a feature from the left navigation pane, such as Web Sites, presents the list of items filtered to that feature, as shown in Figure 1-2, which helps you quickly find whatever items you may be looking for in a particular category. Note that the left navigation pane collapses into its icon representation to give you more real estate in the window as you select a particular item.

FIGURE 1-2

In addition to creating more real estate, selecting an item from the list by clicking on its name will take you to the dashboard for managing that item. Alternatively, you can select a row by clicking elsewhere on the row to highlight it, then use the context menu at the bottom of the screen to perform some of the basic state management commands that you may be familiar with from IIS. These operations and other related commands are described in detail later in this chapter, but first you’ll need to create a site in order to display them in your portal.

CREATING A SIMPLE SITE

With Web Sites selected (the globe in the left-hand navigation menu), you can create a basic site by following these steps:

1. Click the New button in the context menu at the bottom of the screen. A fly-out menu will appear with three options for creating an Azure Web Site: Quick Create, Custom Create, or From Gallery, as shown in Figure 1-3.

FIGURE 1-3

2. Click Quick Create, which exposes a panel to name your site, as I’ve done. Pick a unique name by filling in the URL field and click the Create Web Site button to create your site.

In Figure 1-3, you’ll see a Region field that can also be provided. Microsoft provides a number of different regions in which your Azure Web Site can be created. As a general rule, select the region that is geographically closest to the people who you expect to use your website. However, the complete answer is not that simple. There are a couple of potential ramifications of your choice. The first is that you can have a maximum of 10 free Web Sites in any region. If you have 10 active free Web Sites in a single region, you will have to create your eleventh (and subsequent) Web Site in a different region.

The second potential consideration relates to the scalability of a Web Site. As will be covered in Chapter 7, “Scaling, Configuring, and Monitoring Your Site,” there are three levels of scalability supported by WAWS: Free, Shared, and Reserved. When you upgrade a Web Site to Reserved, then all of the Web Sites in the same region are also upgraded. As a result, when you determine the region in which your Web Site is being created, keep in mind whether you expected it to always be “free” or to grow into “reserved” at some point in the future.

You’ll need to wait a few moments while Windows Azure spins up your website. Each new site creation process entails several stages, none of which require administrator interaction — namely, creating, deploying, and running.

After completion of the latter stage, you’ll see your website in the portal.

3. Click on the URL to launch it in a separate window. If you see the message shown in Figure 1-4 when you click the link, congratulations!

FIGURE 1-4

This default site won’t win you any awards for web design and functionality, but it will serve as a proxy while you learn the essentials of managing a site. In Chapter 8, “Deploying and Configuring a Cloud Application,” you’ll look at an Azure Web Site with a little more oomph. This fledgling application will help you explore many of the real-world scenarios that most developers encounter as they grow their site.

MANAGING YOUR SITE FROM THE PORTAL

This section examines the management options in a little more detail. To follow along, you’ll need to navigate to the dashboard of your site by walking through the following steps:

1. Close any browser windows that were opened when you were exploring the site you created in the previous section. Leave open the window containing the Windows Azure Management Portal.

2. Click the globe icon or Web Sites item in the left navigation pane. This will take you to the filtered list of websites that you have created.

3. Click the name of the website you just created to be taken to the dashboard for your site, which contains some options for getting started, as shown in Figure 1-5.

FIGURE 1-5

As mentioned earlier, the menu will collapse, giving you a little more working space in the portal. You can also easily switch between any websites you have created on your account, as the menu title area is converted to a list of the Web Sites that are part of your subscription.

Working with Notifications

As you carry out operations on the site, the portal does a pretty good job of keeping you up to date. Any list of the items in your account contains a status column for each row, which is updated in real time.

Figure 1-6 is an illustration of the working indicator in action. The icon lights up in the bottom-right corner of the portal, adjacent to the help icon (the question mark, seen in the bottom right corner of Figure 1-5). This icon lets you know that Windows Azure is working on completing an operation you started, even if you navigate to a different page in the portal.

FIGURE 1-6

Clicking the working indicator icon causes a progress panel similar to the one shown in Figure 1-7 to appear. The panel will contain relevant bits on the progress of the operations in your queue, and even more information can be exposed by clicking on the “detail” link in the panel. As commands transit through state to completion or error, you can track them here.

FIGURE 1-7

Modifying Application State

At this point, the menu at the bottom of the screen (see Figure 1-8) reflects the context of the selected site, displaying the state management options available for your application. This menu is referred to as the command bar or the “drawer.” The commands you see here are always in the context of your current work area.

FIGURE 1-8

Keep in mind that having this context to the available operations will mean that sometimes an operation may not appear in the drawer. For example, the Start and Stop commands are only present when the site is either stopped or started, respectively.

• Stop — Prevents new requests from accessing the application and spins down the site. All outstanding requests are terminated. Take note, as this is different than the default behavior for Internet Information Services (IIS).
• Start — Prepares the web site for the first incoming request, but does not authoritatively start the site. Application initialization occurs when the first request reaches the website.
• Restart — Performs a stop operation followed by a start operation. Outstanding requests are terminated, the app domain is unloaded, leaving your application in a ready-to-start state. This is effectively the same as performing separate stop and start operations.

Performing Other Application Operations

Continuing with the command bar at the bottom of the screen, take a look at these other operations (see Figure 1-9) as they pertain to the context of your site, depending on your site configuration.

FIGURE 1-9

• Browse — Opens the website in a new browser window (or tab). If your application is “cold,” it may take a moment to start. This operation has the technical side effect of changing your application’s state when in the “ready” but not “started” state, as it counts as a first request to your site.

  ---

  NOTE

  WAWS has two types of “cold” states. The first is the type that many ASP.NET developers are used to in IIS. After a period of inactivity (typically 20 minutes), IIS will shut down the process that handles the requests for a particular website. The first subsequent request will cause the process to restart, but will typically take a little longer than average to process.

  The second type of “cold” state occurs when a Web Site is deactivated due to inactivity. This is done to help preserve the quotas that Windows Azure imposes on Free and Shared mode Web Sites. As with the IIS “cold” state, there will be a delay when the first request is received. However, because the Web Site needs to be reactivated, it will actually take even longer than the IIS warm-up time.

  ---

• Manage Domains — Reveals a popup window that enables you to configure which domains are associated with the current website. Note that you have to perform some additional steps in order for this feature to be enabled, which are covered in Chapter 7, “Scaling, Configuring, and Monitoring Your Site.” When your site is properly configured, this command item will appear, as was shown in Figure 1-2.
• Web Matrix — Opens the Azure Web Site locally for editing in the WebMatrix Integrated Development Environment (IDE). If you don’t have the IDE installed, it will be bootstrapped as part of this operation. The website files are downloaded from Windows Azure to your local file system and you can edit the site locally before pushing any changes.

Deleting a Site

As a careful reader who has been closely inspecting all the wonderful artwork in the book and reading attentively, you likely noticed that I did not mention the Delete button in the previous set of commands. That’s because there is a little more going on with delete — it’s worth noting separately, as this is one of the marked differences from hosting a website on your own server.

Remember that your Azure Web Site is very much like what you would have on IIS; there’s an entry on a virtual machine somewhere that serves requests to your clients, and a set of files that are referenced as part of the configuration. Unlike your traditional IIS deployment, however, your web site has a number of other details attached to it that are also deleted when you delete the site. These details extend beyond the standard configuration of a website in IIS and include the DNS entries, related host headers and logs, as well as post-deployment configuration that you may have set up, such as connection strings, application settings, or the scaling options of your site. Among the most important of these attached details are the files that make up your application and enable your site to tick. When you delete a site on Windows Azure Web Sites, all your application files are gone for good.

Setting Your Deployment Credentials

Although you have already logged into the portal and tied your Microsoft Account to your Azure subscription, certain deployment procedures in this book require a different set of credentials. This is because some protocols (such as FTP) and third-party providers (such as Git) do not support Microsoft Accounts.

You can configure your subscription-wide username and password through the “Reset deployment credentials” link from the dashboard of any Windows Azure Web Site. As shown in Figure 1-10 the link appears under the quick glance section of the page.

FIGURE 1-10

Selecting this link allows you to originally set and subsequently reset your credentials as required, as you can see in Figure 1-11.

FIGURE 1-11

SUMMARY

At first blush Windows Azure Web Sites may just look like another hosting option for your website — with options and management features that will be familiar to most developers working on the .NET stack. While it has its familiarities, it also has the benefit of not being tied to a specific piece of hardware, and the ability to leverage other aspects of cloud computing down the road, particularly scalability and high availability.

This chapter’s coverage of the Azure Portal should enable you to create and locate sites, and access the site management commands, with confidence.

Managing the state of your site is probably a familiar concept, and you have seen how Azure compares to a more traditional hosting environment. Although the differences in how you create and delete sites are relatively minor, you do need to be aware of them, and which pieces of your configuration will be affected as you perform certain operations.