Which component of Microsoft Azure provides services to connect on premise applications with those in the cloud?

9.3.3 Windows Azure platform appliance

The Windows Azure platform can also be deployed as an appliance on third-party data centers and constitutes the cloud infrastructure governing the physical servers of the datacenter. The Windows Azure Platform Appliance includes Windows Azure, SQL Azure, and Microsoft-specified configuration of network, storage, and server hardware. The appliance is a solution that targets governments and service providers who want to have their own cloud computing infrastructure.

As introduced earlier, Azure already provides a development environment that allows building applications for Azure in their own premises. The local development environment is not intended to be production middleware, but it is designed for developing and testing the functionalities of applications that will eventually be deployed on Azure. The Azure appliance is instead a full-featured implementation of Windows Azure. Its goal is to replicate Azure on a third-party infrastructure and make available its services beyond the boundaries of the Microsoft Cloud. The appliance addresses two major scenarios: institutions that have very large computing needs (such as government agencies) and institutions that cannot afford to transfer their data outside their premises.

Confidentiality

Windows Azure provides data confidentiality via identity and access management, isolation, and encryption. The identity and access management mechanism adopts service management API (SMAPI) to provide web services via the Representational State Transfer (REST) protocol, which runs over SSL and is authenticated with a certificate and private key generated by the customer. Windows Azure does not grant customers with administrative access to their VMs. By default customer software is restricted to running under an account with low privilege. By this, the level of attack will be reduced. Communication between Azure internal components is always protected with SSL and via mutual authentication. To assure data confidentiality, Azure provides isolation at different levels: hypervisor, root OS, guest VM, and fabric controller. Customer access infrastructure is also logically isolated from customer applications and storage. Critical internal stored or transmitted data can be encrypted with the .NET Cryptographic Service Providers (CSPs) provided by the Azure SDK. Azure's storage subsystem provides data deletion operations for customers. If the execution of a data delete operation is successful, all the references to that associated data item are removed and the data will not be accessible via the storage APIs.

Service Level Agreements (SLAs)

Windows Azure has separate SLAs for the storage, compute, CDN and App Fabric components. The reader is referred to Chapter 3 of this book for more details of these components. For compute, Microsoft guarantees that when customers deploy two or more role instances in different fault and upgrade domains, the web roles will have external connectivity at least 99.95% of the time. Additionally, Microsoft guarantees that 99.9% of the time corrective action will be initiated when the fabric controller detects that a role instance is down. Similarly on the storage front, Microsoft guarantees that at least 99.9% of the time correctly formatted requests to Windows storage for adding, updating, reading and deleting data will be processed correctly. Requests that are throttled because the application does not obey back-off principles and requests that fail because of application logic (like creating a container that already exists) are not considered to be failures of the service.

For SQL Azure, Microsoft guarantees a Monthly Availability of 99.9% during a calendar month. Monthly Availability Percentage for a specific customer database is the ratio of the time the database was available to customers to the total time in a month. Time is measured in 5-minute intervals in a 30-day monthly cycle. Availability is always calculated for a full month. An interval is marked as unavailable if the customer's attempts to connect to a database are rejected by the SQL Azure gateway.

Uptime percentage commitments and SLA credits for Service Bus and Access Control are similar to those specified previously in the Windows Azure SLA. Due to inherent differences between the technologies, underlying SLA definitions and terms differ for the Service Bus and Access Control services. Details are available in the App Fabric SLA [8]. The latest versions of the list of committed Windows Azure SLAs are maintained at [9].

PaaS Providers

The number of PaaS providers in the market continues to grow. First we take a look at Windows Azure.

Windows Azure

Windows Azure, shown in Figure 4.10, was one of the first PaaS offerings to hit the market. Windows Azure has a free offering and upgraded offerings that include features such as increased SLAs. Windows Azure makes it very easy to spin up a Web site or development platform. Windows Azure includes a wide variety of options such as compute services, data services, app services, and network service.

Figure 4.10. Windows Azure

Google App Engine

