Docker meetup - PaaS interoperability

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

Agenda

CONTEXT AND PROJECT 1

CLOUD COMPUTING AND PAAS 2

STANDARDIZATION 4

INTEROPERABILITY, PORTABILITY 3

TECHNOLOGIES 5

CAMP2DOCKER 6

3

5 months

R&D internship

lob.ops@octo

Context 1

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

Cloud computing 1 2

OpEx is

the New

CapEx* Operation expenditure ** Capital expenditure

*

**

6

Definition 1 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

Models

CHARACTERISTICS

Public

Private

Hybrid

DEPLOYMENT

1 2

On-demand self-service Broad network access

Resource pooling

Rapid elasticity

Measured service

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

Agility and time-to-market Operational simplicity

Expertise Trade-offs between CapEx et OpEx

PaaS Benefits 1 2

10

PaaS Providers

PUBLIC BOTH/HYBRIDE PRIVATE

1 2

11

Market study

Magic Quadrant for Enterprise Application Platform as a Service

Magic Quadrant for On-Premises Application Platforms

1 2

12

PaaS Model 1 2

13

PaaS Model: Deis example 1 2

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

Provisionning 1 2

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 onto 1 2

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 onto 1 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://[email protected]:2222/lambda-hawthorn.git

* [new branch] master -> master

17

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

Running onto 1 2

18

$ deis scale web=4 Scaling containers... but first, coffee!

done in 12s

Scaling out with 1 2

19

Pricing: Heroku

Computing Units

Database

Support

1 2

20

Pricing: Heroku

Add-ons

1 2

21

Pricing: Openshift Online 1 2

22

Pricing: AWS Elastic Beanstalk 1 2

23

Pricing: Google App Engine

Computing Units

Database

Search

1 2

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 interoperability 1 2 3

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

Challenges 1 2 3

27

Benefits 1 2 3

28

Scenarios 1 2 3

29

Federation 1 2 3

30

Standards 1 2 3 4

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

Approaches 1 2 3 4

32

Cloud Standards 1 2 3 4

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

TOSCA: Members 1 2 3 4

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

TOSCA: Service template 1 2 3 4

37

Topology example 1 2 3 4

38

Topology example 1 2 3 4

39

Topology example 1 2 3 4

40

Orchestration plan 1 2 3 4

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

Orchestration 1 2 3 4

42

Cloud Service Archive (CSAR) 1 2 3 4

43

Architecture of a TOSCA environnent 1 2 3 4

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

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

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

CAMP Ressources 1 2 3 4

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 example 1 2 3 4

49

Deployment 1 2 3 4

50

Technologies 1 2 3 4 5

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

1 2 3 4 5

53

1 2 3 4 5

54

1 2 3 4 5

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

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

camp2docker 1 2 3 4 5 6

camp.yaml

58

59

BACKUP

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

Non-Recurring Costs   Acquisition   Implementation

Ongoing Costs   Application Deployment and Testing   Vendor Support   Administration & Management   Monitoring, Diagnostics & Tuning

Cost model

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