TOWARDS A NEW PaaS ARCHITECTURE GENERATION

Claudio Guidi

, Paolo Anedda

and Tullio Vardanega

Department of Mathematics, University of Padova, Padua, Italy

CRS4, Technology Park, Pula (CA), Italy

Keywords:

PaaS, IaaS, SaaS, SOA, Architectures, Services.

Abstract:

In this paper we present our vision for a next-generation Cloud Computing PaaS layer intended for openness

and federation. We base our vision on the principles of the Service Oriented Architecture paradigm, and

discuss some design details of the internals of the PaaS we are currently prototyping.

1 INTRODUCTION

The PaaS is a fundamental layer of the Cloud Com-

puting stack. It is the connection layer between the

IaaS, the computing, storage and networking infras-

tructure, and the SaaS, where applications become

available to the user. The PaaS provides the abstrac-

tions needed for developing applications abstracting

away from the negotiation, contention and reclama-

tion of the bare execution resources on which applica-

tions will eventually run. More speciﬁcally, the PaaS

provides all the functionalities required for the devel-

opment, the deployment and the monitoring of ser-

vices at the level of SaaS. In our view, the PaaS also

governs the resource requests that must be made to

the underlying IaaS to meet the service level agree-

ments separately deﬁned with the SaaS and the IaaS:

one between the user and the application provider; the

other between the application provider and the infras-

tructure owner.

At present there is no clear picture of where the

future evolution of Cloud Computing PaaS layer will

lead. Current evidence shows that they will continue

to be provided by big IT suppliers (e.g.: Google,

Amazon, SalesForce). However, the scenario could

as well signiﬁcantly change if open-cloud ideas such

as those proposed in (opencloudmanifesto.org, 2009)

will meet with support. In the latter case the Cloud

should be an open horizontal platform where differ-

ent players can freely interact with one another, with

obvious beneﬁts for companies, developers and end

users alike.

We contend that the role played by PaaS will be

instrumental to determining how Cloud Computing

will evolve in the future. One extreme is the domi-

nance of closed solutions, such as those currently pro-

posed by worldwide leaders (cf. e.g. Google App

Engine (Google, 2011)), in which case Cloud Com-

puting will be a huge vertical infrastructure controlled

only by few actors. At the other extreme there is in-

stead prevalence of open and standardized architec-

tures, which enable an open Cloud scenario.

On account of these observations, it is reasonable

to anticipate Cloud Computing PaaS layers realized

as the mix of offerings from private and custom in-

frastructures and open solutions. As far as open in-

frastructures are concerned, interesting though initial

proposals have been formulated by EU projects like

IRMOS (EU, 2011a) and RESERVOIR (EU, 2011b),

which prototyped demonstrative cloud infrastructures

for the development of multimedia applications, and

the deployment of services over the boundaries of dif-

ferent domains, respectively. Those results form a

good starting point for furthering the concept of PaaS

we envision. Yet we must acknowledge that, to the

best of our knowledge, there does not currently ex-

ist any consolidated understanding of the PaaS frame-

work architecture and rationale. There also is no stan-

dard deﬁnition of the interaction protocols between

the IaaS and the PaaS, and between the PaaS and the

SaaS.

The concept we present in this paper aims at

proposing an initial model, termed PaaSSOA, for fa-

cilitating the development of next-generation PaaS

frameworks. Our model captures the main functions

which characterize the Cloud from the PaaS perspec-

tive and the interactions the PaaS has to have with the

two adjacent levels in the Cloud SPI stack. Our pro-

posal should be considered in the context of an open

Cloud Computing infrastructure where the PaaS layer

279

Guidi C., Anedda P. and Vardanega T..

TOWARDS A NEW PaaS ARCHITECTURE GENERATION.

DOI: 10.5220/0003914102790282

In Proceedings of the 2nd International Conference on Cloud Computing and Services Science (CLOSER-2012), pages 279-282

ISBN: 978-989-8565-05-1

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

should be distributed, open and freely composed. The

vision which inspires our effort focuses on the Ser-

