Portable Green Cloud Services

Stephan Ulbricht

, Wolfram Amme

, Thomas Heinze

, Simon Moser

and Hans-Dieter Wehle

Friedrich-Schiller-University Jena, Jena, Germany

IBM Germany Research & Development GmbH, B

oblingen, Germany

Keywords:

Cloud Computing, TOSCA, Green IT, Policy, Energy Efﬁciency, Standardized Cloud Services.

Abstract:

The areas of cloud computing and green IT are amongst the fastest growing markets in the IT industry, until

now there are very few opportunities to combine the potential of both. In this paper, we present a method

to combine the advantages of both to create standardized and energy efﬁcient cloud services. For their de-

scription, we will use the cloud computing standard TOSCA(OASIS, 2013). Thereby, it is possible to create

standardized and model-based cloud applications which can be deployed in many cloud environments. We

will further show how it is feasible to combine policies with TOSCA to realize energy-efﬁcient management

of cloud services. To accomplish this, we will provide ideas on how to extend the TOSCA language as well

as the cloud operating environment to achieve the goal of portable, energy-efﬁcient cloud services. The core

of this work is the identiﬁcation and integration of the underlying system architecture for a common solution

concept. For this, the architectures and necessary adjustments are explained.

1 INTRODUCTION

In times of climate change and rising energy costs,

even IT companies (who are traditionally not in the

spotlight when it comes to naming the biggest pol-

luters) start to think about improving their energy ef-

ﬁciency. While moving a traditional IT application

from an data center to a modern, energy-efﬁcient vir-

tualized cloud implementation already has a positive

impact on the energy bill, such a step also allows

to improve the automated energy-management of the

application. In practice, there are two concerns: a.)

for the consumer, moving an application to the cloud

practically means committing to one cloud provider,

as there is no standardized description format that

helps to avoid a provider lock-in, and b.) in terms of

energy-efﬁciency, there is no way for a cloud service

provider to formally describe the energy guidelines

that he would like to have followed. So neither the

consumer nor the provider of a cloud service have the

possibility to inﬂuence the environmental friendliness

of an IT service - they are dependent on what the data

center or cloud provider offers, both in terms of the

infrastructure and the energy sources that get used as

well as during the actual operation of the service.

This a huge opportunity to give both cloud

service-consumers and -providers a choice: For a

cloud service consumer to state that he wants to

use ”green” cloud services, and for cloud service

providers to model the service with a ”green” mind-

set as well as to inﬂuence or deﬁne the operation of an

actual service instance. The ﬁrst thing that is needed

to address this challenge is an accurate model of the

service. With model-based cloud services, the depen-

dency on a speciﬁc data center or cloud provider can

be reduced (since they are portable), and if these cloud

services contain energy guidelines, such guidelines

could even be reﬂected when the service is operated.

Chapter 3 introduces TOSCA(OASIS, 2013), a stan-

dard for describing such model-based cloud services.

2 RELATED WORK

The efforts regarding energy-efﬁcient and environ-

mental sustainable IT solutions have increased signif-

icantly in recent years and many different approaches

and techniques have been developed. There are three

categories where energy improvement actions can be

undertaken: Hardware, Software and IT environment.

On the hardware side the simplest method for a re-

duction of energy consumption is the shutdown of un-

used devices. Such techniques are shown in (Hwang

and Wu, 2000, Sueur and Heiser, 2010, Dargie, 2012).

In the software category it is possible for multiple

users to work simultaneously on the same hardware,

Ulbricht S., Amme W., Heinze T., Moser S. and Wehle H..

Portable Green Cloud Services.

DOI: 10.5220/0004787300530059

In Proceedings of the 4th International Conference on Cloud Computing and Services Science (CLOSER-2014), pages 53-59

ISBN: 978-989-758-019-2

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

through virtualization of computing resources. Re-

search showed different approaches how environmen-

tal sustainability can be achieved by process schedul-

ing - c.f. (Duy et al., 2010, Wang et al., 2010). The

IT-Environment includes a number of components and

characteristics, ranging from the power supply via the

used cooling system to the layout of the components.

Various papers have dealt with the subject of reducing

fossil energy sources (Zhang et al., 2011, Liu et al.,

2011). These approaches propose to allocate IT re-

quests depending on available energy sources (wind,

solar, etc.) or the overall energy costs.

To achieve a sustainable energy improvement of