Google App Engine is a PaaS solution that enables users to host their own applications on the same or similar infrastructure as Google Docs, Google Maps, and other popular Google services. Just as Microsoft Azure provides a platform to build and execute .NET applications, Google App Engine enables users to develop and host applications written using Java, Python, and a new language called Go.6 The platform also supports other languages that use Java Virtual Machine (JVM) runtime, such as JRuby, JavaScript (Rhino), and Scala programming languages.

The applications hosted on Google App Engine can scale both in compute and storage, just like other Google products. The platform provides distributed storage with replication and load balancing of client requests. The applications can be easily built using the Eclipse Integrated Development environment with which many developers are familiar. This section gives a simple overview and key highlights of the platform.

Getting Started

Step-by-step instructions for using Google App Engine are described here, based on the procedure available as of the writing of this book.7 The developer first signs up for a Google App Engine account using his or her Gmail credentials. Figure E4.5 shows the first screen when the application is being configured.

Figure E4.5. Google App Engine: Application configuration.

Google App Engine allows a newly developed application to be served from the developer’s own domain name. For example, if the developer chooses myapp as an application name, the application will be served at http://myapp.appspot.com. This URL can be shared publicly or selectively shared with a small group of members. Every developer can host up to 10 applications for free, with 500 MB of complimentary storage. The developer needs to pay a nominal amount for the storage and bandwidth resources used by the application beyond these limits. A simple dashboard showing the usage metrics for each application can be seen on the portal, a screenshot of which is shown in Figure E4.6.

Note

Developing and Deploying on Google App Engine1.

Download the SDK (Eclipse plug-in).

2.

Create a new “Web Application Project.”

3.

Configure the application.

4.

Develop code.

5.

Test in simulated App Engine environment.

6.

Deploy to Google App Engine.

Figure E4.6. Application dashboard of Google App Engine.

Developing a Google App Engine Application

To develop Java applications, the App Engine software development kit (SDK) needs to be installed. The SDK is an Eclipse plug-in (Figure E4.7) that includes build, test, and deployment environments and is available at http://dl.google.com.eclipse/plugin/3.x. To get started, create a new project as a Web Application Project; right-click the project name and select Google in the preferences and enter a valid application ID for the project. After developing (programming) the application, during the deployment stage we need to specify an app ID for the application. To deploy onto the App Engine, similar to creating the application, simply right-click on the project name and select the Deploy to App Engine option, and the application will be uploaded onto the App Engine and will be deployed.

Figure E4.7. Google App Engine Eclipse plug-in.

Another interesting option during application configuration is an option to create a Google Web Toolkit (GWT) application. GWT basically allows us to create interactive applications with drag-and-drop facility to author a custom graphical interface. The toolkit then automatically converts the UI portion into JavaScript with AJAX8 (asynchronous) calls to access the backend logic on the server. Note that since JavaScript runs within a browser (client side) and AJAX provides a nonblocking way of accessing the back end, the overall effect is a good experience with quick response for interactive applications. A skeleton code for GWT can be created using the following command:

webAppCreator -out myFirstApp com.cloudbook.myFirstApp

The developer can also check the Generate GWT Sample Code option during application creation to create a default Greeting project (Figure E4.8). If this option is unchecked, we could write our own Java servlet code and deploy it on the App Engine, as discussed earlier. So, literally any Web application written in Java can be deployed on the App Engine.

Figure E4.8. Google App Engine App deployment.

The SDK comes with a local Web server for test deployment. This local Web server simulates the secure runtime or App Engine sandbox environment with limited access to the underlying operating system. For example, the application can only be accessed using HTTP on specific ports. It cannot write to the file system and can read only files that were uploaded along with application code. An additional restriction with the sandbox environment is that the application, when accessed over HTTP, should return a response code within 30 seconds. These restrictions are mainly to prevent one application from interfering with another.

Windows Azure Runtime Environment

The Windows Azure runtime environment provides a scalable compute and storage hosting environment along with management capabilities. It has three major components: Compute, Storage and the Fabric Controller.

