The document discusses the architecture and implementation of a cloud-based Platform as a Service (PaaS) solution, emphasizing interoperability, portability, and standardization among different cloud providers. It includes a review of cloud computing definitions, benefits of PaaS, and the market landscape, as well as details on the OASIS TOSCA and CAMP initiatives aimed at enhancing cloud application management and interoperability. Furthermore, it covers important concepts such as pricing models, cost metrics, and deployment processes for various cloud services.

1. 1
Tél : +33 (0)1 58 56 10 00
Fax : +33 (0)1 58 56 10 01
www.octo.com© OCTO 2013
50, avenue des Champs-Elysées
75008 Paris - FRANCE
PaaS Interoperability
Thomas Lacroix
&
Ludovic Piot

2. 2
Agenda
CONTEXT AND PROJECT1
CLOUD COMPUTING AND PAAS2
STANDARDIZATION4
INTEROPERABILITY, PORTABILITY3
TECHNOLOGIES5
CAMP2DOCKER6

3. 3
5 months
R&D internship
lob.ops@octo
Context1

4. 4
Architecture and implementation
of an interoperable PaaS solution
Project
‘‘
’’Considering the:
technical dimension: standard and technology study, architecture, implementation
economical dimension: pricing, business model, economic impact of interoperability
and standardization
1

5. 5
Cloud computing1 2
OpEx
is
the
New
CapEx
* Operation expenditure
** Capital expenditure
*
**

6. 6
Definition1 2
Cloud computing is a model for enabling
• ubiquitous
• convenient
• on-demand
network access to a shared pool of
configurable computing resources
• networks
• servers
• storage
• applications
• services
that can be rapidly
• provisioned
• released
with minimal
• management effort
• service provider interaction

7. 7
Models
CHARACTERISTICS
Public
Private
Hybrid
DEPLOYMENT
1 2
On-demand self-service
Broad network access
Resource pooling
Rapid elasticity
Measured service

8. 8
PaaS
The capability provided to the consumer is to deploy onto the cloud
infrastructure consumer-created or acquired applications created using
programming languages and tools supported by the provider.
The consumer does not manage or control the underlying cloud
infrastructure including network, servers, operating systems, or storage,
but has control over the deployed applications and possibly
application hosting environment configurations
‘‘
’’
1 2

9. 9
Agility and time-to-market Operational simplicity
Expertise Trade-offs between CapEx et OpEx
PaaS Benefits1 2

10. 10
PaaS Providers
PUBLIC BOTH/HYBRIDE PRIVATE
1 2

11. 11
Market study
Magic Quadrant for Enterprise Application
Platform as a Service
Magic Quadrant for On-Premises
Application Platforms
1 2

12. 12
PaaS Model1 2

13. 13
PaaS Model: Deis example1 2

14. 14
$ curl -sSL http://deis.io/deisctl/install.sh | sudo sh
$ git clone https://github.com/deis/deis.git
$ export DEIS_NUM_INSTANCES=3
$ cd deis
$ make discovery-url
$ vagrant up
$ ssh-add ~/.vagrant.d/insecure_private_key
$ export DEISCTL_TUNNEL=172.17.8.100
$ deisctl install platform
$ deisctl start platform
$ pip install ./client/
$ deis register http://deis.local3.deisapp.com
$ deis keys:add
Provisionning1 2

15. 15
$ deis clusters:create dev local3.deisapp.com # create a cluster
--hosts=172.17.8.100,172.17.8.101,172.17.8.102
--auth=~/.vagrant.d/insecure_private_key
$ git clone https://github.com/deis/example-ruby-sinatra.git
$ cd example-ruby-sinatra
$ deis create
Creating application... done, created lambda-hawthorn
Git remote deis added
Deploying onto1 2

16. 16
$ git push deis master
Counting objects: 92, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (87/87), done.
Writing objects: 100% (92/92), 19.29 KiB | 0
bytes/s, done.
Total 92 (delta 40), reused 0 (delta 0)
-----> Ruby app detected
-----> Compiling Ruby/Rack
-----> Using Ruby version: ruby-1.9.3
-----> Installing dependencies using 1.5.2
Running: bundle install --without
development:test
...
-----> Discovering process types
Procfile declares types -> web
Default process types for Ruby ->
rake, console, web
-----> Compiled slug size is 12M
-----> Building Docker image
Uploading context 11.81 MB
…
Deploying onto1 2
Step 3 : ENTRYPOINT ["/runner/init"]
---> Running in 94eb867135db
---> f49031ecd6c1
Successfully built f49031ecd6c1
-----> Pushing image to private registry
Launching... done, v2
-----> lambda-hawthorn deployed to Deis
http://lambda-
hawthorn.local3.deisapp.com
To learn more, use `deis help` or
visit http://deis.io
To ssh://git@local3.deisapp.com:2222/lambda-
hawthorn.git
* [new branch] master -> master