data centers, a holistic solution spanning hardware,

software and IT-environment is required. Analo-

gous to our solution, there is other research in this

ﬁeld, presenting frameworks and architectures to re-

alize green enhancements in cloud computing envi-

ronments - c.f. (Younge et al., 2010, Buyya et al.,

2010, Beloglazov et al., 2012, Berl et al., 2010). To

create a powerful and widely used solution concept, it

is necessary to provide a standardized approach. This

is the prerequisite for the acceptance and dissemina-

tion in the economy. In the remainder of this paper

we’ll show how this can be achieved with the help of

cloud standards and policy languages.

3 CLOUD STANDARD: TOSCA

Chapter 1 already outlined the need for standardized,

model-based cloud services. To ensure the interoper-

ability and portability of cloud services, the standards

body OASIS has started the standardization initiative

TOSCA (Topology and Orchestration Speciﬁcation

for Cloud Applications) (OASIS, 2013). TOSCA is

a meta-language for the model-based description of

cloud services. This language not only allows the def-

inition of the topology of an application, but also of

its management behavior by requiring business pro-

cesses which are operating directly on the application

topology and thus deﬁne the operational semantics.

The aim of TOSCA is to create standardized cloud

services and simplify exchangeability. These stan-

dardized cloud services then get executed by a run-

time entity called a ”TOSCA container”, which e.g.

interacts with a hypervisor to install the topology and

interprets the management plans to manage an ac-

tual service instance. As Figure 1 shows, a TOSCA-

based cloud service is described by a service template,

which is made up of a topology template and a (set

of) plan(s). The topology template deﬁnes the struc-

ture of the service, i.e., the base components and their

relationships. A component can be a VM, an OS, a

Figure 1: TOSCA service template.

network connection, etc.

Build- and Management Plans deﬁne the business

process models which control the operational man-

agement behavior of the service, operating on the

topology. If modeled correctly, the operational man-

agement behavior spans the complete life cycle of

a service: A build plan for setting up the service,

plans for any operation during its lifetime (e.g., trig-

ger backups, install patches, elastic scaling, ...), as

well as a termination plan when the service gets de-

provisioned. The scope and the implementation of the

plans are speciﬁc to the service and determined by the

service modeler. When ﬁnished, the service modeler

creates a Cloud Service Archive (CSAR), a package

that contains the topology template, the plans and all

other required artifacts (e.g., image ﬁles, scripts, etc.).

These CSAR ﬁles can then be exchanged between

different IT environments. More precisely, a topol-

ogy template can be represented by a graph, where

the nodes are the base components (e.g. a VM) and

the edges are the relationships between the compo-

nents. Both nodes and relationships are ﬁrst deﬁned

outside of a concrete service, as they usually repre-

sent reusable building blocks. They are called Node

Types and Relationship Types. A Node Type is a node

of the type ”VM” when used outside of a topology,

but once added to a template (potentially with some

properties attached), it becomes a node template. The

same is true for the edges of the graph: Relationship

Types deﬁne abstract relationships (like ”hosted on”

or ”connected to”), but when used in a topology tem-

plate they become relationship templates, describing

the relationship between the node templates and also

deﬁning the potential states of a service instance.

The structure and functionality of service tem-

plates will be shown by example of an LAMP-

infrastructure. The corresponding topology template

CLOSER2014-4thInternationalConferenceonCloudComputingandServicesScience

has the elements ”Linux OS”, ”Apache Web Server”,

”MySQL Database” and ”PHP Module”. The web

server and the database are connected via the relation-

ship ”hosted on” with the operating system, and so is

the PHP module with the web server. The underlying

relationship template ”hosted on type” is character-

ized by the source and destination element. The sec-

ond type of relationship (connects to) exists between

the PHP module and the database. The description of

a node type, e.g. the Web Server, deﬁnes properties

such as the IP address of an instance.

Another feature of TOSCA is the fact that it al-

lows policies for certain elements, e.g. for Service

Templates and Node Templates. Policies enable the

dynamic control of the behavior, i.e. rules can be de-

ﬁned for access control (authorization policy) or to

specify requirements on a system (obligations poli-

cies). Such a mechanism is useful for the combination

with the topic of Green IT. Policies have advantages

like reusability, higher efﬁciency, expandability and

better conﬂict management (Tonti et al., 2003) when

it comes to managing large services or systems. Poli-

