Docker meetup - PaaS interoperability
•
4 j'aime•823 vues
This is an overview of how we have to consider interoperability between several PaaS services and how standards like CAMP or TOSCA can help.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à Docker meetup - PaaS interoperability
Similaire à Docker meetup - PaaS interoperability (20)
Plus de Ludovic Piot
Plus de Ludovic Piot (10)
Dernier
Dernier (20)
Docker meetup - PaaS interoperability
- 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
- 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
- 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
- 27. 27 Benefits1 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