What’sInsidetheCloudAnArchitecturalMapoftheCloudLandscape_sapICM_HTTP_SSL_PEER_CERT

需积分: 10 42 浏览量 2011-03-30 22:39:30 上传评论收藏 333KB PDF 举报

《云内部：一幅云计算架构地图》一文由Alexander Lenk、Markus Klems、Jens Nimis、Stefan Tai及Thomas Sandholm等作者撰写，旨在提出一个集成的云计算堆栈架构，作为未来混合应用与比较研究的参考点。文章不仅展示了现有的云计算景观如何映射到这一架构中，还识别了基础设施差距，这是他们计划在今后工作中解决的问题。 ### 云计算的核心概念云计算正作为一种“一切皆服务”（XaaS）模式崭露头角[8]，其中物理资源、基础设施以及中间件平台和商业应用程序被虚拟化，并以服务的形式提供和消费。然而，设计利用“一切皆服务”的软件系统，或可能以自身形式提供的云服务，需要深入理解众多新兴的云计算技术，以及开放云市场中已有的服务解决方案。 ### 目标与方法文章的目标在于探讨各种云技术和产品，范围涵盖了开源框架如Hadoop MapReduce，到亚马逊和谷歌等公司的商业服务，它们之间是如何相互关联的？从技术、软件架构和商业视角，我们应如何比较和理解这些云技术和产品？为了解答这些问题，作者首先提出了一个通用的云计算堆栈，将云技术和产品分类至不同的层次。通过实例解释每一层，展示该模型如何有助于阐明整个云计算景观。此外，文章还描绘了该堆栈在模拟不同供应商的云计算生态系统中的使用情况。云计算堆栈旨在促进对不同云技术和产品的讨论，包括将更复杂的提供物如Google App Engine定位在云计算景观上，并支持那些希望利用和组合现有云服务来设计软件系统的开发者。 ### 云计算堆栈架构云计算堆栈架构通常包含以下几层： 1. **基础设施即服务(IaaS)**：提供基础计算资源，如服务器、存储和网络，用户可以在此基础上构建和运行自己的应用程序和服务。 2. **平台即服务(PaaS)**：在此层，开发人员可以获得预配置的环境，用于开发、测试和部署应用程序，无需管理底层硬件和操作系统。 3. **软件即服务(SaaS)**：提供完整的应用程序供用户使用，而无需在本地安装任何软件或硬件，如电子邮件服务、办公套件等。 4. **数据即服务(DaaS)**：提供数据管理和分析工具，使用户能够访问和处理大量的数据集。 5. **功能即服务(FaaS)**：允许开发者上传代码片段或功能，当触发事件发生时执行，而无需关心底层架构。通过这样的分层结构，云计算堆栈帮助理解和组织复杂的服务生态，使开发者和企业能够更有效地选择和组合适合其需求的服务。此外，它还促进了跨不同云平台和技术栈的互操作性，为云服务的创新和整合提供了坚实的基础。 ### 结论《云内部：一幅云计算架构地图》通过对云计算景观的深度剖析，不仅揭示了云服务的层次结构，还指出了当前云计算领域存在的基础设施缺口，为未来的云计算研究和发展提供了重要的参考。对于寻求利用云计算技术的开发者和企业而言，理解并掌握云计算堆栈架构，无疑是在日益复杂的云环境中导航的关键。

资源推荐

资源详情

资源评论

What’s Inside the Cloud?

An Architectural Map of the Cloud Landscape

Alexander Lenk, Markus Klems, Jens Nimis, Stefan Tai

FZI Karlsruhe

Haid-und-Neustr. 10-14,

76131 Karlsruhe, Germany

{alenk, klems, nimis, tai}@fzi.de

Thomas Sandholm

Hewlett-Packard Laboratories

1501 Page Mill Road,

Palo Alto, CA 94304

thomas.e.sandholm@hp.com

Abstract

We propose an integrated Cloud computing stack archi-

tecture to serve as a reference point for future mash-ups and

comparative studies. We also show how the existing Cloud

landscape maps into this architecture and identify an infras-

tructure gap that we plan to address in future work.

1. Introduction

Cloud computing is emerging as a model in support of

“everything-as-a-service” (XaaS) [8]. Virtualized physical

resources, virtualized infrastructu re, as well as virtua lized

middleware platforms and business applications are being

provided and consumed as services in the Cloud. Engi-

