Open
‐
source
platform
‐
as
‐
a
‐
service
Dana Petcu
Dana
Petcu
West
University
of
Timisoara
&
Institute
e
‐
Austria
Timisoara
1
Romania
Overview
Overview
1. The
problem:
vendor
‐
lock
‐
in
in
Clouds
2. The
solution?
Interoperability
and
portability
3. The
role
of
open
‐
source
platforms
4. mOSAIC case
studyy
5. Research
challenges
6. Further
steps
p
2
2
Vendor lock-in due to proprietary APIs
Vendor lock in, due to proprietary APIs
API
spec
spec
How
to
protect
my
application
from lock in?
API
spec
01011001
from
lock
‐
in?
API
spec
3
3
Interoperability and portability: challenges
Interoperability and portability: challenges
Scenarios
using
multiple
Clouds
Multi
‐
dimensional
problem
Federation
01 01 01 01 01 01POLICY:
Federate,
communicate
of Clouds
011 01 1 01 1Cloud
RUNTIME:
between providers
01 01 1InterOp
DESIGN:
RUNTIME:
Migration
support
4
DESIGN:
Abstract the programmatic
differences
Markets of Clouds
4
01 01 1 01 01 1Interoperability and portability: approaches
Interoperability and portability: approaches
E.g.
Levels
Techs
E g
S
i
Business
Strategies,
regulations,
mode
of
use
Function
calls
and
Domain
specific
lang.
E.g.
Automated
translation
in
code
Appl &
service
Semantic
responses
Automation,
configuration
Standards
in
deployment
& migration
Abstraction
layers
Semantic
repositories
UCI
Mediators,
frame
‐
works
(SLA@SOI)
Techs
&
infrastr
Management
&
migration
Protocols
for
requests/responses
Pre
‐
deployment,
Open
protocols
Standards
OVF/DMTF,
CDMI/SNIA
OCCI,
Deltacloud
5
Network
Image
&
data
work
‐
loads
Allocation,
admission
Open
APIs
jClouds,
OpenStack
libcloud,
Open
5
PaaS
– the
worst
case!
each PaaS provider offers a special flavor in its design
each
PaaS provider
offers
a
special
flavor
in
its
design
not
all
the
features
that
are
expected
rarely debug facilities
rarely
debug
facilities,
no
Security
‐
as
‐
a
‐
Service
often
not
for
private
p
clouds
portability
is
possible
only
between
a
small
no.PaaSs
in
case
of
open
‐
source
clones
of
the
proprietary
ones
the
problem
escalates
with
the
increase
of
no.PaaSs
increased
no.
in
last
two
years
6
6
Deployment
of
Cloud
techs
at
PaaS
level:
two
types
Platform Service |
Platform Software |
Platform
Service
|
Hosting
|
Integrated solution
Platform
Software
|
Software
service
|
Deploy
‐
based solution
Integrated
solution
Well
knows
examples:
Google’s
AppEngine,
Microsoft’s
Azure,
R kS
’ Cl
dSi
A
’ B
lk
Deploy based
solution
Deployment
of
middleware
in
data
RackSpace’s CloudSites,
Amazon’s
Beanstalk,
Salesforce’s Force.com,
Joyent’
SmartPlatform
Open
‐
source
only
to
develop
appls
centers
Easy
way
to
deal
with
portability and
to
allow
customization
Appl support
– different
approaches:
Deploy code to specific VMs (Azure Beanstalk)
portability
and
interoperability
(framework
category)
O
h
th
Deploy
code
to
specific
VMs
(Azure,
Beanstalk)
Devolop using
rules,
platform
deal
with
deployment
(AppEngine,
Heroku)
C
t
t d t t b i t
t d b P S t
7
Open
‐
source
have
the
potential
to
impact
the
market
as…
Create
metadata
to
be
interpreted
by
PaaS at
run
‐
time
(Force.com,
OrangeScapes)
7
PVM/Parallel
Open
‐
source
Platform
Software
Product AppScale Cloud
Foundry ConPaaS mOSAIC OpenShift TyphoonAE WaveMaker
Owner Univ. Ca‐
lifornia VMWare ContrailConsortia mOSAICConsortia RedHat TobiasRodäbel VMWare
Site appscale.cs. ucsb.edu www.cloud foundry com www. conpaas. eu www. mosaic‐ cloud eu
open shift.com code. google. com/p/typho onae
www.wave
maker.com
foundry.com eu cloud.eu onae
Repository appscale. googlecode. com/svn/ github. com/ cloud foundry www. conpaas. eu/ download/ bitbucket. org/ mosaic github. com/ openshift code. google. com/p/ typho‐onae/ downloads/ dev.wavemak er. com/wiki/ bin/
State 1.5/Jul 2011 0.x , Beta 0.1/Sep 2011 0.5/Jun’12,
Beta Production 0.2/Dec2010/beta/ 6.4.4/Dec2011
Languages Python, Java,
Go Java,Ruby,Node.js, Groovy PHP Java, Python, Erlang, Node.js Java, Python,
Perl, PHP, Ruby Python Java
Data
Support HBase,Hypertable, Redis MySQL Cl t MongoDB, SQLFire, PotsgreSQL, R di Scalaris, MySQL, XtreemFS Riak, CouchDB, MemcachDB R di MySQL, MongoDB, Amazon RDS MongoDB, MySQL, Berkeley DB JE Amazon S3, Rackspace Cluster, Cassandra, Voldermort, MongoDB, Memcache‐ DB Redis Redis, MySQL, Amazon S3, HDFS JE
OS Ubuntu VMWare XtreemOS Linux Red Hat Debian VMWare
8
OS Ubuntu,
CentOS VMWareimage XtreemOSimage Linux RedVirtualization Hat Debian,Ubuntu VMWareimage
Messaging Channel RabbitMQ Own
design RabbitMQ Owndesign RabbitMQ,ejabberd,
Channel
Own design
Clouds tested Amazon EC2,
E l t VMWare Own testbed AmazonFl i l EC2, RightScaleR k Google EC2,R k
8
Eucalyptus Flexiscale, OpenNebula. Eucalyptus … Rackspace, Smart‐Cloud, Amazon Rackspace, OpSource, Eucalyptus
Open
‐
source
Platform
Software
d
l
d
d
hif
Product
CloudFoundry
mOSAIC
OpenShift
Development support 1 2 3
Dedicated to web aps or general Web apps General Web apps
Desktop Cloud Simulator Yes Yes No
API access No Yes No
Support standard programming libs Yes Yes Yes
Impact on web application architecture No Yes No
Impact on web application architecture No Yes No
Complexity of porting web application Medium Low Low
Standard support tools Spring Tools No JBoss, Zend
Thread access Yes No Yes
MySQL Yes Yes Yes
Allows to choose stack components Yes Yes No
Allow to pullp data out Yes Yes Yes
Debugging mode Yes Yes Yes
Deployment support 1 2 3
Lock‐in when building own Cloud Yes (VMWare) No Yes (RHE)
Web server (e.g. Tomcat) Yes Yes Yes
Build‐in‐balancer No Yes Yes
Auto‐scaling app server No Yes Yes
A t li d t b N Y N
Auto‐scaling database No Yes No
Performance analytics Yes No Yes
Support multiple Cloud providers Yes Yes Yes
Agreements SLA No Yes No
Deploy with a special tool Yes No No
Support Private Cloud Yes Yes No
Allows to add third party components Yes Yes Yes
9
Allows to add third party components Yes Yes Yes
Execution support 1 2 3
Command line (CLI) Yes Yes Yes
Web console No Yes Yes
Access to logs via web No Yes Yes
Web based monitoring No Yes Yes
Multitenant Yes Yes Yes
mOSAIC’s
marketing
motto:
“ l i
h
h h
l
d ”
“Flying
through
the
Clouds”
API
spec
Application
Portability!
0101
1001
API
spec
Portability!
0101
1001
API
API
spec
mOSAIC
as
R&D
collaboration
effort
Consortium:
www.mosaic
‐
cloud.eu
1.
Second
University
of
Naples,
Italy
2.
Institute
e
‐
Austria
Timisoara,
Romania
3.
European
Space
Agency,
France
4.
Terradue SRL,
Italy
5.
AITIA
International
Informatics,
Hungary
6.
Tecnalia,
Spain
7.
Xlab,
Slovenia
8.
University
of
Ljubljana,
Slovenia
9.
Brno
University
of
Technology,
Czech
Republic
September 2011: 1
stAPI implement. (Java)
September 2012: 1
ststable PaaS,
2
ndAPI i
l (P th
)
2
ndAPI impl. (Python)
Layered architecture
Open-source and deployable PaaS
12
How
to
use
it?
One
scenario:
Write
component
‐
based
application
Languages:
Java,
Python,
Erlang,
Node.js
C
i ti
th
h
i
Communications
through
message
passing
Respect
the
event
‐
driven
style
of
programming
Debug
g y
your
application
pp
on
the
desktop
p
or
on
‐
premise
p
server(s)
Within
Eclipse
Use
Personal
Testbed Cluster
using
VirtualBox for
the
VMs
D
l
li ti
i
Cl
d
Deploy
your
application
in
a
Cloud
Assisted
by
Cloud
Agency
and
Broker
(with
SLAs)
Monitor
&
modify
y
the
applications
pp
Control
the
life
‐
cycle
of
the
components
(start/stop/replace)
Need
help?
13
Follow
documentation
and
YouTube
demos
(search
“mOSAIC Cloud
computing”)
Application lifecycle
5) Monitoring
Cloudlets + mOS software modules
1) 3) Deployable Apps Application descriptor 2) desc pto 4) Deployment descriptor
How is designed the vendor independent API?
(J) Component
(J) Component
(P) Component
(P) Component
Classical
components
of
applications
(J) Connector API
(P) Connector API
(J) Cloudlet API
(P) Cloudlet API
Operations
with
standard
Component
reacting
to
events
pp
Interoperability API
Proxies
generator
Operations
with
standard
type
of
resources
Driver
API
API
API
API
Driver
API
for
same
type
of
resource
Driver
API
API
15
15
D. Petcu, G. Macariu, S. Panica, C. Craciun, Portable Cloud Applications - from Theory to
Research
issues
related
to
mOSAIC’s
PaaS
Auto
‐
scaler
N.M.
Calcavecchia,
B.A.Caprarescu,
E.
Di
Nitto,
D.
J.
Dubois,
D.
Petcu,
DEPAS
A D
t li d P b bili ti Al
ith
f
A t S li
DEPAS:
A Decentralized Probabilistic Algorithm for Auto‐Scaling
,
Computing,
Springer,
doi:
10.1007/s00607
‐
012
‐
0198
‐
8,
June
2012,
available
at
http://arxiv.org/abs/1202.2509
Scheduler
M.
Frincu,
Scheduling Highly Available Applications on Cloud
Environments
,
,
Future
Generation
Computer
p
Systems,
y
,
May
y
2012,
,
doi:10.1016/j.future.2012.05.017
Naming
service
S P
i
Di t ib t d R
Id tifi ti
S
i
f
Cl
d
S.
Panica,
Distributed Resource Identification Service for Cloud
Environments
,
submitted
16
16
Auto
‐
scaler
Problem:
Most
existing
auto
‐
scaling
solutions
are
centralized
Solution:
Solution:
based
on
a
P2P
architecture
one
autonomic
service
is
deployed
on
each
VM
DEPAS
algorithm:
each VM probabilistically decides to
each
VM
probabilistically
decides
to
add
new
nodes
or
remove
itself.
probability
is
computed
based
on
an estimation of the average
an
estimation
of
the
average
system
load
the
average
system
load
is
approximated by each node with
17
approximated
by
each
node
with
the
average
load
of
itself
and
its
neighbors
Auto
‐
scaler
On
Amazon
EC2
in
COMPUTING
j.
Test
conclusions:
After
a
period
of
adaption,
DEPAS
allocates
a
right
capacity
(between
the
optimum
capacity
at
High capacity nodes areadded
Low capacity nodes are added
max
load
and
optimum
capacity
at
min
load)
The
delay
in
adaptation
is
cased
by
the
relatively
high
duration
of
load
monitoring
timeframe
and
cycle duration
cycle
duration
The
benefit
comes
in
the
high
stability
(no
oscillations)
which
is
impressing
for
a
decentralized algorithm
decentralized
algorithm
18
18
Scheduler
Problem:
component
‐
based
appls can
encounter
failures
of
components
a scaled application can span its components on several nodes
a
scaled
application
can
span
its
components
on
several
nodes
finding
the
optimal
no.component types
needed
on
nodes
so
that
every
type
is
present
on
every
allocated
node
cost restrictions and threshold for no nodes
cost
restrictions
and
threshold
for
no.
nodes
Application
to:
Highly
available
Web
2.0
applications
Novelty:
Schedule
components
instead
VMs
Scheduling
algorithms:
One
that
produces
an
optimal
solution
in
case
when
the
load
of
every
component
is
known
19
One
that
produces
a
sub
‐
optimal
solution
and
relies
on
a
GA
to
allocate
components
in
case
the
component
load
is
unknown
Scheduler
Test
goals:
Ability
to
achieve
high
availability
measured
through
reliability
indicator
Heterogeneity of the load on every node; expect load close to max of
Heterogeneity
of
the
load
on
every
node;
expect
load
close
to
max
of
resource
capacity
20
20
Naming
service
Problem:
Usually,
common
naming
services
are
implemented
in
a
centralized
manner
DNS
service
uses
a
static
configuration
scheme
and
it
is
therefore
not
suitable
to
be
deployed
as
a
PaaS component
Solution:
distributed
naming
and
resource
identification
service
allows
a
client
to
consume
or
communicate
with
a
resource
without
having
to
deal
with
resource
location
or
discovery protocols
discovery
protocols
create
a
distributed
system
on
top
of
the
DNS
service
that
manages
the
naming
ops
p ( g
(register,
, p
update
and
retrieve)
)
in
a
21
distributed
manner
and
by
using
the
What’s
next?
Full
integration
&
testing
&
benchmarking
&promotion
of mOSAIC PaaS
‐
deadline Spring 2013
of
mOSAIC PaaS deadline
Spring
2013
Develop
further
the
open
‐
source
and
deployable
PaaS:
[RO]
Improve
platform
services
‐
automated
management
‐
in
the
//
frame
of
AMICAS
(http://amicas.hpc.uvt.ro),
2012
‐
2014
[EC
‐
FP7]
Develop
HPC
services
in
Cloud
using
parts
of
the
mOSAIC’s PaaS
in
the
frame
of
HOST
(http://host.hpc.uvt.ro),
2012
‐
2014
Develop
top
‐
level
services
based
on
the
PaaS:
[EC
‐
FP7]
MODAClouds
‐
model
‐
driven
engineering
in
multiple
Clouds
(http://www modaclouds eu) 2012 2015
(http://www.modaclouds.eu),
2012
‐
2015
Develop
applications
that
are
using
the
PaaS:
[EC
‐
CIP]
SEED
‐
e
‐
Government
services
on
Clouds,
2012
‐
2014
22
Other
references
D P t H t b ild li bl OSAIC f lti l l d i EWDCC '12 2012 •D. Petcu, How to build a reliable mOSAIC of multiple cloud services, EWDCC '12, 2012
•D. Petcu et al, Towards Component-based Software Engineering of Cloud applications, WICSA 2012 80-81, 2012. •B. A. Caprarescu et al. Decentralized Probabilistic Auto-Scaling for Heterogeneous Systems, ADAPTIVE 2012, 7-12 •D.Petcu, J.L. Vazquez-Poletti (eds), European Research Activities in Cloud Computing, CSP, 2012
•M. Rak et al,Security Issues in Cloud Federation.Achieving Federated&Self-Manageable Cloud Infrastructures,176-194, •F Moscato et al An Ontology for the Cloud in mOSAIC Cloud Computing: Methodology Systems&Applications 467-486F. Moscato et al, An Ontology for the Cloud in mOSAIC. Cloud Computing: Methodology,Systems&Applications,467 486 •D. Petcu et al, Towards Open-Source Cloudware, UCC 2011, 330-331.
•S. Panica et al,Serving Legacy Distributed Appls by a Self-configuring Cloud Processing Platform,IDAACS’11,139-145. •D. Petcu, Portability and Interoperability between Clouds: Challenges and Case Study, LNCS 6994, 62–74, 2011.
•D. Petcu et al, Building an Interoperability API for Sky Computing, InterCloud 2011, 405-412 •D. Petcu et al, Architecturing a Sky Computing Platform,, LNCS 6569, 2011, 1-13
•M. Frincu et al, Self-Healing Distributed Scheduling Platform, CCGrid'11, 225 - 234
•S. Venticinque etal,Agent based Cloud provisioning&management.Design&Prototypal Implementation,CLOSER’11,184-191 •D. Petcu et al, Towards a cross platform Cloud API. Components for Cloud Federation, CLOSER 2011, 166-169
•B. Di Martino et al, Building a Mosaic of Clouds, LNCS 6586, 2011, 529-536
•S. Venticinque et al, A Cloud Agency for SLA Negotiation and Management, LNCS 6586, 2011, 587-594
D P t t l F G id C ti T d Sk C ti C St d f E th Ob ti CGW 2010 11 20
23
•D. Petcu et al, From Grid Computing Towards Sky Computing. Case Study for Earth Observation, CGW 2010, 11-20 •D. Petcu, Identifying Cloud Computing Usage Patterns, Cluster 2010.