What is the Windows Azure Platform?
Contents
In my last post I covered cloud computing by discussing the various types of Cloud offerings that exist in the internet today. These offerings are Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). Figure 1 below shows each of these offerings and what they host. Understanding what each offering hosts, the relationship of the cloud vendor to the software owner, and the relationship of the cloud vendor to the end user is a good way to understand the differences between each of these offerings.
Figure 1 – Types of Cloud Offerings and what they host
In my last post I also provided some concrete examples of each type of offering by listing actual cloud vendors. A list of all the vendors I presented is shown in Figures 2 through 4. This is not a complete list of all the players in the industry. It is just a representative sample that shows the better known offerings that I have come across in discussions with my customers.
|
Vendor
|
IaaS Offering
|
Hosting Environment
|
Storage
|
Cloud Services
|
|
Amazon
|
|
|
|
|
|
ServePath
|
|
|
|
None.
|
|
Rackspace
|
|
|
Storage is integrated with the Cloud Servers offering.
|
|
Figure 2 – IaaS Vendors
|
Vendor
|
PaaS Offering
|
Runtime Environment
|
Cloud Services
|
|
Google
|
|
|
|
|
Microsoft
|
|
|
|
|
Salesforce.com
|
|
|
|
Figure 3 – PaaS Vendors
|
Vendor
|
SaaS Brand
|
Offerings
|
|
Google
|
|
|
|
IBM
|
|
|
|
Microsoft
|
|
|
|
Salesforce.com
|
|
|
Figure 4 – SaaS Vendors
In this post I would like to focus on the Windows Azure Platform which is Microsoft’s Platform as a Service offering. I want to do this for two reasons. First, at the present time I am working for Microsoft (what can I say) and it is my job to research and describe their technologies. Second, I think there is a lot of confusion in the industry with respect to exactly what the Windows Azure Platform is all about. This confusion exists because the Windows Azure Platform is often described at too high a level or at too low a level. In my opinion it does not matter whether you are a business person or a technologist, in order to understand the Windows Azure Platform you must come in at just the right level.
I’ll attempt to find this optimal level. I’ll do this by starting off with a general discussion of what is actually meant by the term “Platform” when it is used in the context of software. Then I’ll present the Windows Azure Platform as a Software Platform in the cloud.
When the word “Platform” is used in the context of software what is really meant is what is shown in Figure 5. The best way to visualize a software platform is to think of it as being composed of two parts. The first part is a runtime environment for your application or your custom code. The second part is a collection of tools that can be purchased (as opposed to built) that solve common problems.
Figure 5 – A Software Platform
I could have added more detail to the Operating system component by showing web server capabilities, application server capabilities, and the level of abstraction that a lot of modern programming languages run upon. For example, Microsoft’s .NET Framework runs on top of a Common Language Runtime (CLR for short) and Java runs on top of what is known as a Java Virtual Machine (JVM for short). I did not show these lower level features because I want to keep my visualization simple and I did not want to burden my definition of a software platform with the details that come with these terms.
Let us look at the runtime environment and the tools in more detail and establish some metrics that can be used to evaluate a software platform.
The first piece of a software platform is the runtime environment. The runtime environment is where application code is deployed. Modern runtime environments need to do more than just execute code in today’s web oriented world. A modern runtime environment should be able to do the following:
1. Execute your code (or run your application)
2. Provide availability for every user of your application
3. Provide scalability so your application can handle increasing workloads
4. Provide reliability so that a single failure does not bring your entire application down
If your application provides capabilities that are mission critical to your business then it will have to be highly available so that when one of your employees, customers, or business partners requires its services the application will be able to readily find resources to service the request.
As your business grows your application will also have to grow in order to deal with the increase in traffic. Therefore, your application will need to be scalable. In general, there are two ways to scale an application. You can scale it up by increasing the horsepower of the hardware that your application is running upon. The other option is to scale your application out by adding more web servers and application servers. Another way to think about scalability is to think of it as the ability to add resources (compute power and storage for example) to your application without changing code and without shutting down the application.
Finally, your application should be reliable. Therefore, it should be deployed in such a way that is does not have any single points of failure. In other words your application should be running multiple instances in the event that one instance experiences a failure. Additionally, there should be multiple copies of your data in the event that a storage array fails.
In addition to a runtime environment a software platform should also provide a collection of tools that solve common problems. Tools that are common to most modern software platforms are shown in Figure 5. These tools provide the following: capabilities for authenticating/authorizing users a messaging system for processing outgoing and incoming messages; business process management (also known as workflow capabilities); a relational database for durable persistence; and tools for providing business intelligence.
The capabilities shown in Figure 5 represent core capabilities that are needed by most mission critical applications in the field today. It could be argued that there are other categories that should be in this list. (For example, document management, content management, and collaboration.) However, I chose to keep these off my list of common capabilities in order to keep my visualization of a software platform simple.
As a concrete example of a software platform, Figure 6 shows Microsoft’s on-premise software platform.
Figure 6 – Microsoft’s Software Platform
The Windows Azure Platform is a software platform in the Cloud. This is shown in Figure 7. The runtime environment is known as Windows Azure. Custom code is uploaded to Windows Azure and can be started and stopped on demand. In a cloud platform tools become services. The services that are part of the Windows Azure Platform provide the services needed for authentication/authorization, messaging, a relational database, and social networking.
Figure 7 – The Windows Azure Platform
Figure 8 below shows the marketing terms that Microsoft is using to group related services. Here we see that the Service Bus and the Access Control Service are collectively referred to as “.NET Services”. Initially, Microsoft had intended for .NET Services to contain a Workflow Service. This service was dropped from version 1 of .NET Services and will be added into a future version when it can be based on Workflow Foundation 4.0 which is a part of the .NET Framework 4.0 which is scheduled to be released sometime in the first half of calendar year 2010. Today “SQL Azure” only refers to one service which is SQL Azure Database. However, future versions of the SQL Azure will contain services for synchronizing data, reporting, and business intelligence. These new capabilities will be delivered as services under the SQL Azure brand.
Figure 8 – Marketing Terms for the Windows Azure Platform
Note: The new marketing terms shown in Figure 8 represent the new marketing terms that were introduced at Microsoft’s Worldwide Partners Conference in July of 2009. Specifically, the term “Azure Services Platform” has been replaced by the term “Windows Azure Platform”. Additionally, “SQL Services” is now known as “SQL Azure” and “SQL Data Services” is now known as “SQL Azure Database”.
The next two sections will cover Windows Azure and the Azure Services in more detail.
The runtime environment of the Windows Azure Platform is known as Windows Azure. Figure 9 shows the details of Windows Azure. A useful analogy is to compare the runtime environments of Windows Azure and on-premise operating systems (desktop operating systems and server operating systems). On-premise operating systems manage basic storage, and run applications. Windows Azure provides the same functionality within Microsoft’s datacenters which are built to provide cloud computing. Basic storage is provided by Table, Queue, and Blob storage and the Fabric Controller provides the compute power.
Figure 9 – Windows Azure
Windows Azure Blobs can be used to store data that is unstructured. Using the credentials that come with a Windows Azure Storage account a developer can create one or more containers to store related collections of blobs. Containers can be setup as either private or public. If a container is setup as public than any internet user will be able to read the blobs contained within it using the proper URL. If a container is marked as private than the secret key that comes with a Windows Azure storage account will be needed to access the blobs within the container. Additionally, if a single Blob is very large then Windows Azure provides tools to break up these large blobs into blocks so that they may be transferred to Windows Azure Blob storage more efficiently.
Windows Azure Tables provide storage for entities. The secret key that comes with a Windows Azure storage account is always needed to access Table storage. A common use for Tables is to hold data that can be associated with an application’s object model. For example, custom data types and classes that are composed of properties. Tables here should not be thought of as Relational Database tables; rather tables are merely a collection of related entities. It is important to note that there is no schema associated with a given table. Stated another way, Windows Azure Table Storage will not do any type checking when an entity is saved to a table. Any type checking that is required by an application should be performed within the application itself before being transmitted and saved into Windows Azure Tables. As a concrete example, an ecommerce application could use the same table to store both its list of Products and its customer Orders for these products. This may or may not be a good design. It will be the responsibility of the application architect to understand the requirements of the application and the capabilities of Table Storage in order to develop an efficient design.
Windows Azure Queues do not store application data. The purpose of Queues is to allow web roles and worker roles (these roles will be described later in this section) to communicate with each other. In other words, Queues can be used as a durable storage mechanism to hold tasks or actions that can occur in the background. The secret key that comes with a Windows Azure storage account is always needed to access Windows Azure Queues. Windows Azure provides all the locking and concurrency control tools needed to insure that only one worker role reads and acts on a single queue entry. In addition, these tools can also insure that a task gets put back on a Windows Azure Queue should a worker role fail half way through the processing of a task.
Windows Azure’s Fabric Controller manages a datacenter of servers to provide compute power. The Fabric Controller can be thought of as a layer that sits on top of the underlying hardware that is used to run an application. Once an application is uploaded to Windows Azure, the software owner can specify the number of instances needed for each web role and each worker role. The application can then be started and stopped on demand. In order to better understand the Fabric Controller it is necessary to describe how applications need to be structured for the Windows Azure runtime environment.
Developers will use familiar tools and programming languages to build applications for Windows Azure. However, Windows Azure is slightly different than the runtime environment within an on-premise server because availability, reliability, and scale are specified via configuration and provided for automatically by the Fabric Controller (this will be described in the next paragraph). Therefore, application code needs to be structured for Windows Azure. Figure 10 shows the basic structure of an application that is designed for Windows Azure. A web application running in Windows Azure is composed of web roles and worker roles. A web role is a component that listens for web requests and responds to web requests. A worker role performs background processing and typically receives its input from a Windows Azure Queue. In a cloud environment that is managed by a Fabric Controller the service definition file is a very important part of the application. This file indentifies all the web roles and worker roles in the application. The service definition file also specifies the number of instances of each web role and worker role that should be started. This is how availability, reliability, and scale can be achieved.
Figure 10 - Application Code built for the Windows Azure Platform
When a software owner decides to run an application on Windows Azure she will upload the application to the Windows Azure Portal and specify the number of web roles and worker roles needed and then start the application. This information is stored in the application’s Service Definition File. When the application is started the Windows Azure Fabric Controller will inspect the application’s service definition file and deploy the correct number of web roles and worker roles.
A concrete example of this process is shown in Figure 11. In this example, the service definition file specifies that an application requires two instances of its web role and two instances of its worker role to be running at all times. When the software owner starts the application the Fabric Controller would look for a place to deploy and run the two web roles and the two worker roles within Microsoft’s Cloud datacenters.
Figure 11 - Windows Azure in action
Configuring an application in this manner provides scalability. Specifically, this allows the application to be scaled out quite easily. Windows Azure will also provide scale up options. At the commercial launch of the Windows Azure Platform in November of 2009 there will be an option to specify that a role (either web or worker) should be started as a small, medium, large, or extra large instance. At the time of this writing the system specifications of each size and the cost are not known. This process also provides availability and reliability. Since there are multiple roles to services requests the application is available. Finally, the Fabric Controller can deploy roles on physical infrastructure such that a single point of failure cannot bring down all the roles that make up an application.
As can be seen from the description above, Windows Azure is not a conventional operating system with a Start menu, a Control panel, and a desktop of icons. Windows Azure is the storage services previous described and the services provided by the Fabric Controller that provide compute power to an application running in a Microsoft datacenter that is accessible via the public internet.
It would be a shame if the only capabilities available within a custom application where the capabilities implemented from the ground up by the application’s development team. As stated previously, most modern platforms provide a collection of tools whose capabilities can be easily customized and passed on as additional features of an application. Figure 12 describes the various Azure Services in modest detail and Figure 13 shows Windows Azure and the Azure Services in action together providing a rich platform for a custom application.
|
Service
|
Description
|
|
Access Control Service
|
The Access Control Service has been referred to as a Security Token Service (STS) in the Cloud. It has also been referred to as a claims transformation service in the Cloud. The truth is that the Access Control Service is both. Cloud applications will often be dependent on many different user directories. The Access Control Service can take Security Tokens from different Security Token Services and transform these tokens into another token which represents a common format that can be recognized and processed by an application.
|
|
Service Bus
|
Service Bus is a relay service that allows two applications to talk to each other even if they are separated by firewalls and Network Address Translation (NAT) devices. To accomplish this, the Service Bus has a naming system, a service registry, and a messaging system. The Service Bus messaging system supports a variety of message exchange patterns such as request/response, one way, and publish-subscribe. The Service Bus is also capable of negotiating direct connections when it is possible for the communicating parties to exchange message directly with each other.
|
|
SQL Azure Database
|
SQL Azure Database is a relational database management system in the cloud. To a developer it will be utilized the same way that a conventional relational database is utilized. Familiar tools with be used to design and support a database. Also the Tabular Data Stream (TDS) protocol will be used to communicate with SQL Azure Database. Two features that will not be available in SQL Azure Database are the SQL Common Language Runtime and support for Spatial Data.
|
|
Live Services
|
Using Live Services custom applications can access data from Windows Live Applications such as Hotmail, Messenger, Contacts, and Calendars and other Live Applications such as Search and Maps. Additionally Live Services will provide tools such as the Live Framework, the Live Operating Environment and Live Mesh that will allow this data to be accessed easily from any programming environment and kept synchronized between desktops, laptops, and devices.
|
Figure 12 – Description of the Azure Services
Figure 13 – Windows Azure and the Azure Services together
It is important to note here that the Azure Services shown here are not just tools for applications running within Windows Azure. Each service can be consumed individually through the internet by applications running on-premise inside an organization’s datacenter. This is shown in Figure 14. Additionally, Microsoft intends to make the Service offerings of the Windows Azure Platform more robust over time by improving the existing services and adding additional services.
Figure 14 – On-Premise plus Cloud
Understanding the Windows Azure Platform is not hard. As presented in this post, the best way to start is to understand exactly what is meant by the term “Platform” when it is used in the context of software capabilities. A “Software Platform” can be visualized as the combination of a runtime environment and a collection of tools that solve common problems.
The Windows Azure Platform is a Cloud Platform. Windows Azure is the runtime environment and the Azure Services (Access control, Service Bus, SQL Azure Database, and Live Services) are cloud tools or cloud services that solve common problems.