neering software systems that use “everything-as-a-service”

and which in turn may be provided as Cloud services them-

selves, however, requires a good understanding of the nu-

merous emerging Cloud computing technologies as well as

of already available services solutions offered in the open

Cloud market.

1.1. Objective

How do the various Cloud technologies and offerings

ranging from open source frameworks like Hadoop MapRe-

duce to commercial services from Amazon and Google re-

late to each other? How do we compare and understand

these Cloud technologies and services from a technology,

software architectural, and from a business perspective?

1.2. Approach

As a ﬁrst step towards answering these questions, we

propose a generic Cloud computing stack that classiﬁes

Cloud technologies and services into different layers. We

explain each layer through examples and d emonstrate how

this model helps in explaining the overall Cloud computing

landscape. We further illustrate the use of the stack in mod-

eling a Cloud computing ecosystem of various providers.

The Cloud computing stack aims at facilitating commu-

nication about different Cloud technologies and services,

including placing more complex offerings such as Google

App Engine on the Cloud computing landscape, and at sup-

porting the design of software systems that wish to use and

compose existing Cloud technologies and services.

The different technologies and tools were categorized

in our stack based on the highest-level interface offered to

its users. We also recognize that some tools allow a wide

range of lower-level plug points, but we focus on repre-

senting the primary use of the technology, which is most

likely to happen on the highest level. Our architectural

stack provides guidance about how to combine, and inter-

change technologies. For example, a developer at The New

York Times [27] needed to transform a large number of doc-

uments and was able to obtain machines to run on from

a virtual machine provisioning system (Amazon EC2 [4])

and parallelize the processing using a parallel programming

framework (Hadoop MapReduce [30]). Others could learn

from his example but may wish to replace either the ma-

chine provisioning system or the programming framework

to meet their needs. Our categorization of existing technolo-

gies does not aim at being complete, which is impossible in

the currently rapid evolution o f the Cloud landscape, but

rather serves as a reference point or snapshot to guide fu-

ture developments. The tools we mention are for the same

reason limited to the most popular or well known.

2. Reference Stack

Distributed computing technologies targeted at enter-

prise systems integration in the 90’s such as the Open

Group’s DCE [29], and the Object Management Groups

CLOUD’09, May 23, 2009, Vancouver, Canada

CORBA [28] offered programmable interfaces to overcome

the complexities of remote p rocedure calls. Speciﬁcatio ns

such as OMA, in the CORBA case, served as reference

architectures for services offered at different levels in the

frameworks, e.g. vertical (industry domain speciﬁc) versus

horizontal (infrastructure support) services. These catego-

rizations simpliﬁed interoperability and promoted vendor

independence. A decade later the Grid community pro-

posed the Open Grid Services Architecture (OGSA) [20]

as an effort to standardize de-facto Grid service interfaces

and help adoption of Grid technologies across organizations

at a global scale. The Service Oriented Architecture (SOA)

inherent in the WS-I speciﬁcations [18] serve a similar pur-

pose for the Web services B2B community.

What differs the Cloud from these earlier technologies

is the “grass-root” evolution of a wide range of technolo-

gies from successful Web 2.0 enterprises such as Google,

Facebook, and Amazon, and the enhanced programmabil-

ity (access to APIs, RPCs, SDKs etc) offered to develop-

ers. This plethora of interfaces brings an unprecedented op-

portunity to systems integrators or mash-up technologists to

realize their business ideas with minimal investment in in-

frastructure development. It can be a daunting task to n av-

igate around the technologies in the Cloud landscape, and

although various mind maps have been proposed (e.g. [57]),

they p rovide little architectural guidance as to how the of-

ferings may be integrated.

In the spirit of earlier distributed co mputing architectures

we therefore propose a ﬁrst architectural categorization of

Cloud technologies as a stack of service types. Our stack

was inspired by the “everyting as a service” (XaaS) taxon-

omy; Infrastructure as a Service (IaaS), Platform as a Ser-

vice (PaaS), and Software as a Service (SaaS); recent de-

velopments of a Cloud stack for the HP, Intel, and Yahoo!

Open Cirrus Cloud testbed [45]; and a survey of state-of-

the-art Cloud services tools. The stack is depicted in Fig-

ure 1.

2.1. Infrastructure as a Service

On the lowest level of the infrastructure closest to the

hardware we distinguish two types o f services, Physical Re-