As depicted in Figure 3.16, Windows Azure runs on a large number of machines, all maintained in Microsoft data centers. The hosting environment of Azure is called the Fabric Controller. It has a pool of individual systems connected on a network and automatically manages resources by load balancing and geo-replication. It manages the application lifecycle without requiring the hosted apps to explicitly deal with the scalability and availability requirements. Each physical machine hosts an Azure agent that manages the machine – starting from boot up, installation of the operating system and then the application, application monitoring during its execution, and finally even attempting to fix the system if the agent detects any problems. Compute and storage services are built on top of this Fabric Controller. Note that the Fabric Controller is not the same as the AppFabric – the former manages machines in the cloud, while the latter provides services to connect on-premise applications with those in the cloud.

The Azure Compute Service provides a Windows-based environment to run applications written in the various languages and technologies supported on the Windows platform. While any Windows-compatible technology can be used to develop the applications, the .NET framework with ASP.NET has the greatest tool and library support. Like most PaaS services, Windows Azure defines a programming model specific to the platform, which is called the Web role-Worker role model. This model was briefly referred to in the simple “Hello World” example and will be further detailed in The Azure Programming Model section later in this chapter.

The Windows Azure storage service provides scalable storage for applications running on the Windows Azure in multiple forms. It enables storage for binary and text data, messages and structured data through support for features called Blobs, Tables, Queues and Drives. The distinction between these types of storage is described in the section Azure Storage Services. For applications that require simple SQL-based access to traditional relational databases, SQL Azure provides a cloud-based RDBMS system. These are described later in this section.

Figure 3.17 shows a bird's-eye view of the internal modules of the platform. At the heart of the system are the storage and compute clusters – vast numbers of machines kept in Microsoft data centers. These machines, the operating systems running on them, and applications are managed by the Fabric Controller. The external interface of the Azure system consists of a set of REST APIs that perform service management and give users access to the storage system.

4.4.2.7 ACS Management Portal

The ACS Management Portal is launched through the Windows Azure Management Portal. The ACS Management Portal is used to configure most aspects of your ACS environment. The portal allows you to configure IdPs, relying parties, rule groups and rules, certificates and keys, service identities, portal administrators, and the ACS Management Service. Most of these components are covered in other sections. The exception is portal administrators. So we will cover them a little bit here.

When you create your ACS namespace, it is created with only one administrator account. This is the account that was used to create the namespace. The portal administrator section of the ACS Management Portal allows you to grant administrative access to a designated namespace within ACS to users from a particular IdP.

CloudCmp Results

CloudCmp [20] presents the result of a comparison between AWS, Windows Azure, Google App Engine, and CloudServers in an anonymized fashion, where the 4 providers are listed as C1 through C4 instead of being named. The following are some of the results presented in the paper.

Elastic Compute Cluster: CloudCmp [20] lists the instance types provided by each provider, their cost per hour, as well as their benchmark finishing time. The conclusion is that the price performance of the different providers varies greatly. For example, C4.1 (the first instance type offered by vendor C4) is reported to be 30% more expensive than C1.1 but twice as fast). When comparing the cost to run each benchmark, it was found that the smallest instance of the cloud providers was the most cost-effective. Additionally, it was found that scaling latency was below 10 minutes for all providers, with some providers achieving latency less than 100 seconds. Linux instances were found to be created faster than Windows instances.

Persistent Storage: Table storage was tested with both a small table (1K entries) and a large table (100K entries) for all the providers other than C2, which did not have a table service. All table services were found to have large variations in response time. As an example, across all the providers, the median of the response time was 50 ms, while the 95th percentile was twice as large at 100 ms. In terms of scaling, all the providers were found to scale well (no degradation in response time) with up to 32 parallel threads. In terms of the inconsistency time, all providers other than C1 were found to not have any inconsistency. C1 provided an API option to force strong consistency which was found not to have much impact on latency. However, without the strong consistency option, C1 was found to have an inconsistency window of 500 ms (if the 99th percentile of inconsistency times is taken). Cost per operation was found to be comparable across all providers.

Blob download times were measured with small (1KB) blobs and large (10MB) blobs. Again, only three of the service providers were considered, since C3 did not offer a blob service. With small blobs, all providers other than C2 were found to show good scaling performance (up to 32 concurrent downloads), with C4 being the best. With large blobs, C4 and C1 were found to continue to scale better; however, C1 had the best performance. Study of the maximum throughput suggested that in the case of both C1 and C2, the intra-cloud network was the performance bottleneck, since the maximum achievable throughput was close to the intra-cloud network bandwidth.

