Windows Azure is the Platform-as-a-Service offering (PaaS) from Microsoft. Like other cloud services it provides the following features:
Windows Azure Compute is exposed through hosted services deployable as a package to an Azure datacenter. A hosted service provides an organizational and security boundary for a related set of compute resources. It is an organizational boundary because the compute and connectivity resources used by the hosted service are specified in its service model. It is a security boundary because only compute resources in the hosted service can have direct connectivity to other compute resources in the service.
A hosted service comprises a set of one or more roles, each of which provides specific functionality for the service. A role is a logical construct made physical through the deployment of one or more instances hosting the services provided by the role. Each instance is hosted in a virtual machine (VM) providing a guaranteed level of compute – cores, memory, local disk space – to the instance. Windows Azure offers various instance sizes from Small with one core to Extra-Large with eight cores. The other compute parameters scale similarly with instance size. An Extra-Small instance providing a fraction of a core is currently in beta.
A role is the scalability unit for a hosted service since its horizontal and vertical scaling characteristics are specified at the role level. All instances of a role have the same instance size, specified in the service model for the hosted service, but different roles can have different instance sizes. However, the power of cloud computing comes not from vertical scaling through changing the instance size, which is inherently limited, but from horizontal scaling through varying the number of instances of a role. Furthermore, while the instance size is fixed when the role is deployed the number of instances can be varied as needed following deployment. It is the elastic scaling – up and down – of instance numbers that provide the central financial benefit of cloud computing.
Windows Azure provides three types of role:
- Web role
- Worker role
- VM role
Web roles and worker roles are central to the PaaS model of Windows Azure. The primary difference between them is that IIS is turned on and configured for a web role – and IIS is sufficiently privileged that other web servers cannot be hosted on a web role. However, other web servers can be hosted on worker roles. Otherwise, there is little practical difference between web roles and worker roles.
Web roles and worker roles serve respectively as application-hosting environments for IIS websites and long-running applications. The power of PaaS comes from the lifecycle of role instances being managed by Windows Azure. In the event of an instance failure Windows Azure automatically restarts the instance and, if necessary, moves it to a new VM. Similarly, updates to the operating system of the VM can be handled automatically. Windows Azure also automates role upgrades so that instances of a role are upgraded in groups allowing the role to continue providing its services albeit with a reduced service level.
Windows Azure provides two features supporting modifications to the role environment: elevated privileges and startup tasks. When running with elevated privilege, an instance has full administrative control of the VM and can perform modifications to the environment that would be disallowed under the default limited privilege. Note that in a web role this privilege escalation applies only to the process hosting the role entry point and does not apply to the separate process hosting IIS. This limits the risk in the event of a website being compromised. A startup task is a script that runs on instance startup and which can be used, for example, to ensure that any required application is installed on the instance. This verification is essential due to the stateless nature of an instance, since any application installed on an instance is lost if the instance is reimaged or moved to a new VM.
The VM role exists solely to handle situations where even the modifications to a web role or worker possible using startup tasks and elevated privileges are insufficient. An example would be where the installation of an application in a startup task takes too long or requires human intervention. Deployment to a VM role requires the creation and uploading of an appropriately configured Windows Server 2008 guest OS image. This image can be configured as desired up to and including the installation of arbitrary software – consistent with any licensing requirements of that software. Once deployed, Windows Azure manages the lifecycle of role instances just as it does with other role types. Similarly to the other role types, VM roles host applications – the difference being that for a VM role the application is a Windows Server 2008 guest OS. For VM roles, it is particularly important to be aware of the statelessness of the instance. Any changes to an instance of a VM role are lost when the instance is reimaged or moved.
Windows Azure provides supports various forms of permanent storage with differing capabilities. The Windows Azure Storage service provides cost-effective storage for up to 100s of terabytes. SQL Azure provides a hosted version of SQL Server scaling for up to 10s of gigabytes. It is very much the intent that applications use both of these, as needed, with relational data stored in SQL Azure and large-scale data stored in Windows Azure Storage. Both Windows Azure Storage and SQL Azure are shared services with scalability limits to ensure that all users of the services get satisfactory performance.
The Windows Azure Storage Service supports blobs, queues and tables. Azure Blob supports the storage of blobs in a simple two-level hierarchy of containers and blobs. Azure Queue supports the storage of messages in queues. These are best-effort FIFO queues intended to support the asynchronous management of multi-step tasks such as when an image uploaded by a web role instance is processed by a worker role instance. Azure Table is the Windows Azure implementation of a NoSQL database supporting the storage of large amounts of data. This data is schemaless to the extent that each entity inserted into a table in Azure Table carries its own schema.
The definitive way to access the Azure Storage Service is through a RESTful interface. The Windows Azure SDK provides a Storage Client library which provides a high-level .NET wrapper to the RESTful interface. For Azure Table, this wrapper uses WCF Data Services. Other than to Azure Blob containers and blobs configured for public access, all storage operations against the Azure Storage Service are authenticated.
With Azure Drive, a blob containing an appropriately created virtual hard disk (VHD) can be used to provide the backing store for an NTFS drive mounted on a compute instance. This provides the appearance of locality for persistent storage attached to a compute instance.
SQL Azure is essentially a hosted version of Microsoft SQL Server exposing many but not all of its features. Connections to SQL Azure use the same TDS protocol used with SQL Server. Individual databases can be up to 50GB in size. The storage of larger datasets can be achieved through sharding (the distribution of data across several databases) which can also aid throughput. Microsoft has announced the development of SQL Azure Federation services which will essentially automate the sharding process for SQL Azure. All operations against SQL Azure must be authenticated using SQL Server authentication.
Windows Azure also supports two types of volatile storage: local storage on an instance and the Windows Azure AppFabric Caching service (in production soon). Local storage for an instance can be configured in the service model to provide space on the local file system that can be used as desired by the instance. Local storage can be configured to survive an instance recycle but it does not survive instance reimaging. The Windows Azure AppFabric Caching service essentially provides a managed version of the Windows AppFabric Caching service. It provides the core functionality of this service including central caching of data with a local cache providing high-speed access to it. The Windows Azure AppFabric Caching service also supports directly the caching of ASP.Net session state for web roles.
Windows Azure supports various forms of connectivity;
- Input endpoints
- Internal endpoints
- Windows Azure AppFabric Service Bus
- Windows Azure Connect
A hosted service can expose one or more input endpoints to the public internet. All input endpoints use the single virtual IP address associated with the hosted service but each input endpoint uses a different port. The virtual IP address assigned to the hosted service is unlikely to change during the lifetime of the service but this is not guaranteed. All access to an input endpoint is load-balanced across all instances of whichever role is configured to handle that endpoint. A CNAME record can be used to map one or more vanity domains to the domain name of the hosted service provided by Windows Azure. These vanity domains can be handled by a web role and used to expose different websites to different domains.
An internal endpoint is exposed by instances of a role only to other instances inside the same hosted service. Internal endpoints are not visible outside the service. These endpoints are not role balanced.
The Windows Azure AppFabric Service Bus provides a way to expose web services through a public endpoint in a Windows Azure datacenter and consequently avoid compromising a corporate firewall. The physical endpoint of the service can remain private and, indeed, can remain behind a corporate firewall. The Windows Azure AppFabric Service Bus can be configured to attempt the fusion of the client request to the public endpoint with the services connection to the public endpoint and thereby allow a direct connection between the client and the service.
Windows Azure Connect supports the creation of a virtual private network (VPN) between on-premises computers and hosted services in a Windows Azure datacenter. This allows for hybrid services with, for example, a web role exposing a website where the backing store is a SQL Server database residing in a corporate datacenter. This allows a company to retain complete control of its data while gaining the benefit of using Windows Azure hosted services for its public-facing services. Windows Azure Connect also facilitates the remote administration of instances in a hosted service. Note that Windows Azure Connect is currently in CTP.
Connectivity brings with it the problem of authentication. The Windows Azure AppFabric Access Control Service v1 provides support for authentication for RESTful web services. The newly released Windows Azure AppFabric Access Control Service v2 is much more interesting and provides a security token service (STS) able to transform claims coming from various identity providers including Facebook, Google, Yahoo and Windows Live Id – as well as Active Directory Federation Services. The claims produced by ACS v2 can be consumed by a web role and used to support claims-based authentication to websites it hosts.
The Windows Azure Portal can be used to manage the compute, storage and connectivity provided by Windows Azure. This includes the creation of hosted services and storage accounts as well as the management of the service endpoints required by the Windows Azure AppFabric Service Bus and Caching service. The Windows Azure Portal also supports the configuration of the Windows Azure Connect VPN.
The Windows Azure Service Management REST API exposes much of the functionality of the Windows Azure Portal for managing hosted services and Windows Azure Storage service storage accounts. The Windows Azure Service Management Cmdlets provide a wrapper to this API. Cerebrata has several useful management tools for Windows Azure including Cloud Storage Studio for managing the blobs, queues and tables hosted by the Windows Azure Storage service. SQL Server Management Studio can be used to manage SQL Azure databases.
Next Steps for Developers
The first step is to go to the Get Started page on the Windows Azure website and download the Windows Azure SDK. You can then try Windows Azure for free by going to http://www.microsoft.com/windowsazure/free-trial/. This gets you a 90-day pass to try out Windows Azure by providing 750 compute hours per month and a 1GB SQL Azure databases as well as connectivity and Windows Azure Storage.