The Technology Landscape

This is the preserved 2012 chapter text. Figures have been restored from the original document export where available.

We have had adequate talk about the realistic foundation of cloud computing as a new way of delivering IT services. This talk will remain tangential if we do not understand the technologies that play cardinal roles in shaping this novel computing paradigm. In this chapter, we shall discuss the key underlying technologies. We shall refer to some of the major vendor-specific technologies and products (when appropriate) as examples without creating bias, and shall retain the thread of discussion about the fundamental aspects of this computing paradigm.

To come down to actual discussion, we shall maintain our reference to the same NIST definition discussed in Chapter 2. We shall utilize our acquired knowledge about the way cloud computing being characterized, being treated as different services, and the ways of deployment. As a matter of convenience, we shall view cloud computing from the perspective of three categories of services (service models), and shall stack all requisite technologies and other components around these (Cloud Technology Stack as we had mentioned in Chapter 2). Figure 4.1 illustrates this technology stack – an organized view of the technologies used to build a cloud ecosystem.

The stack consists of three layers, creates valued services on the top of the dumb hardware, and delivers these services to users through their cloud clients like web browsers or native applications (Apps) sitting on their devices like desktop, laptop, tablet or smartphone. This may seem to be a long description; but it works as it tells the entire story in a comprehensive way.

We shall start our discussion from bottom to top. The interconnected hardware devices that make the hardware platform serves the basis of infrastructure. We shall not discuss about physical servers, storage disks or network as we assume it to be an obvious thing for IT users. Well, we do not assume any special skills, and shall rather elaborate any specific technical terms in detail if we use it during our discussion.

In fact, IaaS layer consists of a set of software tools, called cloud toolkits, which interface with the cloud hardware layer. Let us initiate our discussion by looking at the key concepts like virtualization and cloud orchestration that are part of these toolkits.

Virtualization Is the Key

Virtualization is the buzz-word of today, and is the key constituent in building cloud system. Virtualization refers to creating a virtual version of something, be it server machine, storage container, operating system or even network resource.

In simple terms, hardware virtualization pertains to the task of making hardware platform capable of running multiple copies of OSs or multiple sessions of single OS simultaneously. In this process, each copy of OS is isolated from all other copies in all reasonable terms while adhering to the internal communication guidelines.

What happens to the behavior of OS in such an environment? How different copies interact with one another that will offer a framework for networking within the same environment? How will the applications hosted in such virtual machines behave? What special care will be taken to run these applications successfully? Let us find answers to these questions below.

To understand this, let us do an abstraction of the entire scenario. The hardware platform is dumb without a software component sitting and working on it. This software, popularly called as a Virtual Machine Manager (VMM) or a hypervisor, enables the available hardware resources to be fragmented into different virtual machines each being allocated with resources like RAM, processing power, and storage etc. This software controls and manages the VMs. An Operation System (OS) on a VM is treated as a bundle of programs along with their states by this parent software platform. OS in such incarnation can readily be used without going through the process of installations and configurations. On the other hand, these VMs are setup not to allow unwanted traffic from other VMs. In a networking framework, this mimics the traditional world. IPs and subnet masks are allocated to VMs to make the virtualization complete (figure 4.1).

Figure 4.2: A Simplistic Model of Virtualization

Well, as we discussed above, we restricted ourselves to virtualization within a single physical machine. On the other hand, grid computing has already given adequate amount of expertise to gather multiple machines to enable a distributed environment for computing. Putting both into a single integrated perspective, we can extend the concept of virtualization across multiple machines spread over multiple geographical locations. And, of course, we add the components like automated tools for provisioning and managing computing resources based on metered usages (many refer to this as ‘utility computing’ model) to realize a comprehensive picture of cloud computing. Moreover, user applications hosted on such a platform is not aware of these changed details while leveraging all advantages like scalability and redundancy associated with the new platform. Application is open to communicate with one another, and even across different clouds through their APIs adhering to standard protocols like SOAP, ReST, XML-RPC; and in this way, they scale out horizontally. We shall discuss this in detail in a separate section later in this chapter.