17. 17
$ curl -s http://lambda-hawthorn.local3.deisapp.com
Powered by Deis!
Running onto1 2

18. 18
$ deis scale web=4
Scaling containers... but first, coffee!
done in 12s
Scaling out with1 2

19. 19
Pricing: Heroku
Computing Units
Database
Support
1 2

20. 20
Pricing: Heroku
Add-ons
1 2

21. 21
Pricing: Openshift Online1 2

22. 22
Pricing: AWS Elastic Beanstalk1 2

23. 23
Pricing: Google App Engine
Computing Units
Database
Search
1 2

24. 24
Use Case Cloud Computing Discussion Group:
« the ability to write code that works with more than one Cloud provider
simultaneously, regardless of the differences between the providers »
Cohen:
« Cloud computing interoperability is the ability for multiple Cloud
providers to work together* or interoperate, whereas Cloud portability is
the ability of data and application components to be easily moved and
reused regardless of the provider, operating system, storage, format or
API »
Goyal:
* including « process execution, security, migration/cloning control,
standards, transparency, and manageability and regulatory
compliance »
Definitions of Cloud computing interoperability1 2 3

25. 25
Distributed Computing Reference Model
http://www.opengroup.org/cloud/cloud/cloud_iop/dcrm.htm
Categories of portability and interoperability
Data Portability
Application Portability
Platform Portability
Application Interoperability
Platform Interoperability
Management Interoperability
Publication and Acquisition
Interoperability
1 2 3

26. 26
Challenges1 2 3

27. 27
Benefits1 2 3

28. 28
Scenarios1 2 3

29. 29
Federation1 2 3

30. 30
Standards1 2 3 4

31. 31
The standardization initiatives seem to rotate around three key
enablers for tackling Cloud computing interoperability.
a standardized API/interface and a common management model
a common data model/semantic
the utilization of a marketplace/broker
Approaches1 2 3 4

32. 32
Cloud Standards1 2 3 4

33. 33
Official description:
The OASIS TOSCA TC works to enhance the portability of cloud
applications and services.
TOSCA will enable the interoperable description of application and
infrastructure cloud services, the relationships between parts of the
service, and the operational behavior of these services (e.g., deploy,
patch, shutdown)--independent of the supplier creating the service, and
any particular cloud provider or hosting technology.
Formed in January 2012
OASIS Topology and Orchestration Specification for Cloud
Applications (TOSCA)
1 2 3 4

34. 34
TOSCA: Members1 2 3 4

35. 35
Standardizes the language to describe
The infrastructure of an IT Service (the topology)
How to orchestrate operational behaviour (plans such as build, deploy,
patch, shutdown, etc.)
Declarative model that spans applications, virtual and physical
infrastructure
TOSCA: What is it ?1 2 3 4

36. 36
TOSCA: Service template1 2 3 4

37. 37
Topology example1 2 3 4

38. 38
Topology example1 2 3 4

39. 39
Topology example1 2 3 4

40. 40
Orchestration plan1 2 3 4

41. 41
Declarative -> What ?
« I want this, realize it ! »
Runtime interprets topology and does deployment
Imperative -> How ?
« First do this, then do that »
Management plan explicitly describes each step
Orchestration1 2 3 4

42. 42
Cloud Service Archive (CSAR)1 2 3 4

43. 43
Architecture of a TOSCA environnent1 2 3 4

44. 44
Official description:
The OASIS CAMP TC advances an interoperable protocol that cloud
implementers can use to package and deploy their applications.
CAMP defines interfaces for self-service provisioning, monitoring,
and control. Based on REST, CAMP is expected to foster an
ecosystem of common tools, plugins, libraries and frameworks, which
will allow vendors to offer greater value-add
Formed in August 2012
17 members:
OASIS Cloud Application Management for Platforms
(CAMP)
1 2 3 4

