Differences between Cloud Computing and Grid Computing

Computing

A classical distinguishing criterion between Cloud Computing and Grid Com- puting is the uniqueness or multiplicity of administrative domains. Clouds are supposed to be rather homogeneous servers located in data centers controlled by a single organization, while grids are supposed to be a federation of distinct collaborative organizations sharing (potentially heterogeneous) resources. A consequence of the multiple administrative domains in Grid Computing is that grids need to handle the additional constraints of a federated environment, e.g. checking the credentials and the agents’ identities, but also monitoring the system to detect malicious uses. These additional constraints, together with the potential lower bandwidth between two distinct administrative domains increase the com- munication burdens and therefore tend to require coarser granularity for the tasks distributed on the Grid than those distributed on the cloud.

A second aspect of Cloud Computing is the intensive use of Virtual Machines (VM). A VM is the software implementation of a computer that executes programs as if it was a physical machine. VM implementations were already available several years ago, but they were uniquely software based and therefore suffered from a significant impact on their overall performance. Nowadays the VM im- plementations are both hardware and software based, reducing the loss due to virtualization in a significant way. While the original motivation for virtual machines was the desire to run multiple operating systems in parallel, Cloud Computing is intensively using VM to build a higher degree of abstraction of the software environment from its hardware. The use of VM provides Cloud Com- puting with desirable features such as application provisioning and maintenance

tools, high availability and easier disaster recovery.

A third difference between grid and cloud is ownership. In most Grid Computing examples, consumers as a group own the resources they use. In the cloud case, resources are totally outsourced to the cloud provider and do not need delegation of authentication or authority: cloud consumers are paying for resources in a pay-as-you-go manner. Rather than accessing resources directly, Cloud Comput- ing consumers access them through a kind of service they pay for. By adopting cloud, computing consumers do not need to invest in and own hardware and infrastructure (data center, power supply, cooling system, etc.) as they would probably need in the Grid Computing case.

A side effect of this ownership shift is multi-tenancy and elasticity. Elasticity is the ability for the cloud consumer to provision up or down the number of computing instances as well as the size of the data storage system. Since differ- ent resources are gathered into a specific cloud company actor instead of being held by each customer, the resources are mutualized. Such a mutualization of resources allows elasticity, in the same way the mutualization of the risks allows insurance mechanisms. This dynamic reconfiguration of the resources allows each consumer to adjust its consumption to its variable load, therefore enabling an optimum resource utilization. For instance, in most Cloud Computing systems, the number of computing instances can be resized in few minutes.

One last significant difference between cloud and grid is hardware administration and maintenance. Cloud consumers do not care about how things are running at the system end. They merely express their requests for resources and the Cloud Computing service then maps these requests to real physical resources. It therefore disburdens customers of a part of system administration. In the same way electricity became available to consumers in the 1930’s when a national electricity grid was implemented, Cloud Computing is an attempt to commoditize IT. The administration part left to the cloud consumer depends on the type of cloud offer which will be chosen (Infractruture as a Service, Platform as a Service, etc.) as detailed in the following subsection.

From a computing consumer’s point of view, Cloud Computing is therefore a Grid Computing with a single administrative domain, where the management of physical resources has a clear outsourced centralized ownership and hardware is accessed indirectly through abstractions, services and virtual machines. There are much fewer commitments for the consumer since no initial investments are

required anymore1_.

2.3.2

Everything-as-a-Service (XAAS)

A Cloud Computing environment is a three-actor-world. It is composed of the cloud provider which supplies hardware ownership and administration, the cloud consumer using this abstracted hardware to run applications (the cloud consumer often being a software company), and the application consumer, which is using the applications run on the cloud. The three actors are related to each other as follows: the cloud consumer is the customer of the cloud provider, and the application consumer is the customer of the cloud consumer.

It is up to the cloud consumer to choose which part of the application build- ing he wants to handle by himself and which part will be built using the cloud provider pre-made libraries and services. This decision mostly depends on the cloud consumer’s will to get involved in low-level software considerations. More specifically, there is a tradeoff for the cloud consumer between a higher control on the hardware and the systems he consumes, and a higher level of programming abstractions where developing applications is made easier.

To address the different choices of the cloud consumers, each cloud system has developed distinct strategies and API, as reported in [43]. A mainstream clas- sification of Cloud Computing offers is therefore based on the programming abstraction level proposed by the cloud providers. Let us provide a short descrip- tion of these different abstraction levels.

– Infrastructure as a Service (IaaS) is the lowest cloud abstraction level. Re- sources (computation, storage, and network) are exposed as a capability. Cloud consumers are relieved of the burden caused by owning, managing or control- ling the underlying hardware. Therefore they do not access directly the physical machines, but indirectly through VM. IaaS consumers are given almost full control on the VM they rent: they can choose a pre-configured Operating System (OS) image or a custom machine image containing their own applica- tions, libraries, and configuration settings. IaaS consumers can also choose the different Internet ports through which the VM can be accessed, etc. A VM in IaaS can run any application built by the cloud consumer or anyone else. The main example of IaaS offers is Amazon Elastic Cloud Compute (EC2).

– Platform as a Service (PaaS) is a higher cloud abstraction level than IaaS, designed to ease applications building and hosting. Contrary to IaaS on which the OS and the configuration settings can be chosen and any application can be run, PaaS provides the cloud consumer with much less freedom. This consumer is given a fixed and constrained execution environment run on a specialized OS, and he is only in charge of defining the code to be run within this framework. The PaaS environment manages code deployment, hosting and execution by itself. PaaS offers may also provide additional development facilities, such as application versioning and instrumentation, application testing, system mon- itoring, etc. In the case of PaaS, storage is mostly provided in the form of a remote abstracted shared storage service. Prime examples of PaaS are Amazon MapReduce with Simple Storage Service (S3), Microsoft Azure, BungeeLabs, etc.

– Software as a Service (SaaS) is the highest cloud abstraction level where appli- cations are exposed as a service running on a cloud infrastructure. Contrary to the customer of IaaS or PaaS, the SaaS consumer is not involved in any software development. This customer is only an application consumer com- municating through the Internet with the application which is run on the cloud. Some examples are GMail, Salesforce.com, Zoho, etc.

These distinct abstraction level technologies have different positioning on some tradeoffs:

– abstraction/control tradeoff : PaaS provides higher abstractions to develop ap- plications than IaaS, but the applications built on top of PaaS need to conform and fit with the framework provided. As outlined in Subsection 2.5.1, some processes hardly fit with a rigid framework like MapReduce. On the other hand, IaaS will provide cloud consumers with a higher control on the machines but with fewer off-the-shelf abstractions in return: the same distributed compu- tation challenges will probably need to be repeatedly solved.

– scalability/development cost tradeoff : Applications run on a PaaS environment prove to be easily scalable. Yet, this scalability comes as a side-product of a strong design of the application so that it fits in with the framework provided. On the contrary, applications run on an IaaS environment provides more flexi- bility in the way the application can be built, but the scalability remains the customer’s responsibility.