Going back to our ongoing discussion, offerings from Oracle, Microsoft, Citrix and VMware are very popular in the segment of virtualization. Respective websites will provide the details of these products along with feature comparisons and other technical details. In fact, all major IT companies are investing significantly in achieving seamless process of virtualization from hardware to application level. The drivers of such effort include the expectations of greater control over the OS and applications hosted within, provisioning and managing applications, middleware and databases, accelerating application deployment, lower cost, scalability, and high availability.

Orchestrating Cloud Infrastructure

Do not confuse this with software stack that will be delivered in PaaS model. Here, we are talking about an integrated management of cloud infrastructure to be delivered in IaaS model. In fact, the concept of virtualization across multiple hardware systems led to the projects for building an integrated cloud platform.

Early efforts can be traced to projects such as Nebula by NASA and Eucalyptus, originated from a research project in the Computer Science Department at the University of California, Santa Barbara. Later Rackspace and NASA collaborated along with a growing list of partners for an open source project called Openstack, which is now in the process of becoming the de facto platform for public and private clouds. Apart from this, there are several other products which have received good acceptance, notable among them is Cloudstack sponsored by Citrix, Flexiscale, which was in fact launched shortly after Amazon’s EC2 service, Opennebula, and Skytap.

Each cloud platform offers its own set of terminologies while bringing the conceptual foundation to working. However, all of these adopt a set of broad guidelines and goals:

Capability to build, manage and deploy IaaS offerings, for example, like Amazon EC2 and S3
Agnostic to hypervisors, or at least support for all popular hypervisors from different vendors
Equipped with tools for managing heterogeneous distributed datacenter infrastructures
An easy-to-use web interface, command line, and a full-featured RESTful API (honoring ReST protocol).

While major cloud vendors have built platforms for IaaS offerings, the architecture and product features are in a rapid process of evolution.

On the other hand, different cloud management tools have been created that can support across multiple vendors and across different deployment models. Prominent players like RightScale, Enstratus, Kaavo, and Scalr provide such solutions in SaaS model – applications that interface with IaaS offerings for easy management and monitoring of cloud resources across different vendors.

As we learnt about cloud orchestration, we must note that it is not just hardware platform or OS that we control, but we also control and manage data storage and network. We shall discuss these two in the next two sections respectively.

Handling Big Data Effectively

We have already discussed about big data in the last chapter. We speak about big data in a scenario where the existing Relational Database Management Systems (RDBMS); and the associated tools are simply inadequate to manage such data. In fact, this signifies a much broader thing than the voluminous data size as indicated previously.

Big data has two qualitative, and three major quantitative, attributes that define it in a comprehensive manner (figure: 4.3).

The qualitative parameters are relevance and fidelity. The data must be relevant for the purpose. When we speak of big data, we refer to data that can pile incessantly; and thus the question of relevance becomes so important. For an example, we may accumulate data from a surveillance camera (an example that we had placed in the Chapter 1), but we must store images of requisite resolution for the requisite period of time for creating event based alerts.

Fidelity of data refers to the trust associated with the data. This depends on different parameters like the source of data, and the method of their retrieval or accumulation, and the format.

Other attributes of data that are critical to define big data, are quantitative. The first parameter, volume, has already been discussed, and refers to the large volume of data. In the context of data storage and accessing data for useful analytics, it is required to have faster append and retrieval process in place – the greater velocity of data. The data storage must have interface to be able to meet these requirements like rapid updates on a social networking site or to serve real-time analytics in an enterprise. Finally, the third parameter, variety, refers to the multitude of data formats that we are using these days like graphics, audio, video, texts, documents apart from transactional data (those stored in relational databases).

How to manage big data? If we look across various IT systems in operation today, we can see a mixture of established practices along with some forward looking implementations to manage data at this scale.