vice Oriented Architecture paradigm, which facili-

tates the construction of system architectures that are

modular, scalable and standardized. The use of a

Service Oriented Architecture for designing a PaaS

reference model has two main advantages: (i) it al-

lows for a standard and well-deﬁned separation be-

tween the PaaS and the IaaS on the one hand, and

between the PaaS and the SaaS on the other hand; (ii)

it also warrants a high degree of ﬂexibility, adaptabil-

ity and modularity within the PaaS itself, which are

very desirable architectural qualities. Interestingly,

IRMOS (EU, 2011a) based its SPI vision on clear

principles of service orientation, even though without

providing a general rationale for realizing a SOA-like

PaaS layer.

Besides providing a general reference for our PaaS

concept, with the deﬁnition and prototyping of PaaS-

SOA we also investigate the mechanisms involved

in the management of application-level services de-

ployed on the IaaS in the form of a SOA: we refer

to them as meta-SOA mechanisms. In Section 2 we

present PaaSSOA by illustrating its architecture and

main components. In Section 3 we discuss the issues

related to the IaaS layer as seen from the perspective

of PaaSSOA. In Section 4 ﬁnally we present some ini-

tial conclusions and plan for future work in this direc-

tion.

2 OUR VISION: PaaSSOA

Figure 1 depicts the main architecture of PaasSOA. In

it, we focus on the relationship in place between the

PaaS and the SaaS on the one hand, and between the

PaaS and the IaaS on the other hand.

Figure 1: Main PaaSSOA architecture.

We see the PaaS layer as composed of three main

blocks: Tools and Functions, which should be typ-

ical of a PaaS; and the Service Container, which is

more speciﬁc of PaaSSOA. The Tools block provides

the tools for designing and developing SOA and in-

cludes a web GUI designer for developers. The Func-

tions block offers all the services which provide the

more classic PaaS functionalities such as deployment

and scheduling. The Service Container hosts the de-

ployed services so that they can be reachable by both

the end user and the developer. The end user needs to

access the deployed services for ”consuming” them;

the developer needs to monitor the deployed services

to keep their performances under control. This is the

reason why we have placed this particular block in

the middle between the PaaS and the SaaS layers.

Next we present and discuss the fundamental blocks

of PaaSSOA.

Figure 2 depicts the architecture of the Tool and

Functions blocks.

Figure 2: Tools and Functions architecture.

Blocks ID, SSD, WD, ConnD and CD represent

the design tools needed for developing a SOA-based

application or service. The function block is repre-

sented by the Service Registry (SR) block and the Ser-

vice Deployment and Monitor (SDM) blocks.

The SOA tools we envision to supply with PaaS-

SOA include the following: Interface Designer (ID),

a graphical tool for designing service interfaces such

as for example WSDL interfaces; Simple Service De-

signer (SSD), a tool for developing simple services

able to connect to data storage; Workﬂow Designer

(WD), a tool for designing orchestrators able to inter-

act with other services; Service Deployer and Moni-

tor (SDM), an administrative tool for deploying ser-

vices and monitoring them during execution; Chore-

ography Designer (CD): a tool for designing ser-

vice choreographies, which address SOA system de-

sign from a global perspective, like in WS-CDL (Ka-

vantzas et al., 2005).

As far as the function block is concerned, the

SDM service implements some important tasks such

as: deployment, to deploy new services or migrate the

existing ones in different service containers; sched-

uler,to schedule service deployment depending on the

available resources; negotiator, to negotiate resource

allocations with the IaaS in accord with the stipulated

the Service Level Agreement; monitor, to monitor

the SLA conformance of the deployed services. In

CLOSER2012-2ndInternationalConferenceonCloudComputingandServicesScience

280

case of under-performance, the Monitor can activate

the scheduler and the deployer to reclaim the unused

slack and assign it to respond to the request for new

resources.

The Service Container block is part of the PaaS

but it is also reachable also from the SaaS level as

an endpoint for accessing deployed services. More-

over, the Service Container must be deployed within

the virtual machine images allocated and controlled

