3.2 Grids and Clouds – Distributed Technologies
3.2.2 Cloud
Cloud computing can be considered a rather less mature concept than grid comput- ing. As an illustration, Gartner’s hype cycle [39] characterizes technologies through a series of phases “from over-enthusiasm through a period of disillusionment to an eventual understanding of the technology relevance and role in a market or do- main”. While grid computing reached the peak of inflated expectation in 2002 (to continue into a period of disillusionment), cloud computing reached the same peak in 2009. This is not to say that the idea of clouds should be discarded. However, being at the peak of the hype, it can be difficult to extract the basics of what a cloud is from the diverse solutions embracing the cloud paradigm2.
2It should be noted here that the term ”ATLAS cloud” (see Figure 3.2) is not an attempt from the ATLAS community to embrace the cloud paradigm. The term ”ATLAS cloud” is used
3.2. GRIDS AND CLOUDS – DISTRIBUTED TECHNOLOGIES
Applications and portals Application Portal Portal Application Web-enabled
applications
Grid tools Languages/
compilers Libraries Debuggers Monitors Web tools Resource brokers
Grid middleware Security Information Data
management Resource access QoS Security layer Client side Server side Fabric Operating system Queuing system Libraries Application kernels Internet protocols
Networked resources across organizations
Computers Networks Storage systems Data sources
Scientific instruments
Grid users
Figure 3.3: Schematic view of the grid abstraction layers. The users use applica- tions and portals to interact with the grid. The applications acts as a frontend for the users and uses the grid tools to communicate with the grid middleware which is an abstraction layer in front of the fabric consisting of the hardware and the software needed to communicate with the hardware.
However, some early attempts on defining the cloud paradigms have been made, of which one of the most notable is “Clouds are a large pool of easily usable and ac- cessible virtualized resources (such as hardware, development platforms and/or ser- vices). These resources can be dynamically reconfigured to adjust to a variable load (scale), allowing also for an optimum resource utilization. This pool of resources is typically exploited by a pay-per-use model in which guarantees are offered by the Infrastructure Provider by means of customized Service Level Agreements.” [40].
The main building blocks of a cloud are the services. The cloud actors access the services both to add resources and utilize resources. The services provides quality-of-service (QoS) guarantees through service level agreements. By combin- ing services, the service user can create a customized virtual platform. Conceptu- ally the basic services can be divided into three classes.
• Hardware as a Service (HaaS) provides customizable, scalable hardware resources, typically as a pay-per-use subscription service. Examples of HaaS are Amazon EC2, IBM’s Blue Cloud project, Nimbus and Eucalyptus. • Data as a Service (DaaS) provides data in various formats and from multi-
ple resources to be accessed over the Internet. Examples of DaaS are Amazon Simple Storage Service (S3) and to some extent Google Docs and Adobe Buz- zword.
• Software as a Service (SaaS) offers software applications as web services, usually accessible through standard Web browsers, thus eliminating the need to install and run the application on the client machine. Examples here are office applications provided by, e.g., Google Docs and Microsoft Office Live. Additionally, concepts like Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) combine the above-mentioned concepts to offer higher-level ser- vices. For example, Google Wave is a web-based service, computing platform and communication protocol, combining HaaS, DaaS and SaaS in one service.
Figure 3.4 shows the relationship between the cloud actors, i.e., the service users and the service providers, and the hardware resources. When compared to Figure 3.3 clouds have fewer abstraction layers, and service providers, being at the same side of the infrastructure management as the users, have more control in adding and removing services. However, the hardware is isolated through sep- arated virtualization layers. While in grid one security layer spans the entire grid middleware, security in clouds is provided through isolation of the different virtual- ization layers. Note also that where grids provide high-level services like metadata searches and data services through the grid tools, the clouds leave these issues to the cloud applications. This may be due to the current absence of federated clouds, to describe a Tier-1 with a set of associated Tier-2’s and Tier-3’s, and preceded the commercial use of ”cloud” by several years.
3.2. GRIDS AND CLOUDS – DISTRIBUTED TECHNOLOGIES
Service Service Service Service Infrastructure interface
Infrastructure management
Virtualization layer Hardware Operating system Virtualization layer Hardware Operating system Virtualization layer Hardware Operating system Virtualization layer Hardware Operating system Virtualization layer Hardware Operating systemService
providers
Service
users
Utilization Deployment/ managementFigure 3.4: Schematic view of the cloud actors; the service users and service providers. Both users and providers need to go through the infrastructure man- agement to use and provide hardware through a virtualization layer.
as grids were in a similar state before the need for federated grids forced a need for standardization of grid tools. As cloud services become more cost-effective, one can speculate about a near future where grid services, custom-configured for each virtual organization, are deployed in (one or more) clouds.