E-Commerce web site: CloudCmp [20] presents a projection of the performance of TPC-W, a benchmark for transactional web services that uses an e-commerce site to generate the workload. The benchmark was modified to remove JOIN and GROUP operations, since these are not in the table service. The projection, based on CloudCmp, predicted that C1 should offer the lowest response time. This was verified by actually running the benchmark, which confirmed that cloud provider C1 had the lowest response time.

Other results comparing the intra-network latency and WAN latency of the service providers, as well as projections of their performance for various applications such as Blast, can be found in CloudCmp [20].

NoSQL Systems: Key-Value Stores

After the previous discussion on scaling relational databases, this section describes alternatives to relational databases. These alternatives were originally motivated by the desire to overcome the perceived constraints of relational databases that prevented scaling [19]. These include greater decentralization leading to greater reliability (i.e., avoiding the tight synchronization between replicas characteristic of databases), and a simplified interface compared to SQL. This subsection describes key-value stores, which simply store key-value pairs, and the only query interface is to use the key to get the corresponding value. XML document databases are described in the next section.

The rest of this section describes various well-known key-value stores. It can be seen that these have certain common features. First, the main API used for access is storage or retrieval of a value on the basis of a key. Second, the key-value stores offer automatic scaling by horizontally partitioning the store based on the value of the key. Thus sharding is an in-built feature of the key-value stores.

HBase

HBase, which is part of the Hadoop project, is one of the important scalable NoSQL technologies. For example, it is used in Facebook messaging, and handles about 135 billion messages per month [20]. HBase was selected for many reasons, including scalability and a simple consistency model [21, 22, 23]. In the following, HBase usage is described first, followed by a description of the techniques used by HBase to scale to cloud levels.

HBase usage: HBase is a key-value store that is an open source implementation of the ideas in Google's BigTable [24]. It is part of the Hadoop project, and as can be seen later in this chapter, is tightly integrated with Hadoop MapReduce (introduced in chapter 3 and described in detail later in this chapter). HBase can be considered as a datastore that keeps tables such that each row is indexed by a key. However, HBase is unlike relational databases, where the columns are the same for each row (and are specified by the database schema). In HBase, the columns in each row can vary. This is achieved as follows: when creating the row, the value of each column is specified as {column name, value} pairs. The column name consists of two parts – the column family and the qualifier. The column family is used for vertical partitioning of the database; recall the discussion in the section Scaling Storage: Partitioning about vertical partitioning being one of the partitioning methodologies that can increase scaling of databases. HBase stores different column families in different files. This is very valuable for performance tuning; multiple columns with the same column family are stored in the same file, and stored or retrieved together. Thus putting related columns in the same column family improves performance. Additionally, whenever a key is assigned a value, the old value is not overwritten. Instead, the new value is appended to the database with a timestamp. Periodically, a compaction process that deletes old timestamps is run. The number of old versions that should be retained can be specified.

Figure 5.6 illustrates these concepts. It can be seen that the table has 5 rows. There are two versions of the row with key value A at times T1 and T2. Row A at T1 had two columns – CF1:Q1 and CF1:Q3. These are in the same column family. However, it had only 1 column at time T2. Rows B and C have the same format as each other but different columns from row A. Row D has the same format as row A.

Figure 5.6. HBase data layout.

To make the concepts behind HBase use clearer, the following shows how HBase can be used to implement part of the Pustak Portal example given previously. The code samples in this section show how to insert transactions in the transaction table, and find transactions for a customer. It is assumed that a transaction table for holding the Pustak Portal transaction data (see section Example: Pustak Portal Data) has been created in HBase. The table is assumed to be named transTable, and it was created with a column family called transactionData for holding the transaction data. Note that the actual columns, which contain the transaction data values, have not been specified at the time of creation.

Connecting to HBase transaction table

 import org.apache.hadoop.hbase.HBaseConfiguration;

 import org.apache.hadoop.hbase.HTable;

 class transTableInterface {

 HBaseConfiguration HBaseConfig = new HBaseConfiguration(); // A

 HTable transTableConn = new HTable(HBaseConfig,"transTable");//B

 }