cies consist of rules that control the behavior of com-

puter systems, derived from overarching goals such

as company policy, service level agreements or safety

requirements or for describing and enforcing e.g. en-

ergy efﬁciency requirements.

4 GREEN CLOUD SERVICES:

SYSTEM AND ARCHITECTURE

To create a holistic solution that brings together

model-based cloud services with Green IT policies

end-to-end, we need to examine three things: ser-

vice lifecycle, architectures of Cloud Management

Platform and Policy Management Systems and their

descriptor formats. The lifecycle of a model-based

cloud service can be divided into four phases: mod-

eling, deployment, instantiation and runtime. In

the modeling phase, the TOSCA-modeler creates the

topology template, plans, scripts, images and all other

required artifacts required for the execution of the ser-

vice and packages them into an archive (CSAR). In

the next phase, the service deﬁnition and all related

artifacts are stored in a database component, where

they are made accessible by the public through e.g.

a service catalog. Once published, the cloud service

consumer can select a service from the service cat-

alog - this triggers the instantiation of the service.

The core component during the instantiation phase is

the TOSCA-container, as it orchestrates the genera-

tion of the service, e.g. generating the virtual ma-

chines, installing the needed software, setting up the

Figure 2: Overview of the components involved in a

TOSCA Cloud Management Platform.

network connections etc. by running the associated

plans which operate directly on the topology. Figure

2 gives an overview of the involved components.

The next step to create a holistic solution is to map

the components from the Cloud Management Plat-

form to key architectural components of a policy man-

agement system (IETF, 2001, OASIS, 2005). For il-

lustration, we use the architecture model provided by

the Internet Engineering Task Force (IETF, 2001). In

this model, the basic components of a policy system

are described - Figure 3 gives an overview.

The responsibility of the Policy Management Tool

is the creation, modiﬁcation and deployment of poli-

cies, the transformation from abstract to concrete

policies as well as error handling. The Policy Reposi-

tory provides a storage for the policies, as well as pro-

vides the policies when they should be provisioned.

Finally, the Policy Decision Point interprets policies,

receives events and determines the appropriate ac-

tions. These components match nicely to the pieces

of a TOSCA cloud management platform. To illus-

trate and motivate the combination into a holistic sys-

tem, we examine each lifecycle phase: In the Model-

ing phase, the TOSCA speciﬁcation allows for the in-

jection of policies at different points within a topology

template. The policy is part of the topology template

description and is stored within the CSAR. The mod-

eler can either directly specify the policy code inside

the topology template or refer to it by a reference (c.f.

Figure 3: Overview of the components involved in a Policy

System, according to (IETF, 2001).

PortableGreenCloudServices

section 5). The reference allows for the integration of

externally deﬁned policies. Thus, the TOSCA mod-

eling supports creating and changing policies. Dur-

ing the modeling phase, all attributes of the policy tag

have to be deﬁned. The actual content of a policy is

described within the tag. In the Deployment phase,

the policy management tool component of the IETF-

architecture is also responsible for the distribution of

policies. In TOSCA, all artifacts including policies

are grouped into an archive and stored in a service cat-

alog, which is a implementation of the policy reposi-

tory. When a service has been requested by a user, we

enter the Instantiation phase. The CSAR archive with

the artifacts is loaded into the TOSCA-container. In

the receiving environment, the package is parsed and

the individual artifacts are analyzed by a topology en-

gine, a part of the TOSCA Container, which also real-

izes the order of the elements. The engine implements

the topology template with the help of provisioning

mechanisms into the production system.

Figure 4: TOSCA- and Policy System Architectures com-

bined.

To create an instance of an application, a build

plan is executed. For the interpretation and execu-

tion of the plan, the TOSCA container uses a process

engine which communicates with the hypervisor and

triggers e.g., the creation of virtual machines. Addi-

tional software is installed on the virtual machines by

starting installation scripts. The TOSCA Container

picks the policy implementation based on the URI of

the policy deﬁnition, but for the processing of the in-

coming events and to determine the actions to be per-

formed, an additional policy engine is needed. It has

to be able to afford all functions of the policy deci-

sion point. To respond to events, the policy engine

includes an event handler component. The task of the

event handler is to relate the events to the correspond-

ing policies. Afterwards, the policies are interpreted,

i.e., conditions are evaluated and the resulting instruc-

