In my day job at Satory Global I spend a lot of time educating people about the Windows Azure Platform and helping them develop applications on the platform. In my book, the Microsoft Windows Azure Development Cookbook, I provided instructions for how to perform about 80 or so specific tasks when developing for the Windows Azure Platform. In this blog, I tend to write posts focused on a specific Windows Azure feature or API. In a post about a year or so ago I described the Windows Azure Platform as it was then. In this post I am going to describe the Windows Azure Platform as it is now, showing how the recently announced infrastructure-as-a-service (IaaS) features complement the platform-as-a-service (PaaS) features that have traditionally defined Window Azure.
The post is organized around the four core features of any cloud service offering:
The Windows Azure Platform provides three distinct compute models:
- Windows Azure Web Sites
- Cloud Services
- Virtual Machines
Windows Azure Web Sites
Windows Azure Web Sites provides a multi-tenanted, high-density hosting environment into which web sites can be deployed and upgraded in a matter of seconds. Web Sites provides a hosting environment for ASP.NET websites as well as web sites developed in Node.js, PHP and Python. Applications can be deployed using git, FTP or TFS. Windows Azure hosts a git repository to facilitate the use of git. Web Sites supports the horizontal scalability of web sites from a single instance of a shared web site up to 3 instances of a dedicated 4-core large instance. This scalability can be managed directly on the portal.
The ease-of-use of Windows Azure Web Sites is enhanced by the provision of a gallery on the Windows Azure Portal allowing the easy creation of web sites implemented in content-management systems such as WordPress. The portal also exposes monitoring information such as CPU time, number of requests, and data out for web sites.
Cloud Services is the new name for the traditional hosted service PaaS offering on Windows Azure. A Cloud Services application is described through a service model which specifies the server types (or roles) comprising the application. There are three types of role: web role, worker role and VM role. Although there used to be a significant difference between a web role and a worker role, they are now pretty much the same with the primary difference being that IIS is preconfigured on a web role. A VM role allows a Windows Server 2008 virtual machine to be uploaded as a cloud service. However, the capabilities of a VM role have been superseded by the much more functional Virtual Machines, so VM role should now be regarded as deprecated (even if not officially).
A web role or worker role is a scalability unit for a Cloud Service. A web role or worker role is deployed as a multiple instances with each instance being hosted in a virtual machine (VM) with a specified number of cores, and associated RAM and local storage. Windows Azure supports various instance sizes from small with 1 core through extra-large with 8 cores. The other compute resources – RAM, local storage and network I/O – scale linearly with the number of cores. Windows Azure also supports a low-cost, extra-small instance providing a fraction of a core. The number of instances of a web role or worker role is specified in the service model configuration making it easy to elastically scale the number of running instances. It is this ability to scale elastically to satisfy current demand that provides one of the primary cost drivers of the cloud computing.
The role instances deployed in Cloud Services are stateless which means that there is no durability guarantee on any information written to the drives attached to the virtual machine hosting the instance. The role instance does have some local storage that survives reboots, and re-images where the application bits are reset to their original state on the instance, but it does not survive migrations when the instance is moved to another physical server as a consequence of the Windows Azure self-healing process. Cloud Services supports the Azure Drive feature in which a role instance can mount, as an NTFS drive, a VHD stored as a page blob in Windows Azure Blob Storage to provide durable storage for the instance.
Cloud Services is a PaaS offering and both web roles and worker roles are best thought of as application hosting environments. Microsoft is responsible for ensuring the physical health of the hosting environment and performs automatic self-healing when problems are found. This can include the automatic migration of a role instance to another server when problems are found with the physical hardware. Windows Azure provides various automated upgrade techniques, including in-place upgrades and VIP swaps, that come into play during an OS or application upgrade to ensure the continued availability of the application.
Windows Azure performs much of the post-deployment management of the application but the developer must remain aware that the application is deployed to a managed environment and must hook into the environment as necessary. Cloud Services supports startup tasks which can be used to ensure the correct configuration of the runtime environment for an instance. This includes installing any software required by the instance. Windows Azure provides Windows Azure Diagnostics which can be used to capture diagnostic information – including performance counters, trace logs, and custom logs – and then persist them to Windows Azure Storage where they can then be accessed. This minimizes the need to access individual role instances, although Remote Desktop can be used if necessary.
The PaaS model, of Window Azure Web Sites and Cloud Services, is ideal for green-field development. It can provide significant operational benefits for migrated applications, but with an increased development cost to handle integration with the application hosting environment. However, there are many workloads which can not be migrated into a PaaS environment or which can be migrated only at significant development cost that mitigate the operational benefits.
An IaaS model provides an attractive setting for these difficult-to-migrate workloads since the hosting environment is the OS level not the application level. However, this ease of migration comes with a significantly increased operational cost. Of course, much of this cost would have been present regardless of whether the application was hosted in IaaS in the cloud or in an on-premises datacenter.
Microsoft has now released into preview an IaaS model named Windows Azure Virtual Machines. This significantly increases the types of workload that can be hosted in a Windows Azure datacenter. For example, Virtual Machines supports the deployments of applications hosted in Linux which allows many open-source applications developed for Linux to be deployed to Windows Azure. Michael Washam has an excellent post describing the features of Virtual Machines.
The Windows Azure Portal exposes a gallery of Virtual Machine types that can be deployed directly using the portal or management scripts. This gallery includes various Windows Server offerings as well as several different Linux distributions. One of the offerings in the gallery is a pre-configured SQL Server 2012 virtual machine. It is anticipated that Microsoft will offer additional server offerings directly on the portal, such as SharePoint, as well as other Linux distributions. Furthermore, other companies such as RightScale and Suse are providing Virtual Machine configuration and management services simplifying the configuration and deployment of specific Virtual Machine instances.
In Virtual Machines, the OS drive and any associated data drives are stored in Windows Azure Blob Storage as VHDs persisted in page blobs in Windows Azure Blob Storage. These drives are durable so that any information written to them survives instance failures and self-healing migrations. They are similar to the Azure Drives used in Cloud Services. However, in Cloud Services the drives must be attached by code running on the instance while in Virtual Machines the drives are attached either automatically, for the OS drive, or externally by using the Windows Azure Portal or service management scripts.
Windows Azure provides various forms of persistent storage with different characteristics. The Windows Azure Storage Service provides cost-effective, high-scale storage that can scale up to the petabyte level (when multiple storage accounts are used). The Windows Azure SQL Database (formerly called SQL Azure) provides a managed version of SQL Server 2012. Between them these services support a wide variety of storage capabilities including large file storage, NoSQL and relational. Both Windows Azure Storage and SQL Database are shared multi-tenant systems with performance characteristics impacted by this multi-tenancy.
The Windows Azure Storage Service provides three features: blobs, tables and queues. Note that the Storage Service stored 3 local copies of all data and, unless configured otherwise, makes 3 copies asynchronously to a remote datacenter. The Storage Service always uses strongly consistent writes and does not use eventual consistency.
The Blob Service supports the storage of files in two types of blob: block blobs and page blobs. A block blob is targeted at streaming media with the primary access mechanism being a read from the start to the end of the file. A page blob is targeted at random access with the primary use case being as the backing store for the VHD used in Azure Drive with Cloud Services or as the attached OS or data drive with Virtual Machines. The Table Service is a kev-value, NoSQL store for the durable storage of schema-less entities. The Queue Service provides a simple message queuing service intended for disconnected communication among role instances and virtual machines.
The Windows Azure SQL Database is a managed relational database based on and providing most of the functionality of SQL Server 2012. SQL Database is a multi-tenant system in which application databases are deployed into a managed SQL Server instance. For high availability, SQL Database stores a primary and 2 secondary copies of each database. SQL Database uses a quorum commit for writes.
SQL Database is a multi-tenanted system with performance characteristics that differ from a standalone SQL Server database. SQL Database Federations provides a managed sharding capability that supports high scale both for performance and data for SQL Database. Each individual federation member database provides the performance and data scale characteristics of an individual database so that in aggregate a complete federation can provide very high scale and throughput. Essentially, SQL Database Federations provides horizontal scaleout of data to match the horizontal scaleout that role instances provide for compute.
Windows Azure provides several non-durable storage options directly on virtual machines. In Cloud Services, each role instance has some amount of local storage available on the C: drive that applications can use. This local storage persists as long as Windows Azure does not migrate the role instance to another physical server as part of the server healing process. In Virtual Machines, each virtual machine has a local D: drive primarily used for the page file. This drive does not survive the virtual machine being migrated to another physical server.
It also provides two distinct caching mechanisms: the Windows Azure Caching Service and the Windows Azure Caching. The Caching Service is essentially a managed version of the Windows Server AppFabric Caching Service hosted in a Windows Azure datacenter. It provides centralized caching with a local on-machine caching option. The Caching Service also supports the caching of ASP.NET session state. Windows Azure Caching, currently in preview, allows a ring cache to be created using spare memory of Cloud Service role instances either in an existing role or a worker role specifically created to host the cache. All instances of the cache-configured role participate in this cache.
Windows Azure supports various forms of connectivity:
- Virtual Network
- Windows Azure Connect
- Windows Azure Traffic Manager
- Windows Azure Service Bus
Cloud Services and Virtual Machines both use endpoints to manage the internal IP addresses and ports they expose. There are various types of endpoint depending on whether or not they are exposed to the public internet and on the way in which traffic is directed to them. The endpoints are defined at the role level for Cloud Services and at the service level for Virtual Machines. A Load Balancer Probe can be associated with each endpoint and used to verify that role instances or virtual machines hosting the endpoint are available and, if not, remove them from load balancer rotation. Unless contained in a Virtual Network, a Cloud Service or a Virtual Machine service is a security boundary that can be accessed only through one of the public endpoints. Windows Azure supports both TCP and UDP for internal and external network traffic.
Cloud Services have two types of (public) input endpoint – input endpoint and instance input endpoint – and one type of (private) internal endpoint. These endpoints are associated with individual roles . The input endpoints differ with respect to how the load balancer handles traffic. For an input endpoint, the load balancer uses a round-robin algorithm to direct inbound network traffic to each role instance in turn. For an instance input endpoint, the load balancer uses port forwarding to direct inbound network traffic to a specific role instance. An instance endpoint is used to allow intra-service traffic within a Cloud Service. The Windows Azure Service Runtime API provides methods allowing the actual IP addresses and ports used by these endpoints to be discovered at runtime.
Virtual Machines support two types of public endpoint – Load Balanced and Port Forwarded. The load balancer uses round-robin load balancing to handle traffic directed to a Load Balanced endpoint and port forwarding to direct traffic to a Port Forwarded endpoint. Windows Azure does not restrict traffic internal to a Virtual Machine service so there is no need for an endpoint like the internal endpoint of Cloud Services.
The advent of Virtual Machines drives a need for more sophisticated network architectures than was needed when there was only Cloud Services. Be default, a Virtual Machines service and a Cloud Service form distinct security boundaries traffic can flow between them only through a public endpoint. The new Virtual Network capability allows the creation of a virtual network that supports the composition of disparate services into a larger service in which the security surface can be minimized. For example, a virtual network can be created to contain a Virtual Machine hosting SQL Server with no public endpoint and a Cloud Service with an HTTP public endpoint exposed by a web role.
Windows Azure supports two types of VPN connectivity. Virtual Networks provides a robust hardware-based site-to-site VPN capability allowing for hybrid solutions that span both on-premises services and services hosted in Windows Azure. This is an IT-focused offering requiring configuration of on-premises VPN hardware. Windows Azure Connect is an software agent based VPN that developers can use to provide a simple connection between on-premises machines and Cloud Services. The software agent is available only for Windows which limits the utility of Windows Azure Connect.
The Windows Azure Traffic Manager provides load-balancing capability for public HTTP endpoints in a Cloud Service or a Virtual Machine service. It supports 3 types of traffic distribution: geographical in which traffic is directed to the server with the least latency from the current location; active-passive failover where the traffic is failed over to a passive backup service when the active service fails to respond to probes; round-robin load balancing between multiple services.
The Windows Azure Service Bus provides 2 ways for services to communicate with each other: Relayed Messaging and Brokered Messaging. These facilitate the composition of services in a service oriented architecture.
In Relayed Messaging, a service and a client both connect using outbound connections to a Service Bus endpoint hosted in a Windows Azure datacenter. The Service Bus then welds these connections together allowing two-way communication between the client and the server, both of which could be hidden behind firewalls restricting inbound traffic.
In Brokered Messaging, a Service Bus endpoint in a Windows Azure datacenter hosts a durable message store supporting various publish/subscribe scenarios. The most basic is when the endpoint hosts a Queue with multiple senders sending messages and multiple consumers competing to receive messages. Brokered Messaging also supports a Topic/Subscription model comprising a topic to which messages are sent and one or more subscriptions which receive filtered copies of the messages. Each subscription has its own set of subscribers, which compete for the messages in the subscription.
The Windows Azure Portal can be used to manage the various features provided by Windows Azure. This exists in two versions providing somewhat different functionality: the old Silverlight portal providing almost complete management of traditional Cloud Services and Storage Services; and a new HTML5 portal supporting Virtual Machines and Virtual Networks. The intent is that all existing functionality will be migrated to the HTML5 portal.
The portals are GUI front-ends for the Windows Azure Service Management REST API. This can be used to manage Cloud Services, Virtual Machines, and Storage Services accounts. There are two different sets of PowerShell cmdlets that can be used to manage Windows Azure services: CodePlex cmdlets developed by Microsoft DPE; and the new cmdlets supported by the Windows Azure Product Group. The CodePlex cmdlets are no longer being developed but contain some functionality not yet exposed in the official cmdlets, although that will presumably change. Additionally, there are also command line interface (CLI) scripts for the Mac and Linux that, being written in Node.js, also run on Windows.
A number of companies have developed tools for managing and monitoring Windows Azure Services and Storage. Cerebrata, now part of Red Gate, has the very useful Cloud Storage Studio which can be used to provide Explorer-like functionality for the Windows Azure Storage Service. AppDynamics provides monitoring and scaling services for applications hosted in Windows Azure.
Next Steps for Developers
You can sign up for a 90-day free trial of Windows Azure by going to https://www.windowsazure.com/en-us/pricing/free-trial/. This provides free access to all the features described in this post – obviously with limits on the amount of resources provided. The next step for .NET developers is to download the Windows Azure SDK for .NET from the .NET Developer Center. There are similar landing pages for Node.js, Java, PHP, and Python developers.