45. 45
Resource Model and Interface
RESTfull API
JSON serialization
Models applications, components, services and their relationships
Extensible
Application description and packaging
ZIP, TAR or TGZ
YAML metadata
Extensible
Language, framework and platform agnostic
CAMP: What is it ?1 2 3 4

46. 46
Interoperably manage applications and their use of the platform
Deploy
Manage lifecycle (configure/customize, start, stop, snapshot, suspend,
restart, delete)
Monitoring
Portably migrate applications between platforms
Construct a package and deploy it
Export a package from one platform and deploy it to another
nCAMP: existing demo CAMP implementation
http://ec2-107-20-16-71.compute-1.amazonaws.com/campSrv/
CAMP: What can it do ?1 2 3 4

47. 47
CAMP Ressources1 2 3 4

48. 48
name: VitaMinder
description: Vitamin and Supplement Tracking
camp_version: CAMP 1.1
origin: http://www.oracle.com/nCAMP/Hand
artifacts:
-
name: VitaMinder WAR
artifact_type: com.oracle.nCAMP:WAR
content: { href: VitaMinder.war }
requirements:
-
requirement_type: com.oracle.nCAMP:ConnectTo
com.oracle.nCAMP.dbName: VitaMinder
fulfillment:
id: db
characteristics:
-
characteristic_type: com.oracle.nCAMP:SQL
-
requirement_type: com.oracle.nCAMP:HostOn
fulfillment:
characteristics:
-
characteristic_type: com.oracle.nCamp:ServletContainer
-
name: Supplement SQL
artifact_type: com.oracle.nCAMP:SQL_script
content: { href: vitaminder.sql }
requirements:
-
requirement_type: com.oracle.nCAMP:LoadInto
fulfillment: id:db
CAMP: Planfile example1 2 3 4

49. 49
Deployment1 2 3 4

50. 50
Technologies1 2 3 4 5

51. 51
I. Codebase: One codebase tracked in revision control, many deploys
II. Dependencies: Explicitly declare and isolate dependencies
III. Config: Store config in the environment
IV. Backing Services: Treat backing services as attached resources
V. Build, release, run: Strictly separate build and run stages
VI. Processes: Execute the app as one or more stateless processes
VII. Port binding: Export services via port binding
VIII. Concurrency: Scale out via the process model
IX. Disposability: Maximize robustness with fast startup and graceful
shutdown
X. Dev/prod parity: Keep development, staging, and production as similar as
possible
XI. Logs: Treat logs as event streams
XII. Admin processes: Run admin/management tasks as one-off processes
1 2 3 4 5

52. 52
1 2 3 4 5

53. 53
1 2 3 4 5

54. 54
1 2 3 4 5

55. 55
Docker containers orchestration
Using a configuration file
Used with Orchard (CaaS solution)
Bought by Docker in July 2014.
1 2 3 4 5

56. 56
libswarm is a toolkit for composing network services.
It defines a standard interface for services in a distributed system to
communicate with each other. This lets you:
Compose complex architectures from reusable building blocks
Avoid vendor lock-in by swapping any service out with another
1 2 3 4 5

57. 57
camp2docker1 2 3 4 5 6
camp.yaml

58. 58

59. 59
BACKUP

60. 60
Total Cost of Ownership (TCO)
Coûts liés à l’achat, propriété, utilisation et maintenance d’un produit
Availability
Temps de disponibilité d’un service sur une période donnée
Time to Market
Temps pour implémenter une nouvelle application, ou pour pousser un
nouveau service sur le marché
Opportunity Costs
Manque à gagner potentiel entre deux investissements
Churn Rate
Nombre de clients perdus dans une période donnée
Productivity
Mesure de l’efficacité d’un département ou d’une entreprise
Peut être calculer grossièrement comme le revenue par tête
Service Level Agreement (SLA)
Contrat dans lequel on formalise la qualité du service en question
Métriques indirectes

61. 61
Non-Recurring Costs
Acquisition
Implementation
Ongoing Costs
Application Deployment and Testing
Vendor Support
Administration & Management
Monitoring, Diagnostics & Tuning
Cost model

62. 62
Payback method
Temps requis pour recouvrer l’investissement dans un produit ou
service
Net Present Value (NPV)
Flux de trésorerie actualisé représentant l'enrichissement
supplémentaire d'un investissement par rapport au minimum exigé par
les apporteurs de capitaux
Return on investment (ROI)
Ratio financier qui mesure le montant d'argent gagné ou perdu par
rapport à la somme initialement investie dans un investissement
Métriques directes