tions are determined. In the Runtime phase, the man-

agement and control of virtual machines is done by

the hypervisor. The instructions, determined by the

policy engine, will also be implemented by the hyper-

visor (policy enforcement point). Since virtual envi-

ronments are very complex and include many prop-

erties, special monitoring agents are used to ensure a

ﬂexible and comprehensive monitoring. They are in-

stalled on the servers to monitor all relevant metrics.

The considerations in this section have shown that it

is possible to map the IETF- to the TOSCA- model.

In Figure 4, the TOSCA-components and their equiv-

alents are shown.

5 GREEN CLOUD SERVICES:

METADATA FORMAT

After the combination of a TOSCA cloud manage-

ment platform with a policy system has been outlined,

 

1 <S e r v i c e T e m p l a t e . . . >

2

3 <Topolo g y T e m p l a t e>

4 <No de Te mpl at e i d =” VmApache” name=”VM f o r

Apach e ” t y p e =” ns 1 : V i r t u a l M a c h i n e ”>

5 . . .

6

7 <P o l i c y

8 name=” Lo wW or kl oa dP ol ic y ”

9 p o l i c y R e f = ” l amp : L ow Wor kl oad Po lic y−VmApache”

10 p o l i c y T y p e =” ns 1 : L ow Wo rk lo a d P ol ic y ” />

11

12 </ No de Tem pl at e>

13 <No de Te mpl at e i d =”VmMySQL” name=”VM f o r

MySQL” t y p e = ” n s 1 : V i r t u a l M a c h i n e ”>

14 . . .

15 </ No de Tem pl at e>

16 </ T o p o lo g y T e mp l a t e>

17

18 <P o l i c y T y p e

19 name=” Lo wW or kl oa dP ol ic y ”

20 t a r g e t N a m e s p a c e = ” . . . ”>

21 <P r o p e r t i e s D e f i n i t i o n e l e m e n t = ” n s1 :

Lo wW or kl oa dP o l i cy ” />

22 <A pp l i e s T o>

23 <No de T yp e Re f er e nc e t y p e R e f =” ns 1 :

V i r t u a l M a c h i n e ” />

24 </ A p p l i e s T o>

25

26

27 </ S e r v i c e T e m p l a t e>

 

Figure 5: Excerpt of a service template describing an

energy-efﬁcient LAMP service.

CLOSER2014-4thInternationalConferenceonCloudComputingandServicesScience

let’s illustrate input to such a holistic system based on

the LAMP service template.

In TOSCA, a policy also follows the type / tem-

plate pattern previously introduced: The Policy Type

deﬁnes the properties of policy (e.g. the data needed

to inﬂuence a behaviour), whereas Policy Templates

provide actual values for the properties in a concrete

scenario.

Figure 5 shows an excerpt from a Service Tem-

plate for the LAMP service: In lines 4 and 13, two

node templates have been deﬁned, representing a

WebServer and a Database. To emphasize our point,

think of them as a Web Server Cluster and a Database

Cluster. In line 19, a LowWorkloadShutdownPolicy

has been attached to the Web Server Cluster. In Line

22, the payload of this policy is referenced.

The payload just deﬁnes the properties that an

event is required to carry, in order for the policy def-

inition point to evaluate the policy and trigger an ap-

propriate action. In our example of shutting down a

cluster member when the workload becomes too low,

we need only two properties: the old and the new

workload value. So far we did not deﬁne an action

that needs to be taken, nor did we deﬁne a concrete

policy language. Policies in TOSCA can be deﬁned

independently of a policy language. While this sup-

ports portability, it requires adaption to a speciﬁc lan-

guage for every cloud provider. But TOSCA allows

us also to provide a policy in a speciﬁc language:

 

1 <P o l i c y T y p e name=” Lo wW or kl oa dP ol ic y ”

2 p o l i c y L a n g u a g e =” xs : h t t p : / / www . p o n d e r 2 . n e t / ”

3 t a r g e t N a m e s p a c e =” . . . ”>

5 <P r o p e r t i e s D e f i n i t i o n e l e m e n t = ” n s1 :

Lo wW or kl oa dP o l i cy ” />

6 <A pp l i e s T o>

7 <N od e Ty p eR e fe r en c e t y p e R e f = ” n s 1 :

V i r t u a l M a c h i n e ” />

8 </ A p p l i e s T o>

9

 