RDBMS has been a preferred tool to manage data for last couple of decades. While these database systems like Oracle, MySQL, MS SQL Server, etc. provide a well-structured storage and retrieval system, they come with their overheads due their compliance with ACID (Atomicity, Consistency, Isolation and Durability) properties. To manage growing data size and I/O requirements, a few attempts have been made during the course of time like master-slave architecture and database sharding (or horizontal partitioning) to achieve a workaround with the existing relational databases. But these options were costly and cumbersome.

As people started looking at the method of data management with a revised perspective, it became important either to give priority to high availability of data or to their consistency. In fact, there emerged the famous theorem by Eric Brewer, the CAP theorem, which postulates that any distributed data system can have only two of three properties like consistency (C), high availability (A), and tolerance to network partitions (P). Though it is not my intention to drag you into a technical discussion about this theorem, it is pertinent to draw your attention to its relevance in the current situation of handling big data. Moreover, quick addition (technically appending data to the existing data store) and retrieval of data removes the need of having a single up-to-date copy of data at any given time, an ACID property. Though this requirement of the consistency of data cannot be ignored altogether, mandatory requirements have gone with the kind of data in question; and a new breed of database management systems, called noSQL (Not Only SQL), have compensated the needs. These database systems are categorized according to the way they store and facilitate access to data:

Key-value Stores: These allow to store data in a schema-less way. There is no need for a fixed data model; rather data could be stored in an object. Major examples are Apache Cassandra and Amazon DynamoDB.
BigTable: It is a high performance and compressed database system by Google. It is currently available with Google AppEngine. However, there are different clones/derivatives of this database that have come into scene in the recent years like HyperTable and LevelDB, etc.
Document Store: This is designed for storing, retrieving, and managing document-oriented, or semi structured data. This type of database is also called a Document-oriented Database. CouchDB, MongoDB are two examples of this category of databases.
Graph Databases: These use graph structures with nodes, edges, and properties to represent and store data. AllegroGraph, InfoGrid, and Neo4j are a few examples of this type of databases.

It would be a different exercise to learn these databases and to use them; in fact, the exercise can be a whole new book altogether. I would rather offer a brief discussion about them here.

The noSQL databases are still evolving, and are following the experiences gained from handling different systems using big data, and associating different mathematical concepts to solve these problems. The major areas that are driving innovations in these new breed of database systems are social networking, real-time analytics, context-aware computing requirements for mobile users among others. However, it is also clear that these systems adapt and exploit the distributed architecture of cloud to achieve desired performance and scaling; and we shall discuss this in the following section.

Working in Distributed Architecture

All along, we have seen the advantage of scaling horizontally, and the ease and economic feasibility associated with such an endeavor. On the other hand, it is required to understand the architectural differences that exist in such scenarios where the system is spread over multiple devices, perhaps across different geographical locations. The situation becomes engaging when the participating devices have different configurations and possess different software environments. Well, that is what we want to handle when we talk of distributed systems!

We have already discussed the way the hardware platform is scaled, and how we control and manage such infrastructure. However, it is also important to understand the way the user’s request is met from the cloud. We must have an understanding of the way requests from user to the source of data, and the flow of data from the source to its destination or user are managed. Please note that we use the term “user” as a synonym of any client, be it a thin client or another application on the cloud.

It is normal to think of HTTP protocol to be responsible for the majority of data transactions over Internet. While, there are other protocols, which can be more convenient for certain situations, HTTP has gained popularity due to its simplicity and ease of use in all situations. Putting along our perspective, this protocol is the carrier for all user requests (HTTP Requests) and all responses from the cloud (HTTP response).

But, how are these requests recognized and how are the cloud resources identified? This is done by Domain Name Service (DNS), a hierarchical naming system of Internet resources. The resources are named after domain names, which can be understood as the human-friendly identifiers to different resources available on Internet for consumption.

While DNS enables identification to resources, the process of redirection of access to a copy of the resource depends on the Load Balancer. It regulates the access to a particular resource, and ensures its availability based on geographical proximity, and access to the next nearest neighbor in case of a situation of partition where cycle of a transaction gets disrupted due to unavailability of dependent resources.