by the IaaS. The Service Container, termed SOABoot,

starts at the boot of every individual virtual machine

deployed for PaaSSOA. The SOABoot is a meta-

service which manages a service registry for storing

all the service descriptions (e.g. endpoint locations

and interfaces) of the services executed in the corre-

sponding virtual machine. The SOABoot is able to

receive service implementations and store them as it

is able to remove them. Moreover, it offers the pos-

sibility to remotely control the activation and the de-

activation of the stored services. As shown in Figure

3, the set of all the SOABoot services represents the

Service Container. The Deployer block manages all

the SOABoots which form the Service Container.

Figure 3: SOABoot architecture.

The key aspect of PaaSSOA is the high level of

ﬂexibility it aims to offer, as evidenced by the fact

that it provides additional means for governing the ef-

ﬁciency and performance of service deployment from

the SaaS, over those traditionally offered by the IaaS.

In the event of under-performance detected in the de-

ployed services, the PaaSSOA scheduler can take one

of two actions: 1) request a new virtual machine

(equipped with a SOABoot) to the IaaS so as to in-

crease the set of bare resources availed to the user; 2)

organize and manage the deployed services so as to

optimize their individual and collective performance.

for example it could move a service with low perfor-

mance to another SOABoot which can guarantee a

higher level of performance. Interestingly, this action

can be taken without involving the IaaS.

Decision 2 makes it possible to implement opti-

mization rules from within the PaaS level, without in-

curring dependence on the IaaS.

3 INTERACTING WITH THE IaaS

LAYER

In a typical Cloud infrastructure, whether public or

private, the system exploits the possibility to share

the physical resources among the different virtual ma-

chines in order to minimize the waste of the unused

resources and maximize the possibility of supporting

multiple users. The many beneﬁts introduced by mul-

tiplexing physical resources among different virtual

machines cannot be doubted. However, without a pre-

cise policy for the governance of physical resource

sharing, the performance of the virtual machines can

be negatively affected by wrong utilization. For ex-

ample, intensive access to disk and frequent request

for exclusive access to physical resources (e.g., GPU,

Inﬁniband card, etc.) can cause important delays and

incur massive performance decay.

In order to build a ﬂexible system and to support

multiple technologies and actors, we want to maintain

separation of concerns between the PaaS and the IaaS

layers. Our approach consists in providing a bidirec-

tional interface through which the two layers are able

to constantly negotiate SLAs according to the system

changes, in order to ﬁnd a trade-off between the re-

quests of both the layers.

As shown in Figure 1 the main PaaSSOA actors

involved in the interactions between the PaaS and the

IaaS layers are the Functions and the Resource Man-

ager blocks. In fact, as depicted in Figure 2, the Func-

tion block is composed of a CDM block which has a

Negotiator component which is in charge of commu-

nicating with the IaaS layer. As shown in Figure 4

instead, the Resource Manager is composed of a Re-

source Manager itself (RM) and the Monitor Agents

(MAs). The RM is in charge of maintaining the status

of the utilization of the physical resources and, ac-

cording to the scheduler chosen, to allocate them to

the virtual machines. The MA is in charge of moni-

toring a single physical resource and reports its status

to the RM. Since the status of the IaaS infrastructure

can be impacted by the performances of the physical

resources as well as by the virtual ones, it is very im-

portant to monitor both using two different MAs: the

Physical Monitor Agent (PMA) and the Virtual Mon-

itor Agent (VMA).

Figure 4: The IaaS Resource Manager Architecture.

TOWARDSANEWPaaSARCHITECTUREGENERATION

281

The PMA leverages the resource functionalities

in the intent of monitoring Physical Metrics such as

Availability, Memory Available for VMs, Memory

Used by VMs, CPU Used, CPU Idle, Number of

CPUs.

The VMA leverages the hypervisor functionali-

ties for the purpose of monitoring virtualization met-

rics, which include the following parameters: a) VM

Metrics such as Availability, Process Virtual Memory

Size, Process Resident Memory Size, Process Page