Figure 6: PolicyType from Figure 5 with a Policy Type de-

ﬁned in the language Ponder2.

In our prototype, we have chosen a policy lan-

guage called Ponder2 (PONDER, 2013). Ponder2

is a declarative, object-oriented language that allows

for the deﬁnition of both, obligation and authoriza-

tion policies. Ponder2 can be used in a wide range

of different devices ranging from ad-hoc networks to

distributed systems. A Ponder2 system provides the

ability to manage a variety of objects such as sen-

sors, alarm systems, routers, etc. These basic ele-

ments are called managed objects. They are created in

Java and their provided functionalities can be adapted

to the requirements of an environment and expanded

accordingly. The standard distribution of Ponder2 in-

cludes three predeﬁned object types: domains, events

and policies. Additional functionality can be added to

a system by means of new managed objects. To al-

low a dynamic interaction between heterogeneous IT-

Environments, Ponder2 utilizes so called Self Man-

aged Cells (SMC). SMCs represent independent sys-

tems, i.e. a set of hardware and software components

that are able to manage themselves. The communica-

tion between the different components occurs through

an content-based event bus. For the message ex-

change, the proprietary language PonderTalk is used.

The Java objects implement an interface (Managed

Object) that enables the mapping from PonderTalk to

Java methods. For the communication between differ-

ent systems, the Ponder2-Framework offers the possi-

bility to access external Managed Objects. Thus, ob-

jects can be exported and imported between different

SMCs.

To make the holistic system work, leveraging the

Ponder2 technology, several steps are necessary: a.)

An event emitter has to be installed on the virtual ma-

chines - in our example, both on the mySQL VM

and on the WebServer VM. Conceptually, it is an

agent that monitors relevant metrics from the VMs

(e.g., the CPU load) and triggers respective events.

This design is very much in line with industrial cloud

management systems, where a set of agents (for var-

ious purposes) are installed on top of the provisioned

VMs. b.) The produced event has to be send to the

TOSCA-container where an obligation policy inter-

preter receives the event and looks for applicable poli-

cies. This requires c.) correlating the event to a run-

ning instance and then identifying the model where

this instance was derived from to get the policy. The

policy then evaluate their conditions and invoke the

corresponding actions (Keoh et al., 2007). Figure 7

illustrates how the concrete Ponder2 code looks like:

 

1 e v e n t : = r o o t / f a c t o r y / e v e n t c r e a t e : # ( ”name ” ”

new ” ” ol d ” ) .

2 r o o t / e v e n t a t : ” gr e e n E v e n t ” p u t : e v e n t .

3 p o l i c y : = r o o t / f a c t o r y / e c a p o l i c y c r e a t e .

4 p o l i c y e v e n t : r o o t / e v e n t / g r e e n E v e n t .

5 p o l i c y c o n d i t i o n : [ : name : o l d V a l u e : newVa lue

6 name == ” Work load ” & ( new < 3 0 ) & ( o l d >= 30 )

] .

7 p o l i c y a c t i o n : [

8 / / E x e c u t e sh u t do w n Cl u s t e r M e mb e r P l a n t o

sh ut do wn a c l u s t e r member ] .

9 r o o t / p o l i c y a t : ” workload L ow ” p u t : p o l i c y .

10 p o l i c y a c t i v e : t r u e .

 

Figure 7: Concrete LowWorkloadPolicy in PONDER2.

PortableGreenCloudServices

In Figure 7, a management plan called shutdown-

ClusterMember is triggered by the policy, following

the event-condition-action (ECA) rule used in policy

systems. Figure 8 illustrates the plan: First the plan

has to check whether the cluster manager is available

- obviously, this is a safety measure. If successful, the

plan issues a request against the cluster member to

shut down. This step might require more detail, e.g.,

if it is a database we might want to stop the datasource

ﬁrst, to avoid data inconsistencies, but conceptually

this is the step that needs to be taken. Once stopped,

the cluster member can be removed from the cluster

manager and thus will no longer consume energy.

Figure 8: The shutdownClusterMember Plan.

A policy-based mechanism to shut down a clus-

ter member to save energy is just one example how

policies can be used to realize energy-efﬁcient cloud

services. Other use cases can be imaged: If clouds

would have an energy certiﬁcation, i.e. the data center

is operated on renewable energy, a cloud service could

declare a policy requiring such a certiﬁcation, and if

