Understanding Cloud Computing
We talk of computation as a service bundle when we talk of cloud computing. We aim to use the entire platform, including server infrastructure, computer network, operating system and software applications, as a service; and aim to pay per-use basis. We pay a fee for the service, thus pay for use only.
As we discussed in the first chapter, the whole concept of 'Cloud Computing' started with using Software as a Service (SaaS) where application service providers setup their software applications to be used on pay-per-use basis from their central infrastructures. Later, the same concept was extended to infrastructure itself, and we called it as IaaS (Infrastructure as a Service). Similarly, we coined the term Platform as a Service (PaaS) that referred to the availability of a software platform as a service.
This inclusive approach to computing with hardware, software, and network, resources sourced from one or more vendors, located at one or more locations, and working in unison to provide highly available storage and applications, has led to the model of cloud computing. People also term this model as a technology though it can certainly be ascribed as a functional model with a bundle of intertwined (cloud) technologies. Thus the use of the term as a technology in this book or elsewhere must be understood in the right spirit.
A Search for Definition
As different providers provisioned their resources (software or hardware or both) and used the term cloud computing, people began to worry about the definition of this phrase. Different specialists and group of vendors started defining the term in different ways – as it suited their requirements.
At the same time, we cannot simply deny the contribution of these interest groups as the current understanding has made its way from those many trials, both wrong and right. Gradually dust settled with a standard definition being proposed by National Institute of Standards and Technology (NIST); and it received wide acceptance from providers, researchers and users alike. Let us now discuss this in detail.
A Model - the NIST Way
NIST proposed the model that can serve as a standard to understand various cloud services offered by multitude of cloud providers. The model is intended to serve as a means for broad comparisons of different cloud services and deployment methods. This also provides the basis to understand the whole paradigm, and to make the best use in business and common usages.
As per the definition by NIST, 'Cloud Computing' is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. The Cloud Model is composed of five essential characteristics (on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service), three service models (cloud software as a service or SaaS, cloud platform as a service or PaaS, and cloud infrastructure as a service or IaaS), and four deployment models (private cloud, community cloud, public cloud, and hybrid cloud).
In the remaining part of this chapter, we shall discuss each item mentioned in this model and its impact in modifying the IT architecture.
Essential Characteristics
As mentioned above, cloud computing has five essential characteristics. We shall discuss these first, and shall then try to understand its influence on existing IT systems and their architecture:
1. On-demand Self-service: Before the advent of cloud computing, a major hurdle was to depend on a group of highly-skilled system administrators while provisioning and scaling IT resources, be it software, hardware or network. This was a slow and tedious process, and the turnaround time was sometimes pinching.
With cloud computing, this capability has now fallen into the hands of users themselves sans the technical steps involved during the process. The proposition has also created a demand from providers to make each resource measurable, and to avail a simple user interface for the users to provision these resources when they require, on demand. The actual provisioning is supposed to be done at the level of software on service provider’s side without human intervention.
2. Broad Network Access: Accessing cloud resource requires internet connectivity, and the definition makes it explicit. The emphasis on broad connectivity and access promotes thin clients and platforms for accessing and using IT resources across different devices like desktop PCs, laptops, mobile phones and tablets. It addresses the need for universal access to IT resources as a part of cloud computing, a topic that we shall discuss in detail in Chapter 3.
3. Resource Pooling: The cloud computing promises an economic advantage through an optimal use of the available IT resources; and it is achieved by sharing resources between different tenants on demand. We set the stage for adopting a multi-tenancy model. Of course, the sharing process and intricacies are masked from the end-user, a step in concurrence with the above discussion about on-demand self-service.
4. Rapid Elasticity: This characteristic is consequential as we have automatic provisioning and scaling of IT resources possible on cloud. But, of course, it is now explicit and a major feature of cloud computing. It also implies to the availability of almost unlimited resources for allocation on demand. Though the term ‘unlimited’ can be misleading, availability of much more resources than usual collective demands from users makes a sense.
5. Measured Service: We have already talked about the need for measuring the resources, and thus services offered, while we discussed on-demand self-service above. It requires the cloud systems to employ a metering capability at some level of abstraction. The infrastructure services may use parameters like size of storage, unit of processing power, and incoming and outgoing bandwidths for measuring the services offered. For example, Cloud Sites of Rackspace use compute cycle (abstract unit to measure computing resources) along with other obvious parameters like storage and bandwidth. Similarly, platform and software services may use parameters at an appropriate level of abstraction to create a usable measurement of services offered, like number of transactions, etc. Moreover, the metering facility at cloud systems requires creating dashboards and reporting facility for consumers who can monitor and adjust the allocation based on their requirements and budget.
After the above discussion, we can sense our changing view on using IT resources. A general user with a login access to cloud can allocate almost instantly as much resources as needed. Moreover, user can start using these resources from anywhere, anytime and with any device with a network connection. At the same time, the service provider manages the cloud system, which is equipped with tools for automated provisioning of resources, resource pooling for optimal shared usages, and for measurements and monitoring purposes. These measurement tools should be based on limited number of parameters for controlling allocation and usage of resources, and for receiving payment from users. A win-win situation for both sides.
We may now summarize our above understanding in the form of an illustration (figure 2.2) that describes the change to IT architecture in relation to the delivery and use of cloud services. The illustration shows augmentation of three new components to the IT system in the cloud computing environment. Let us review these one by one starting with the metering and billing tools.
The metering and billing tools have two interaction points. One is tenant-facing where users can measure and monitor their resource usages, and can make payment for the purpose. The other interaction point of these tools is vendor-facing where the service provider can monitor, and manage the resource allocation and usage by tenants apart from tracking and managing the billing. Of course, such control is centrally managed on the side of service provider, and mostly without human intervention.
The second set of tools is meant to handle identities of users on cloud. It is the most important one from security point of view. These tools filter unwanted traffic at cloud, validate identity of rightful users, and assign appropriate access rights over the requested IT resources.
The final set of tools is meant for provisioning of resources on demand and their management. These are basically back-end management tools automating crucial tasks at service provider’s end. These do not require human intervention except during certain typical system administration activities or in special circumstances. In fact, a major role of these tools comes into picture when there is a failure within the system. And, then the automatic recovery of the system should be the handiwork of these tools. We shall discuss more about the causes and types of system failures, and also relevant aspects related to their automatic recovery in Chapter 4.
Alternatively, we can understand that a cloud system must have these three sets of tools built into its architecture; and that is what the five cloud characteristics propose apart from some best practices for delivering and using cloud resources. Some of the implied best practices for cloud service providers that are worth mentioning here:
- Availability of simple and usable user interface for users to provision and manage IT resources they require
- Automation is the key – the system should be able to run and serve its users without no or least human intervention at service provider’s end
- The IT resources must always be available on network and for universal access by its rightful users
- Cloud system must be able to allocate additional resources for resource intensive requirements by any user any time while making optimal utilization of all available resources.
- The IT resources must be quantified in an unambiguous manner, and must be measurable with a limited number of parameters.
It is important to incorporate all the best practices into the design, deployment and delivery of cloud services.
Now, continuing our discussion, we must note that the cloud characteristics bring some radical changes to the way both physical and software architectures are conceived within a cloud system. Cloud service providers adopt appropriate ways to sync with these requirements at all levels, and adhere to the best practices laid while designing, deploying and delivering their cloud services. In the next section, we shall discuss these levels of service delivery as different service models of cloud computing; and shall postpone the discussion about deployment models to a section after that.
Service Models
The definition proposes three service models. Let us review these three in detail first, and then discuss their impact on IT architecture:
1. Software as a Service (SaaS): We have already discussed this in different places while scanning through the history of computing in the Chapter 1 and also at the start of the current chapter for introducing the concept of cloud computing. Basically, service providers offer their software applications as services in this model of IT delivery. Service providers manage all aspects of software including data backup and restore apart from its maintenance and upgrades. Moreover, they manage underlying hardware and network resources for end-users to use software applications oblivious of the backend management. Salesforce.com has been an early player in this tier of services as we have discussed in Chapter 1. Similarly, Wordpress.com can be considered as another example where usages go beyond business domain. There have been numerous other software service providers specialized in different verticals who are gradually shifting or cloning their software applications as cloud services, thus becoming SaaS providers.
2. Platform as a Service (PaaS): These are basically the kind of services useful for developers and solution providers. Such services provision development environments, and avail programming libraries, thus expediting the process of application development. These also provide tools for quick deployment and maintenance of software applications. A platform must be capable of handling administrative tasks like updating OS patches, upgrading supporting software hosted on it, and managing and scaling network resources automatically. Major players for this tier of services are Microsoft (with its Azure Cloud Computing platform) and Google (with Google App Engine). On the other hand, many new PaaS offerings are coming to the market using different open source technologies and innovative development frameworks based on those.
3. Infrastructure as a Service (IaaS): This remains at the core of a cloud system where service provider avail servers, storage devices and network resources for use as services. Cloud infrastructure equipped with different software tools like hypervisor, and cloud orchestration toolkits (both to be discussed in Chapter 4), provides an interface between the users and the actual physical infrastructure. These tools help manage and deliver infrastructure as a service. Rackspace and Amazon are two prominent players in this tier of cloud services though almost all primary web hosting companies have made their foray into this service model in the recent years.
On the other hand, it is important to note that the same provider can very well encompass all the three tiers. Also, different companies offering services in different tiers (service models) can create a larger ecosystem. For example, Microsoft provides its Azure in PaaS model whereas its Windows Azure and SQL Azure in SaaS model. Similarly, Rackspace provides its cloud services in IaaS model, and many other providers, who deliver in PaaS or SaaS model, have built their offerings based on Rackspace’s infrastructure, and, thus creating a large ecosystem of cloud.
I would not like to go into the details of history when many different service models were being proposed, like HaaS (Hardware as a Service) and NaaS (Network as a Service), etc., as they eventually fall under above three broad categories. Rather, we should take solace from the consolidation of thoughts and emergence of a set of comprehensive, yet distinct, cloud service models, which can be used then for building a highly modular architecture of IT systems ready to be delivered as a service. These service models bring in changes to IT systems where different tiers of services can be conceived; and provide excellent means to classify and describe relevant technologies.
The above illustration (figure 2.4) shows the augmentation of a software stack into the cloud system exactly the way we had discovered how three sets of software tools were accommodated into a cloud system while discussing on the essential characteristics of cloud computing and their impact on architecture. We shall take this illustration as the basic means to classify different technologies on cloud, and would call this as the Cloud Technology Stack. Let us postpone any further discussion on this until Chapter 4 where we shall cover the technology stack and the technologies involved in great detail.
Well, we have yet another aspect still left; and that is ‘Deployment Models’. These refer to the ways a cloud system is deployed in practice. Let us discuss these in the next section.
Deployment Models
There are four deployment models as proposed by the NIST definition. The deployment of a cloud system in different ways influences the way the cloud system is configured, and the IT services are delivered to users. This significantly alters the architecture of IT system as it is evident from our above discussion. Let us review each one before we discuss their impact on architecture:
1. Public Cloud: This is the de facto deployment model when people refer to a cloud service. Rackspace Cloud, Amazon AWS, and Microsoft Azure are typical examples of large public cloud. The success of such deployment model relies heavily on its scalability and availability.
2. Private Cloud: We come across many organizations where circumstances and business terms decide about keeping the data on premise or somewhere else but in private. These two parameters have been addressed through a deployment model called private deployment of cloud or a private cloud. Here, IT resources are meant to be used by an organization exclusively. The management aspects may be kept within the organization or be outsourced to 3rd parties, but the guarantee for dedicated service must be honored. Also, the infrastructure may be maintained on premise, or may be located at 3rd party location(s) as long as the exclusive usage is guaranteed.
3. Community Cloud: Different communities, who have shared objectives and requirements, would also demand specific computing environments and applications. These are met through the deployment of cloud system where only the members of the community use it. This is obvious due to the availability of features that suit the community’s specific needs. Google provides App Engine platform, which basically targets Python programmers; and Zend provides a cloud platform for PHP community. There is a distinct advantage for the community where members prefer specific tools and technologies to build their IT solutions on the top of respective platforms. Please note that the offerings on a community cloud can span all three service models in general though we have given a few specific examples only.
4. Hybrid Cloud: This deployment model is a mixture of two or all three other cloud deployment models. In this case, certain components of the cloud system will be located in the public cloud, some other in private cloud, and perhaps, the remaining ones in community cloud as suited. The decision of choosing the deployment of different subsystems lies on business terms, and accessibility requirements among others (to be discussed in detail in Chapter 5). The major areas of emphasis while dealing with hybrid cloud is to handle the partitioning issues; and we shall discuss these in detail in Chapter 4.
The illustration (figure 2.5) depicts different deployment models, and in particular, signifies the complexities that a hybrid cloud can bring in during building and managing such cloud system. It is to be noted that any of the deployment models does not put any restriction on locating the parts of a cloud system in different geographical areas. Rather, it becomes essential for cloud systems to exist in a distributed manner to enable redundancy and quick delivery of data to users (we shall discuss more on this in Chapter 4).
Now that we have learnt about the NIST definition in full, we are equipped with ingredients to relook at the IT service architecture. We shall discuss about our changed perspective in the following section.
A Renewed Perspective
We have shifted our attention from discrete systems that are managed by manual efforts of the highly skilled staff of a service provider to an automated self-managed service that can be provisioned and consumed on demand. We have also moved from the scenario of using enterprise systems on specialized terminals to one that promotes universal access by the user with appropriate access privileges.
Data are now stored in a distributed manner, so also the computing assets. This distribution can be organized into virtualized compartments (Virtual Machines, or VMs) in a bigger machine or across different machines located in a single location or spread across different geographical locations (to be discussed in detail in Chapter 4). Limit is not drawn here; the systems engaged in this distributed conglomeration can be disparate too if circumstances demand, i.e., these systems can operate and be managed differently, but adhere to the same set of standards and protocols while talking to one another. This is the concept of distributed computing, and this is what cloud computing proposes too.
Cloud computing, as it is known, starts with a large-scale (how large, it depends on context) central computing infrastructure, sitting within one or more datacenters. Powerful server machines and other devices scale together with a principle called virtualization to provide a uniform hardware platform. Cloud applications or Apps function from this mega computing platform equipped with networking to communicate with the external world. These apps are supported by automated management tools, and are available for users to access and use from their client devices. Here the client device can be a desktop or a mobile device equipped with a thin client, like browser, and internet connectivity.
The above description has been illustrated in the figure 2.6 where access to Apps is controlled by the augmented tools that we have discussed earlier. Users register their identities on the central cloud system, and this identity is critical to access and consume IT resources by the users on cloud. The identity is verified while accessing the cloud services, and the user access is linked to the Metering and Billing tools while the allocation and usages of resources are actually controlled through Resource Provisioning and Management tools.
The universal access to resources and the sharing of computing resources, while retaining the privacy of data, demand a thorough review of the security architecture too. The security is enforced by the cloud system by allowing access to the appropriate user roles, and restricting the access from other roles that do not have the requisite privileges. This is usually implemented through one of the RBAC (Role Based Access Control) schemes, which we shall discuss further in Chapter 4.
Similarly, at infrastructure level, unwanted traffic within the virtual hardware platform is restricted, and only traffic following appropriate rules are allowed. This consistent view across different levels provides a clear understanding of the cloud architecture, and gives an insight into the security implementation.
The above discussion and review of the underlying scenarios unfold various aspects in the entire cloud delivery cycle. The new perspective is inclusive, which means that the existing solution providers and programmers should be able to use their existing knowledge and expertise on standard programming tools. Basically, migration must be smooth and the effort should be minimal. We shall discuss more on this in Chapter 5.
While implementing cloud systems, different vendors use various situation-specific jargons apart from some specialized implementations as suited. We shall not discuss these in this book, and rather leave those to the documentation of the respective cloud systems.
The Model Is No Red Tape
The definition by NIST proposes a broad model of cloud usage and best practices. This promotes a functional IT service architecture that can meet diverse needs of users. Moreover, it provides guidelines for cloud service providers to create standardized facilities that can meet expectations from users, and to optimize overall costs on their side too.
On the other hand, this definition cannot undo the speed of innovations by red-taping the evolution in our thinking based on user demands and available possibilities to match these. We shall dedicate the next chapter for reviewing the ground realities in IT, expectations from users, and challenges in front of service providers to understand the state of cloud computing in practice.