Figure 4.4: Important Components of a Distributed System that Facilitate User Requests and Response from Cloud for Content

The next thing is to do the actual serving of data to users based on their request. This is done through a Content Delivery Network (CDN), a geographically distributed network setup to increase the availability of resources based on geographical proximity and to reduce the latency of accessing resources. Currently, only large IT infrastructure providers make CDN available. Akamai is the largest CDN provider with 1,00,000 servers spread over 70 countries around the globe. Cloud providers like Amazon and Microsoft also have their own CDNs. Telecommunications service providers offer CDN services to reduce demand on their network resources and to leverage costs of their huge infrastructures.

In fact, we are participating in a rapidly evolving Internet ecosystem. Streaming rich media (disseminating audio and video over Internet to achieve a steady flow of data at the client devices) has pushed the boundary of how we shall deal with content, and has led into mass customerization of content publishing and consumption.

All these happen due to innovations on the side of datacenters that ensure sustainable and better delivery of applications and content. Let us now turn our attention to discuss it in detail.

Datacenters See Transformations

As chip technologies are evolving with active participation from industry, and newer possibilities are emerging with applications of photonics and nanotechnology, the server hardware, storage and network devices are seeing rapid changes. Apart from just items, which are directly associated with capital expenditures, vendors are in constant process of innovation to optimize energy efficiency at datacenters and automation of various processes therein. In fact, cost of power and cooling infrastructure can equal, or even exceed, the cost of IT hardware in a datacenter. Thus adopting cheaper energy sources, cooling mechanisms along with newer tools, and improved process of managing energy utilization will help. Some guidelines in this regard are:

Ensuring infrastructure design for optimum performance and availability throughout its life-cycle
Integration of service demands with the supply of resources for efficient scheduling of resources
Monitoring services in association with usages and quality to determine sustainability and continual improvements
Ensuring high availability of resources in situations of partition

It is also imperative to correlate cloud services with optimal, yet sustainable, resource management to take appropriate business decision to reduce the overall cost of service delivery while providing a sustainable solution. On the other hand, the evolution is not one-sided; i.e., we also see rapid changes to the technologies used at the consumer-side. Let us discuss these in the following section.

New Devices, New Ways to Use

The changing lifestyle and usage of different electronic gadgets have influenced the way we manage our information and content. Innovations have greatly supported the changed behavior largely in sync with the expectations from end-users.

If we track news in IT or the new gadget section in any RSS feed, we come across new devices almost daily (we have happily adopted these new ways of information consumption going away from the traditional news magazines; if you have not done yet, it’s worth trying!). The look of devices, their sizes, and the utilities available within are seeing a sea-change. As we have discussed the concept of ‘universal access’ in Chapter 3, people would like to access different devices as it suits their usage patterns while being connected to all of their data. These demands have given rise to requirements like standardization of software platform, user settings, applications for accessing data, and above all, interoperability of data across various user devices.

Defining an App – A New Incarnation

As we discussed about cloud technology stack, we could see that it was broadly the handiwork of some software that leverages the power of hardware to render cloud services. Moreover, in any normal situation, multiple software applications work in unison to help a service materialize. This gives rise to a new incarnation of software, the way we view and use it.

“Anything can be an App” is the key to conceive how software is being made and used. An App may be defined as an self-sustainable software entity which can be used alone or with other Apps to create a software service.

Each App has a few important characteristics that define it and provide a broad picture of its architecture and usages. We shall discuss six major characteristics below:

