We’re very pleased to announce that Roberto Brunetti’s new book Windows Azure Step by Step (344 pages; Print ISBN: 978-0-7356-4972-9) is now available.
Windows Azure offers developers the chance to extend their application development experience to the cloud. Teach yourself how to build and host scalable applications using Windows Azure—one step at a time. This tutorial provides practical, learn-by-doing exercises for working with the core services and features of the Windows Azure platform. Discover how to:
· Extend your existing skills to the cloud development model
· Build a simple web role application and deploy it to the cloud
· Create a worker role project to perform backend processes
· Store persistent data with Windows Azure Storage
· Develop a scalable database application in the cloud using Microsoft SQL Azure™
· Connect several cloud-based applications with Windows Azure AppFabric
· Design a multitiered solution that can scale to meet user demand
Windows Azure(TM) Step by Step is available through retailers now. Enjoy this excerpt from Chapter 2, “Introduction to the Windows Azure Platform,” to get a solid introduction to the major features of Azure.
Introduction to the Windows Azure Platform
After completing this chapter, you will be able to
- Understand the basic workings of the Windows Azure platform.
- Create a service.
- Understand Worker Roles.
- Understand Virtual Machine Roles.
- Describe the purpose and architecture of Windows Azure AppFabric.
- Know how SQL Azure fits into the overall picture.
Chapter 1, “Introduction to Cloud Computing,” discussed the general concepts and ideas that underlie Microsoft’s cloud computing platform and infrastructure. The following excerpt from the Windows Azure website (Microsoft Corporation, Windows Azure website, 2011, http://www.azure.com) describes how the Windows Azure platform meets the needs of developers. The first two sentences recall what Chapter 1 explained: you pay only for what you use, scale up when necessary, and scale down according to business needs. This is true for every component of the platform:
Building out an infrastructure that supports your web service or application can be expensive, complicated and time consuming. Forecasting the highest possible demand. Building out the network to support your peak times. Getting the right servers in place at the right time, managing and maintaining the systems.
Or you could look to the Microsoft cloud. The Windows Azure Platform is a flexible cloud–computing platform that lets you focus on solving business problems and addressing customer needs. No need to invest upfront on expensive infrastructure. Pay only for what you use, scale up when you need capacity and pull it back when you don’t. We handle all the patches and maintenance — all in a secure environment with over 99.9% uptime.
The chapter you are reading now focuses on the Windows Azure platform, starting with the operating system, and describes the way Microsoft is choosing to respond to the rise of cloud computing. It provides an overview of the major Windows Azure platform components. You see what these components are and how each functions to help you deliver and manage cloud applications.
In the next chapter, you create a simple application that takes advantage of the Windows Azure platform’s scalability feature. You also publish that simple application to the cloud using the project portal.
The Operating System
The most important component of the platform is Windows Azure, the operating system created for the cloud. Like all operating systems, its purpose is to provide an abstraction from the physical hardware components and a set of services that every application can use. In other words, Windows Azure has the same role as a traditional operating system on any hardware platform.
It also has many similarities to—as well as many differences from—a traditional file system. Unlike a traditional operating system such as Windows 7, which abstracts a single box with its CPU, hard disks, keyboard, mouse, and graphics cards, Windows Azure abstracts a set of servers, providing a common platform for building services and applications in a completely virtual environment. In this environment, you work with servers, but you do not install the application on server A or server B; you deploy an application, but not on a specific disk C or D; and you do not have to configure the network card or the virtual directory to expose your services.
Like traditional operating systems, Windows Azure exposes a way to store data, called local storage. However, this storage doesn’t consist of physical hard disks nor is it a traditional network share such as \\servername\sharename. Instead, Windows Azure provides shared storage. It provides CPU power—but not just the processors you can see when you open the case of a physical server. In fact, no one can see the actual disks or machines that host a Windows Azure solution; you just upload the application to the environment and let Windows Azure choose the best servers, disks, and load balancing strategies for a particular solution. You can describe your application’s needs in a logical way. For example, you can request 1 GB of local disk space to cache remote resources, but you cannot force Windows Azure to deploy your solution on a specific disk or server. You can specify that your application needs to listen for HTTPS requests on port 443, but you cannot configure the IP address of the virtual node.
You can’t install the current version of Windows Azure locally, but you can use a local development environment that simulates the cloud version of Windows Azure so that you can test your solutions before deploying them. Window Azure is not a product you can find in a shrink-wrapped software box on the shelf in some store, and there’s no demo version you can download and try out on your local server. Everything is in the cloud. At the time of this writing, Microsoft is slated to release the Windows Azure appliance, and describes it like this: “The Windows Azure platform appliance consists of Windows Azure, SQL Azure and a Microsoft-specified configuration of network, storage and server hardware. This hardware will be delivered by a variety of partners” (Microsoft Corporation, Windows Azure website, 2011, http://www.microsoft.com/windowsazure/appliance/default.aspx).
As you learned in the previous chapter, the main advantages of this cloud-only approach are:
- You do not have to configure hardware, drivers, system components, or the operating system.
- You do not need an inbound Internet connection.
- You do not have to install and configure your own router, firewall, or obtain public IPs; consequently, you do not need network configuration expertise.
- You do not need to apply patches or monitor the system for hardware or software failures.
- Microsoft monitors and maintains the system 24 hours a day so that you don’t have to do it on your own.
- The load balancer configuration is logical, not physical.
- You pay for services you need for a defined period of time. During high-use peaks, you can increment the number of ”servers” simply by changing a number.
- You do not need to precisely dimension your hardware and buy it in advance.
Window Azure takes care of all these aspects for you. It can manage services automatically, basing its decisions on a completely logical configuration. You provide a set of rules that the Windows Azure “brain” (called fabric) follows to deploy your solution. This set of rules is called the model; it is a logical description of an application’s configuration in the cloud.
Windows Azure uses the term service to identify every piece of code that can be exposed and used. For example, an ASP.NET application, a while-block that dequeues some messages, and a Windows Communication Foundation (WCF) service are all services. Each service can be hosted in the platform on different servers. Each server, or more precisely, each node, is based on Windows Server 2008 R2, so virtually any code that can run on-premises can run in the cloud as well.
The hosting environment is distributed on different nodes that are hosted by servers. Each server is part of a server collection that resides in a container. The container is like a big shipping container that you can see on the tops of barges and freight trains, and it is placed in a data center by plugging in a giant cable that provides network connectivity and electrical power. From this point on, Windows Azure takes care of everything. When you deploy a solution, you do not have to use a remote desktop to connect to one of these servers—in fact, you don’t even have to know the name of the machine. Instead, you use the simple web interface shown in the following figure.
Completing this dialog box is the only task you have to do to deploy a solution and, as you can see, there is no physical component to configure. Microsoft Visual Studio builds the two files that the dialog box requests (Application Package and Configuration File) to deploy a service in the cloud automatically every time you create a cloud project. You will learn how to create a cloud project in Chapter 3, “Creating a Web Role Project.”
The Application Package file is the result of compiling your cloud project. It contains the code that Windows Azure will deploy to every node. The Configuration Settings file equates to what I called a model earlier in this chapter. The simplest form of a model is shown in Listing 2-1.
This basic service model contains the configuration for a service, called DevLeapCloudService, that will be deployed to one node of the cloud (one of the virtual servers) as specified by the Instances element value.
As you can see, there is little in this configuration except for names and an instance count: you do not have to configure the IP address, create a virtual directory, copy the application files to the relative path on some remote disk, configure read access to that directory, and so on. You just create a service using the portal, and upload the binaries and the configuration file. You see how to do that in the next procedure.
To create a service that hosts some code, you have to create a new hosted service. You create that service from the main page of the portal (after logging in with a valid Windows Live ID).
1. Open the browser of your choice and go to http://www.azure.com.
From this page, you can access useful information about the platform as well as the major links to the SDKs, as shown in the following figure.
2. You need to buy a subscription before you can work with Windows Azure. Click the Sign Up Now link or the Try link and choose the plan that best suits your needs.
If you just want to test the product, the portal provides some discounted offers at the time of this writing. These subscriptions might be a perfect opportunity to test your solutions in the cloud. Note that most MSDN subscriptions can also include Windows Azure platform subscriptions. I suggest reviewing all the offers available.
3. After you activate your subscription, return to the home page, shown in the following figure.
Three links on the right side of the page take you to the various portals. The Windows Azure Developer Portal is the one you need to create your first Windows Azure Service. You learn more about the SQL Azure and AppFabric Portals and components later in this chapter.
4. Click on the Sign In To The Management Portal link to open the Management Portal. After logging on using your Windows Live credentials, you find the Getting Started page shown in the following figure.
5. On the Getting Started page, click Hosted Services, Storage Accounts & CDN to manage your services. The home page for managing services is shown in the following figure.
6. Click the New Hosted Service icon on the toolbar to create your new service. Assign the name Demo to the project and type a URL prefix for your service, as shown in the next figure. The URL prefix represents the Public Service Name for your service. The name you supply must be globally unique. The portal checks the availability of the name as you write.
The service name is just a logical name and has no relevance during deployment. In practice, the label is useful for finding a service in the service list shown in the previous image and in the relative treeview menu.
7. Choose a region to host your service. You can select any region where Microsoft has a data center for Windows Azure. This option lets you host your code in a data center in your local region or in the region closest to your users.
8. In the Deployment Options section, select the Do Not Deploy option and click the OK button. (Don’t worry about completing the other text boxes for now.) You now have a new hosted service. The next figure shows the user interface for managing a deployed service.
Congratulations! You created a hosted service in which you can deploy your solution using the easy procedure described at the beginning of this chapter. You also uploaded the binaries and the configuration file—that is, the model that describes the application’s requirements. Chapter 3 is dedicated to explaining how to create the binaries and model using Visual Studio.
To review, to create a new solution, you have to:
- Create a hosted service providing the name of the Service, the public URL, and the region.
- Upload the cloud service package (the binaries) and the configuration file.
You learned that Windows Azure is an operating system and that it completely hides the physical details of the data center, servers, disks, and virtual directories. Because you don’t need to worry about any of those aspects, you can deploy a solution with just two clicks.
Figure 2-1 shows you my Windows Azure subscriptions and projects.