Faults, Process CPU System Time, Process CPU User

Time, Process Uptime, Process CPU Total Time, Pro-

cess CPU Usage, VM CPU Wait, VM CPU Used, VM

CPU Sys, VM Memory Shares, VM Memory Min-

imum, VM Memory Maximum, VM Memory Size,

VM Memory Ctl, VM Memory Swapped, VM Mem-

ory Shared, VM Memory Active, VM Memory Over-

head, VM Uptime; b) VM Disk Metrics such as Avail-

ability, Reads, Writes, Bytes Read, Bytes Written; c)

VM NIC Metrics such as Availability, Packets Trans-

mitted, Packets Received, Bytes Transmitted, Bytes

Received.

All the information coming from the MAs will al-

low the RM to implement the best scheduling policy

to achieve the optimal conﬁguration of the system.

For example, a proportional thresholding (H. Lim and

Parekh, 2009) approach could be used to determine

the target range of the variables according to which a

reconﬁguration event needs to be ﬁred.

The prototype implementation of the system vi-

sion we presented in this paper, uses the VIDA

toolkit (Anedda, 2011), a novel software architecture

for the deployment of virtual clusters currently devel-

oped as a part of one of the research activities of one

of the authors’. The VIDA architecture is designed to

dynamically allocate resources to applications via a

general control plane orchestrating the system’s com-

putational and network components. Hence, it meets

our best expectation at the PaaS to IaaS interface.

4 CONCLUSIONS

In this paper we have illustrated the highlights of our

vision for a new approach to the development of an

open PaaS framework which captures the main func-

tions which characterize the Cloud from the PaaS per-

spective. In our discussion we have highlighted the

interactions that the PaaS layer ought to have with the

two adjacent levels in the Cloud SPI stack in order to

draw maximum beneﬁt the mediator potential of its

role.

By virtue of the four constituent blocks sketched

in ﬁgure 1, we were able to clearly deﬁne and appor-

tion the responsibilities of each component of PaaS

architecture as well as to capture the interactions re-

quired among the different layers of the Cloud SPI

stack. Moreover, for each block in the envisioned ar-

chitecture we provided details on the inner working of

the relevant components. We also sketched the com-

munication interface to be put in place between the

PaaS and the IaaS layers, outlining the main function-

alities and parameters to ﬂow across them.

We are currently developinga PaaSSOA prototype

using the Jolie (Guidi and Montesi, 2011) technology:

the demonstrator code may be downloaded at (Guidi,

2012).

ACKNOWLEDGEMENTS

We are grateful to Giovanni Giacobbi, member of our

team at the University of Padova, for his suggestions

and interesting discussions during the write-up of this

paper.

REFERENCES

Anedda, P. (2011). Virtual Infrastructures Deployment Ar-

chitecture. http://project-vida.sourceforge.net/.

EU (2011a). Irmos - Interactive Realtime Multimedia Ap-

plications on Service Oriented Infrastructures. http://

www.irmosproject.eu/.

EU (2011b). Reservoir - Resources and Services Virtualiza-

tion without Barriers. http://62.149.240.97/.

Google (2011). Google App Engine. http://

appengine.google.com/.

Guidi, C. (2012). PaaSSOA: Paas Service Oriented Archi-

tecture. http://sourceforge.net/projects/paassoa/.

Guidi, C. and Montesi, F. (2011). Jolie. http://

www.jolie-lang.org.

H. Lim, S. Babu, J. C. and Parekh, S. (2009). Automated

control in cloud computing: Challenges and opportu-

nities. In First Workshop on Automated Control for

Datacenters and Clouds.

Kavantzas, N., Burdett, D., Ritzinger, G., Fletcher, T., La-

fon, Y., and Barreto, C. (2005). Web Services Chore-

ography Description Language Version 1.0. W3C

Candidate Recommendation 9 November 2005.

opencloudmanifesto.org (2009). Open Cloud Manifesto.

http://www.opencloudmanifesto.org.

CLOSER2012-2ndInternationalConferenceonCloudComputingandServicesScience

282