source Set (PRS) and Virtual Resource Set (VRS) services.

Both of these service types provide a management front-end

API for a set or pool of resources in order to allow higher

level services to automate setup and tear-down, demand-

based scalability, fail-over and operating system hosting.

Primary functionality includes starting and stopping indi-

vidual resources, OS imaging, network topology setup and

capacity conﬁguration. The PRS layer implementation is

hardware dependent and therefore tied to a hardware ven-

dor, whereas the VRS layer can be built on vendor inde-

pendent hypervisor technology such as Xen [14] or on top

of a PRS service to run in multi-vendor Clouds such as the

Open Cirrus testbed. Examples of PRS services include,

Emulab [33] and iLO [32]. VRS services include Amazon

EC2 [4], Eucalyptus [43], Tycoon [37], Nimbus [36], and

OpenNebula [53]. The reaso n to split these Reso urce Set

(RS) services into two types allows automated management

of physical as well as virtual resources. Furthermote some

Cloud applications may incur too much overhead from run-

ning on a hypervisor but might still want to use similar auto-

mated management capabilities offered by virtual machine

monitors (VMMs) and VMM management toolkits such as

the VRS examples given. Another reason for demarcation

is that different types of resources such as storage, network

and compute node resources might need to be virtualized in

different ways. However, they might still be able to have a

common PRS interface.

One level higher up in the stack but still in the

IaaS category we distinguish three types of Basic Infras-

tructure Services (BIS), computational, storage, and net-

work. Some examples are MapReduce [11] (computa-

tional), GoogleFS [52] (storage), and OpenFlow [39] (net-

work). As the highest level in the IaaS stack we con-

sider Higher Infrastructure Services (HIS). Amazon’s Dy-

namo [22], and Google’s Bigtable [17] all fall into this cat-

egory as they are typically built on top of BIS tools.

2.2. Platform as a Service

Moving up to the PaaS level of our integrated stack

we catego rize the services into Programming Environ-

ments and Execution Environments. Example of the for-

mer is Sun’s project Caroline [42] and the Django frame-

work [13], and examples of the latter are Google’s App En-

gine [24], Joyent’s Reasonably Smart [34] and Microsoft’s

Azure [40]. As seen by these examples an Execution

Environment PaaS typically also encompasses a Program-

ming Environment PaaS. You could potentially replace the

Django framework in Google App Engine with your own

Programming Environment and Microsoft Azure offers a

wide range of alternative programming tools under the

Azure runtime u mbrella. This decoupling between execu-

tion and development environments is thus represented by

having two categories in our stack model.

2.3. Software as a Service

All the applications that run on the Cloud and provide a

direct service to the customer are located in the SaaS layer.

The application developers can either use the PaaS layer to

develop and run their applications or directly use the IaaS

infrastructure. Here we distinguish between Basic Appli-

cation S ervices and Composite Application Services.Ex-

amples of Basic Application Services are the OpenId [46]

剩余8页未读，继续阅读

评论收藏

内容反馈

muzi9_17

粉丝: 52
资源: 22

What’s Inside the CloudAn Architectural Map of the Cloud Landsca...

最新资源

What’s Inside the CloudAn Architectural Map of the Cloud Landsca...

深入java虚拟机(inside the java virtual machine)

Introduction to the Architectural Reference Model for the Internet of Things

Cloud Native Programming with Golang

中英文版--Architectural Styles and the Design of Network-based Software Architectures

internet of things for architects

A Survey of the Recent Architectures of Deep Convolutional Neural Networks.pdf

Software Architecture for Big Data and the Cloud

Cloud Native: Using Containers, Functions, and Data

cloud-native-programming-golang

Practical Microservices Architectural Patterns pdf

Bluetooth Low Energy The Developer-'s Handbook.pdf

Inside Microsoft Windows Communication Foundation

Architectural Blueprints—The “4+1” View中文

Cloud.Computing.Design.Patterns.9332557306.epub

世界某地区的图书馆的建筑学报.pdf

SAP PO/PI教程 Process Orchestration The Comprehensive Guide

The Essentials of Interaction Design

Practical Microservices Architectural Patterns - Event-Based Java Microservices

09VLDB-HadoopDB An Architectural Hybrid of MapReduce and DBMS Technologies

CentOS7Oracle11gInstallHelper.zip

风电场风速及功率数据.zip

最新资源