The code snippet shows how one can connect to the transaction table. It is assumed that class transTableInterface contains all the procedures for interacting with the transaction table. The variable HBaseConfig is automatically initialized in statement A with the connection parameters for HBase, which have to be stored in files hbase-site.xml or hbase-default.xml in the CLASSPATH [25]. Statement B stores the connection parameters to the transaction table in transTableConn.

Inserting a new transaction in HBase transaction table

import org.apache.hadoop.hbase.client.*;

class transTableInterface {

 public static insertRow (int transNum, int CustomerId, int BookId, float salePrice) {

 Put row = new Put (BytestoBytes (new Integer (CustomerId).toString() + "@" + new Integer (transId).toString())); // A

 row.add (Bytes.toBytes ("transactionData", Bytes.toBytes (new Integer (CustomerId).toString()));

…

 transTableConn.put (row); // C

}

The preceding sample code shows how to insert a new transaction into the transaction table. The method insertRow inserts a new transaction into the table. Statement A creates a new row object with the transaction id as a key. Since HBase is a key-value store, the transaction id has to be encoded into a single key. Here, the transaction id is encoded into a string of the form @. Statement B adds the column transactionData:BookId to this row with the value given by BookId. Similar statements are needed to add the salePrice. These statements are omitted for brevity. Statement C finally inserts the row into the table. A default timestamp is provided, since there is no timestamp explicitly specified.

The rest of this section describes how to find all the transactions for a customer. Since HBase does not support secondary indexes, it is not possible to search the transaction table using the customer id. One possible method would be to maintain a table of customer ids and transaction ids, look up this table to find all the transaction ids for a customer, and then look up the transaction table to find the transactions. This is equivalent to maintaining a secondary index on customer ids in the application. However, this requires an extra query to lookup the transaction ids. The following is a method that finds the transactions directly from the transaction table. A modified version of this technique can be used to maintain and search a table of transaction ids and customer ids, if so desired.

FINDING ALL TRANSACTIONS FOR A CUSTOMER IN TRANSACTION TABLE

import org.apache.hadoop.hbase.client.*;

class transTableInterface {

 public static ResultScanner findCustTrans (int CustomerId) {

 Scan CustIdScan = new Scan(); // A

 RowFilter CustIdFilter = new RowFilter (CompareOp.EQUAL, new BinaryPrefixComparator (Bytes.toBytes (Integer (CustomerId).toString() + "@")); // B

 CustIdScan.setFilter(CustIdFilter)

...

 return (transTableConn.getScanner (CustIdScan); // C

}

The code snippet Finding All Transactions for a Customer in Transaction Table gives the sample code for finding all transactions for a customer. The key idea behind the code snippet is that since transaction ids are of the form @, to find all the transactions for a customer (say 38876), we merely need to look for transaction ids of the form [email protected] Additionally, the reason this query can be executed efficiently is that HBase keeps regions sorted on keys. Statement A creates a new scanner object. Statement B specifies that the scan condition is to look for transactions where the row key is equal to [email protected] This is specified by the RowFilter which has two parameters. The second parameter BinaryPrefixComparator specifies the comparison to be made (compare the initial part of the row key with the specified string). The first parameter (CompareOp.EQUAL) specifies that the comparison is to be for equality. Statement C executes the scan and returns the result. Though this technique is being used for finding transactions for a customer, a similar technique can be used if it is, for example, desired to keep a list of customers and books they have purchased or for maintaining a secondary index. This can be achieved by keeping a table with a key of the form @.

HBase scaling: HBase provides auto scaling by horizontally partitioning tables based upon the key. A partition of a table is called a region, and an HBase server serving a region is called a regionserver. Therefore, HBase uses the range partitioning technique described earlier in the section Row Partitioning or Sharding. As the tables grow, they are automatically re-sharded under control of the HMaster server. HBase uses the Zookeeper clustering infrastructure to provide consistency and availability [26]. More details of Zookeeper can be found in chapter 6.

HBase also replicates the data based upon a user-specifiable parameter. Writes are written to all the replicas, and reads can be satisfied from any replica. Therefore, replication can be used to handle scaling for read-intensive workloads. It may be noted that since HBase uses sharding for scaling, the discussions in the section Disadvantages of Sharding are applicable.

HBase MapReduce: HBase is a key value store, and is a natural fit for processing by MapReduce. As MapReduce works on key-value pairs, splitting the input data among multiple nodes helps in scaling MapReduce applications [27].

Note

Popular Key-Value Stores

•

Amazon SimpleDB is described in Chapter 2 Infrastructure as a Service

•

Windows Azure Table Service is described in Chapter 3 Platform as a Service

•

Cassandra : Described in this chapter.

Microsoft Access Control Services

You can choose to go with an externally hosted issuer like Microsoft Access Control Service (ACS). ACS is a Windows Azure cloud-based Web service used for identity and access management. ACS can be used to provide authentication and authorization functionality for Web applications and services. This way, those functions don’t have to be built directly into the code for the application or service. A key benefit of ACS is that because it is a cloud-based instance, no installation is required. You still have to configure the instance for your environment, but nothing needs to be installed.

ACS is very extensible. It complies with a large number of environments and protocols. This allows you to easily integrate ACS into your environment. ACS supports industry-standard protocols such as OAuth, OpenID, WS-Federation, and WS-Trust. ACS also supports multiple token formats. It supports SAML 1.2, SAML 2.0, JWT, and SWT formats. ACS supports development using a variety of Web platforms. You can use .NET, PHP, Java, Python, and a host of others.

ACS includes a host of functionalities that are critical for most federated identity environments. ACS allows you to implement only the functionality you need for your implementation. ACS provides the following functionality: authentication, authorization, federation, security token flow and transformation, trust management, administration, and automation.

2.2.2 Erasure coding for data reliability

Besides data replication, another type of data storage approaches leverages erasure coding techniques to add data redundancy level so as to reach the data reliability assurance goal. Currently, distributed storage systems with erasure coding-based storage schema include OceanStore [6], Ivy [62], Windows Azure[5], and so forth.

Erasure coding is a coding approach that reorganizes the original information into another form. In information theory, it creates a mathematical function referred to as polynomial interpolation or oversampling and transforms a message of k symbols into a longer message (code word) with n symbols such that the original message can be recovered from a subset of n symbols [63]. By transforming the message, m redundant symbols are added to provide protection from storage failures where m = n − k. The redundancy level or code rate is n/k.

The erasure coding approaches have been developed for a long time and widely used for providing data reliability assurance. For example, the simplest even and odd parity is used by RAID 5 to achieve redundancy, in which if a drive in the array fails, remaining data on the other drives can be combined with the parity data (using the Boolean XOR function) to reconstruct the missing data [64]. Reed–Solomon (RS) codes are widely used in producing CDs, DVDs, or Blu-ray disks; building RAID 6 data arrays; storing data in mass storage systems [5], and so forth. Some hybrid research studies that combine replication and erasure coding or analyze differences between replication and erasure coding have also been conducted [65,66]6566. In one study [65], a solution was proposed, referred to as “fusion” that uses a combination of erasure codes and selective replication for tolerating multiple crash faults over multiple data structures in general distributed systems. In another study [66], the analysis between replication and erasure coding storage solutions for P2P systems was conducted, where the authors stated that erasure coding can significantly reduce the self-repair bandwidth. Recently, research studies for erasure coding storage solutions in Clouds have also been seen [5,67]567. In one study [67], an erasure coding approach using the Reed–Solomon 10 + 4 codes was applied to HDFS-RAID storage systems at Facebook. And in another study [5], Local Reconstruction Codes (LRC) 6 + 3 or 12 + 4 codes were applied to part of the Windows Azure Storage service.

Unlike data replication approaches for storage, erasure-coding approaches divide data into several different data blocks, modify the original data, and store the data with additional erasure coding blocks. By using erasure-coding approaches, the data reliability can be assured at a quite high level. Compared to data replication, erasure-coding approaches have better performance at reducing storage redundancy and data recovery bandwidth. However, the computing overhead for coding and decoding erasure-coded data is very high. For example, in one study [68], the decoding time for a data block of 16 MB using Tornado Z codes is at a magnitude of tens to hundreds of seconds. Such a performance is somewhat even above the average performance of other erasure codes, such as the Reed–Solomon codes.