Business Operations: When we talk of an App, we expect that it must achieve certain thing(s) when requested, and must be able to provide us requisite data in the desired form. The computing processes that ensue after the request is received are broadly termed as business operations. In fact, there can be multiple operations possible depending on the complexities and goals. These processes can be classified into three categories such as the processes of updates and retrievals, that of interfacing with I/O devices, and that of managing resource allocation and release. Business operations achieve the specific requirements that the App is meant for.
Disconnected Operations: There can be a situation when one or more resources within an App fail to execute. This situation is called a ‘partition’ as we know by now. It is a critical parameter in cloud scenario as the resources are distributed across many devices and different geographical locations (I believe you will find our earlier discussion on CAP theorem more relevant in this context). The user device is also considered to be a part of it. People call a partition as an 'offline mode' if the connectivity of the user device is lost from the remote cloud system. We are familiar with offline mode while using Apps like Google Mail and Docs, etc. In such cases, an offline component of App is also available natively on the user device along with a copy of data (may not be an updated one). When there is no internet connectivity, you are still using almost the full application except that the updates we perform may be delayed from being synchronized with the cloud system until the connectivity is restored. These delayed updates and the synchronization of data get complex when activities like access from different devices are involved. At present, the native clients built with HTML5 do support local storage, and are capable of managing offline mode in spite of certain inherent limitations. Thus various techniques that are in use to handle disconnected operations will have to mature. In fact, these mechanisms are still evolving, and are in active development.
Metadata: An App must be identified uniquely to be used by other Apps to complete requisite business operations. The usual process of locating an App would be to look up a database of Apps based on appropriate criteria. This will be possible if each App will have appropriate description, taxonomic data associated with it. These data are termed as metadata, and include a unique ID (using domain name system as universal identifier) apart from others.
API (Application Programming Interface): As we discussed about involving multiple Apps to achieve any normal IT computing task, it is required that Apps must work in unison, and should be able to exchange data with one another seamlessly. For this, each App must be able to understand the data exchange protocols, accept data format of another, and respond in a manner that the recipient App can understand. Currently, ReST, SOAP and XML-RPC are being used commonly as data exchange protocols whereas ReST is the most popular one due to its ease of use. Similarly, standard formats like XML and JSON are being used popularly as data exchange formats though the latter has an edge as JavaScript is being used dominantly on cloud clients.
Identity Management: When an App accesses another App, the first responsibility lies in validating the identity of the request, and confirming if it complies to the requisite access privileges. There are different protocols like OpenID and oAuth that are used to make this process easy. These encourage accessing applications across different ecosystems without creating separate identity for each one, a popular model called Single Sign-On (SSO). The other part of the data access after validating the identity is the access control over resources based on pre-assigned privileges to client. Role-Based Access Control (RBAC) schemes are the most popular ones. If you scan the research literatures, you will see a number of derivatives that have been proposed, and are being used as appropriate in different scenarios. Broadly these schemes define the regulation in access control based on user roles rather than the users themselves.
SLA: In normal business situations, SLAs (Service Level Agreements) are used to create a legal document to ensure correct delivery of services along with clear guidelines for actions in case of failures in conforming to the agreement. In similar fashion, SLA is also needed at the App-level that must include the allowed and denied resources, protocols and requests.

Now, we can perceive an App as something which delivers IT resources directly to its valid user, or to another intermediate App through standard protocols and in standard data exchange formats. Apps mask the details of the business operations from all others except providing a standard interface, API, and ensure the data access in a secured manner.

Broad Classification of Apps

Many would not agree to a particular way of classifying Apps. In fact, there are different ways which we can use to classify Apps like kind of industry they are serving, and the type of devices they interact with, etc. However, we shall adopt an approach based on the kind of business operations an App executes (figure 4.6). This approach will adhere to the technology stack closely, and will provide us an insight into the working of Apps in different scenarios.

While we discussed IaaS layer of the Cloud Technology Stack, we talked about the cloud toolkits that are responsible for providing a high-level and usable interface to the hardware platform on cloud. These toolkits are in the state of rapid evolution; and the major thrust is now on more control and auto-management.

Programming Tools are basically associated with the next layer in the stack, PaaS. These include frameworks, application builders, programming libraries, and API suites, etc. These tools mostly focus on specific programming languages and technologies.

Other three categories of Apps pertain to the SaaS layer in the stack. These Apps may have a native counterpart sitting on user devices. A major category in this layer is Web 2.0 Apps, which are used for social networking sites, e-commerce storefronts, and knowledge management portals among others. An important thrust in such Apps is on managing crowd-sourced content; technically, on the process of rapid append and retrieval.

