In this article, Neil Mackenzie looks at where Windows Azure fits among the various cloud computing offerings in the wild today, and also at the four key areas of Azure that new developers will need to be aware of when they start their first project.
Modern cloud computing offerings can be differentiated by the kind of services they offer. Typically these services fall into three categories and vendors may provide one or more of them
- Infrastructure as a Service (IaaS) provides basic hardware as a service. For example, virtual machines, load balancer settings, and network attached storage. You can liken it to server virtualization but without the hardware in your offices.
- Platform as a Service (PaaS) provides not just the computing power of IaaS but also runtime environments for your compiled application code and abstractions around common services such as email and caching. Windows Azure for instance, offer PHP and .NET runtimes. Google’s App Engine supports Java and Python.
- Software as a Service (SaaS) offers hosted instances of a vendor’s applications to a client. For instance, a company may choose to outsource their Human Resources applications to salesforce.com who will give them access to a hosted instance of their software.
You’ll find a much deeper discussion of the difference between IaaS, PaaS and SaaS in “Understanding Public Clouds: IaaS, PaaS & SaaS” by Keith Pijanowski at Keith’s own site.
Windows Azure is Microsoft’s Platform as a Service offering. Its first community technology preview (CTP) was officially launched by Ray Ozzie in the Day 1 Keynote at PDC 2008, and the v1.0 release was made available at PDC 2009. Development continues around it apace with the Azure SDK and Visual Studio Toolset now at version 1.4 while builds of additional tools such as the Azure Traffic Manager are released fast and frequently for our benefit. Similarly the suite of middleware services grouped under the Azure AppFabric continues to evolve with the Caching element having been released to the web in April 2011.
In this article, we’ll provide an overview of the features in Windows Azure and thus what it provides.
Windows Azure Compute
Windows Azure Compute is the heart of Windows Azure, providing the online processing time and hosting environments for your applications in the cloud. It is exposed through hosted services deployable as a package to an Azure datacentre. This package 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. More on roles in a moment.
Each instance is hosted in a virtual machine (VM) providing a guaranteed level of compute – cores, memory, local disk space – to the instance. Based on your application requirements, you subscribe to a Compute instance representing a virtual server with a given specification, as shown in Table 1. 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 on a shared infrastructure is currently in beta.
|Compute Instance Size||CPU||Memory||Instance Storage||I/O Performance||Cost per hour|
|Extra Small||1.0 GHz||768 MB||20 GB||Low||$0.05|
|Small||1.6 GHz||1.75 GB||225 GB||Moderate||$0.12|
|Medium||2 x 1.6 GHz||3.5 GB||490 GB||High||$0.24|
|Large||4 x 1.6 GHz||7 GB||1,000 GB||High||$0.48|
|Extra Large||8 x 1.6 GHz||14 GB||2,040 GB||High||$0.96|
Table 1: Windows Azure Compute Instance Specifications and Pricing
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 definition 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, recycles it and spins 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 start-up 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 start-up task is a script that runs on instance start-up 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 or worker role possible using start-up tasks and elevated privileges are insufficient. An example would be where the installation of an application in a start-up 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.
Note that the VM Role is currently in beta.
Data Storage Options
Windows Azure provides supports various forms of permanent storage with differing capabilities.
- The Windows Azure Storage service provides cost-effective storage for up to 100 terabytes per storage account.
- SQL Azure provides a hosted version of SQL Server scaling up to 50 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, tables and VHDs.
- Azure Blob supports the storage of blobs (Binary Large Objects, such as text or images) 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.
- Azure Drive uses a blob containing an appropriately created virtual hard disk (VHD) 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.
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 two factor authentication involving the storage account name and key.
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
- Windows Azure AppFabric Caching service
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 attempt a best attempt survival upon instance recycle but it does not survive instance reimaging. The Windows Azure AppFabric Caching service essentially provides a managed version of the Windows Server AppFabric Caching service (Velocity). 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 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 between one and five 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 (custom) 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 load balanced.
The Windows Azure AppFabric Service Bus provides a way to expose web services through a public endpoint in a Windows Azure datacentre 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 datacentre. 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 datacentre. 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 (ACS) provides support for federated authentication and authorization for RESTful web services. The preview version, currently in the Windows Azure AppFabric labs, promises to be 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 the preview ACS can be consumed by a web role and used to support claims-based authentication to websites it hosts.
The Windows Azure Portal, shown in Figure 1, 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.
Figure 1: The Windows Azure Management Portal
The Windows Azure Service Management REST API exposes all of the functionality of the Windows Azure Portal for managing hosted services and Windows Azure Storage service storage accounts with the exception of account creation. Indeed, the Windows Azure Portal calls the REST API to do what it does.
- The Windows Azure Service Management Cmdlets provide a wrapper for Powershell users 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.
- The Portal UI also continues to be developed as new Azure features either come into CTP or full release. Figure 1 shows v2 of the portal.
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 here.
This article is derived from a blog post of the same title written by Neil Mackenzie. You can find the original post here.