not fulﬁlled the service model is not allowed to be in-

stantiated. Furthermore, policy-based scheduling or

workload planning or other energy-saving, cloud ser-

vice speciﬁc measures can be imagined.

6 CONCLUSION

In this paper, we have shown how to design, develop

and run standardized, energy-efﬁcient cloud services.

We extended a TOSCA cloud management platform

with policy handling parts. We showed how to com-

bine TOSCA models with policies (in the policy lan-

guage Ponder2). Thereby we realized description and

execution of portable green cloud services. Ponder2

has been chosen as our policy language because of its

dynamicity and versatility. We believe this work to be

the foundation to combine two of the most important

future markets of the IT industry. To our knowledge

there is no work conducted to combine cloud services

with Green IT aspects so far, so this work to com-

bine cloud services with ecological aspects promises

extraordinary potential for cloud service providers.

With cloud computing in general becoming more and

more a commodity, the offering of energy efﬁcient

services will become a competitive advantage as well

as it will serve the environment.

This work was partially funded by the BMWi

project Migrate! (01ME11055).

REFERENCES

Beloglazov, A., Abawajy, J., and Buyya, R. (2012). Energy-

aware resource allocation heuristics for efﬁcient man-

agement of data centers for cloud computing.

Berl, A., Gelenbe, E., Girolamo, M. D., Giuliani, G., Meer,

H. D., Dang, M. Q., and Pentikousis, K. (2010).

Energy-efﬁcient cloud computing.

Buyya, R., Beloglazov, A., and Abawajy, J. (2010). Energy-

efﬁcient management of data center resources for

cloud computing: A vision, architectural elements,

and open challenges. In Int. Conf. on Parallel and

Distributed Processing Techniques and Applications.

Dargie, W. (2012). Analysis of the power consumption of

a multimedia server under different dvfs policies. In

CLOUD. IEEE.

Duy, T. V. T., Sato, Y., and Inoguchi, Y. (2010). Perfor-

mance evaluation of a green scheduling algorithm for

energy savings in cloud computing. In Parallel & Dis-

tributed Processing, Workshops and Phd Forum.

Hwang, C.-H. and Wu, A. (2000). A predictive system shut-

down method for energy saving of event-driven com-

putation.

IETF (2001). Ietf policy model. http://tools.

ietf.org/html/rfc3060.

Keoh, S. L., Twidle, K., Pryce, N., Schaeffer-Filho, A. E.,

Lupu, E., Dulay, N., Sloman, M., Heeps, S., Strowes,

S., Sventek, J., and Katsiri, E. (2007). Policy-based

management for body-sensor networks. In 4th Int.

Workshop on Wearable and Implantable Body Sensor

Networks. Springer Berlin Heidelberg.

Liu, Z., Lin, M., Wierman, A., Low, S., and Andrew, L.

(2011). Geographical load balancing with renewables.

OASIS (2005). Xacml policy model extensible access con-

trol markup language (xacml) version 2.0, pp. 16-18.

OASIS (2013). Tosca - topology and orchestration speciﬁ-

cation for cloud application.

PONDER (2013). http://www.ponder2.net.

Sueur, E. L. and Heiser, G. (2010). Dynamic voltage and

frequency scaling: The laws of diminishing returns. In

Proc. of the 2010 int. conf. on Power aware computing

and systems. USENIX Association.

Tonti, G., Bradshaw, J. M., Jeffers, R., Montanari, R., Suri,

N., and Uszok, A. (2003). Semantic web languages

for policy representation and reasoning: A compari-

son of kaos, rei, and ponder. In The Semantic Web-

ISWC 2003. Springer Berlin Heidelberg.

Wang, L., von Laszewski, G., Dayal, J., and Wang, F.

(2010). Towards energy aware scheduling for prece-

dence constrained parallel tasks in a cluster with dvfs.

In CCGrid. IEEE/ACM.

CLOSER2014-4thInternationalConferenceonCloudComputingandServicesScience

Younge, A. J., von Laszewski, G., Wang, L., Lopez-

Alarcon, S., and Carithers, W. (2010). Efﬁcient

resource management for cloud computing environ-

ments. In Green Computing Conf. IEEE.

Zhang, Y., Wang, Y., and Wang, X. (2011). Greenware:

Greening cloud-scale data centers to maximize the use

of renewable energy. In Middleware 2011.

PortableGreenCloudServices