In contrast, the Enterprise Apps emphasize on transactional data management procedures; and these Apps are used in different mission-critical scenarios of business, government and research. These Apps can serve across multiple industry verticals. For example, the backend of a storefront is managed through these kind of Apps, which achieve successful transactions without fuss.

Finally, the Consumer Apps are the ones which are meant for individual users for their personal needs. With the proliferation of devices, and increasing dependence of lifestyle utilities, this kind of Apps has a significant market-size. Location-based and context-aware technologies such as triggering an action based on location and context are predominant in these Apps.

With a discussion about different Apps on cloud, let us now look at the generic cloud scenario, how Apps behave in a collective environment, and what we expect from them. This is what we shall discuss in the following section.

A Federated Ecosystem

Can we think of a solitary App meeting all our requirements? No, rather we deal with a set of Apps that work together to achieve a real-world task. Each App gets engaged in multi-point interactions among the group of Apps to deliver desired services while maintaining the requisite isolation and independent operations within themselves. This is a truly a federated ecosystem where Apps interact with one another in a disciplined fashion adhering to standard protocols and data exchange formats. Figure 4.7 illustrates different properties of an App that are important to account for in this federated structure.

The most important activity before interacting with any App is to find it. It is required that an App must be available in a search database with necessary information (metadata of App). The discovery of an App by others must be made automatic if we have to obey the cloud characteristics.

After an App is discovered, the next important activity is to validate the requested requirements and available facility through an automatic App-level SLA. Then billing terms must also have to be adhered to if it is a requirement of the SLA; of course, all at App-level. In fact, different vendors are now equipping their devices with billing capability, in turn the Apps installed in those devices. Also, different Apps are getting bundled with the capability to manage billing through their user identities; and Google Wallet to Android Apps point at the evolution in this direction.

Figure 4.7: Group Behavior of Apps in a Federated Ecosystem

We shall go to next activity after contract is made between two Apps for their proposed data transactions. However, we know that data exchanges must abide by one of the standard protocols; and the data format has to be in one of the standard formats. Moreover, both the interacting Apps must obey the same protocol, and exchange data in the same format to facilitate successful interaction; but this may not be possible looking at the multiple popular protocols and data exchange formats. Thus it may be required to come up with a single standard protocol and to adopt a single standard data exchange format between Apps. The other option would be to inject necessary capability to Apps to adapt to different standard protocols and formats.

When we talk of a live App, we refer to an instance of an App run by a user or a virtual agent embedded in another App. And, it becomes quite important for the live App to manage the identity of the request, and to provide only those privileges that the request is authorized for. We have already discussed this aspect of identity management and security in detail in the previous section. We would rather limit our discussion here by stating that each live App must have a user role associated with it to make a request to another App.

Well, we just discussed the interaction mechanisms for Apps and different aspects involved. On the other hand, the major issue that is rather more relevant in the cloud environment is the situation of partition. Such a situation always hinders successful interactions between Apps, and results in unfulfilled requests. When we need to accept the situation of partition as a reality, we must also have the Apps to recover from the state of partition automatically. The automatic recovery manages the processes like delayed updates and synchronization of data through self-audit and control mechanisms. In fact, the situation turns complex when there are dependencies between Apps for one successful transaction at the user-end, and when a state of partition occurs. In such cases, the application must be able to determine its dependency, auto-restart the process of recovery (auto-recovery), and inform the end-user with suitable feedbacks during the process.

New Solution to the Old Problem

In this chapter, we reviewed the technologies associated with cloud computing paradigm, and analyzed the technology scenario at an abstraction of Cloud Technology Stack. Through the entire discussion, we could see the changing nature of software and a new definition of an App. This change in approach creates an abundant opportunities for new solutions.

In the following chapter, we shall look at the old problem of implementing IT, and the migration of existing systems to meet the newer challenges.