Communication Foundation (WCF), and PHP, applications that run as independent background processes,
or applications that combine the two.
Both Windows Azure applications and on-premises applications can access the Windows Azure storage
service, and both do it in the same way: using a RESTful approach. This service allows storing binary large
objects (blobs), provides queues for communication between components of Windows Azure
applications, and even offers a form of tables with a simple query language. For applications that need
traditional relational storage, the Windows Azure platform provides SQL Azure Database, described later.
An application using the Windows Azure platform is free to use any combination of these storage options.
Running applications and storing their data in the cloud can have clear benefits. Rather than buying,
installing, and operating its own systems, for example, an organization can rely on a cloud provider to do
this for them. Also, customers pay just for the computing and storage they use, rather than maintaining a
large set of servers only for peak loads. And if they’re written correctly, applications can scale easily,
taking advantage of the enormous data centers that cloud providers offer.
Yet achieving these benefits requires effective management. In Windows Azure, each application has a
configuration file, as shown in Figure 2. By changing this configuration manually or programmatically, an
application’s owner can control various aspects of its behavior, such as setting the number of application
instances that Windows Azure should run. The Windows Azure fabric then monitors the application to
maintain this desired state.
To let its customers create, configure, and monitor applications, Windows Azure provides a browser-
accessible portal. A customer provides a Windows Live ID, then chooses whether to create a hosting
account for running applications, a storage account for storing data, or both. An application is free to
charge its customers in any way it likes: subscriptions, per-use fees, or anything else.
Windows Azure is a quite general platform that can be used in various scenarios. Here are a few
examples:
A start-up creating a new Web site—the next Facebook, say—could build its application on Windows
Azure. Because this platform supports both Web-facing services and background processes, the
application can provide an interactive user interface as well as executing work for users
asynchronously. Rather than spending time and money worrying about infrastructure, the start-up
can instead focus solely on creating code that provides value to its customers and investors. The
company can also start small, incurring low costs while its application has only a few users. If the
application catches on and usage increases, Windows Azure can scale the application as needed.
An independent software vendor (ISV) creating a software-as-a-service (SaaS) version of an existing
on-premises Windows application might choose to build it on Windows Azure. Because Windows
Azure mostly provides a standard Windows environment, moving the application’s business logic to
this cloud platform won’t typically pose many problems. And once again, building on an existing
platform lets the ISV focus on their business logic—the thing that makes them money—rather than
spending time on infrastructure.
An enterprise creating an application for its customers might choose to build it on Windows Azure.
Because Windows Azure supports .NET, developers with the right skills aren’t difficult to find, nor are
they prohibitively expensive. Running the application in Microsoft’s data centers frees the enterprise