Migrate Heroku & OpenShift Applications to IBM BlueMix


Published on

This slide deck describes some of the architectural principles behind the Heroku, OpenShift, Cloud Foundry and BlueMix enterprise PaaS. The commonalities and differences in designing and porting apps across these platforms to Cloud Foundy/BlueMix are explored.

Published in: Technology, Education

Migrate Heroku & OpenShift Applications to IBM BlueMix

  1. 1. © 2014 IBM Corporation ‘ 2259: Migrate Heroku & OpenShift Applications to BlueMix/ Cloud Foundry Rohit Kelapure IBM Senior Software Engineer
  2. 2. Platform Introduction
  3. 3. Dzone Survey of open source cloud platforms of over 600 IT Professionals
  4. 4. Vendor comparison
  5. 5. 4 BlueMix/Cloud Foundry Bolierplates Runtimes Web & Application Mobile Data Management Big Data Dev Ops
  6. 6. Screenshots 5
  7. 7. 6 OpenShift Cartridges
  8. 8. 7 OpenShift Application Portal
  9. 9. 8 Heroku App Dashboard
  10. 10. 9 Heroku add-ons
  11. 11. Architecture
  12. 12. 11 Cloud Foundry Architecture
  13. 13. 12 OpenShift Architecture
  14. 14. 13 Heroku Architecture
  15. 15. Commonalities and Differences 14
  16. 16. Heroku  Bluemix/Cloud Foundry Commonalities • Application centric • Extensible runtime and services – Buildpack for application runtime – Add-on framework / service broker for services • Dynamic composition, inject configurations using environment variables Differences • Application structure – Heroku: one app can have multiple types of processes, web/worker/clock etc – Bluemix: one app is just one type of processes , focus on the web app – solution: use composite application to support multiple types of processes in one application • Services – May have different set of services – solution: create new service that is compatible and migrate data if necessary, or reuse the previous Heroku services • Environment variables – Heroku: has service specific names – Bluemix: all in VCAP_SERVICES – solution: auto-reconfiguration
  17. 17. 16 OpenShift  BlueMix/Cloud Foundry Code Structure – One component per repo vs all-in-one Architecture – Two major components vs Split into various components Extensions – Cartridges vs Service Brokers and Buildpacks Contribution – Open for large contribution vs reserved process Deploying PaaS – Puppet vs Bosh Load Balancing– Every node has public IP vs router acting as a dynamic proxy Application Idling – Idling applications vs no such capability Buildpacks vs Cartridges Deploying App – • push from source vs push built artifacts • More Control and predictability vs Flexibility and performance
  18. 18. 17 OpenShift – BlueMix/CF Comparison continued App Deployment Process Browsing Application files ssh vs cf files Services – • One service instance per cartridge vs one service for multiple apps • Connection information passed via environment variables Tunneling – SSH Tunnels vs no mechanism exists Evolution vs Revolution
  19. 19. 18 Services, Addons and Cartridges
  20. 20. Porting Applications 19
  21. 21. 20 12 Factor App Codebase - One codebase tracked in revision control, many deploys Dependencies - Explicitly declare and isolate dependencies Config - Store config in the environment Backing Services - Treat backing services as attached resources Build, release, run - Strictly separate build and run stages Processes - Execute the app as one or more stateless processes Port Binding - Export services via port binding Concurrency - Scale out via the process model Disposability - Maximize robustness with fast startup and graceful shutdown Dev/prod parity - Keep development, staging, and production as similar as possible Logs - Treat logs as event streams Admin processes - Run admin/management tasks as one-off processes
  22. 22. 21 Considerations when porting applications to a PaaS Ephemeral Filesystem - Do not rely on any file being used after current request is completed after the current request has been completed Session Management & Caching - Any stateful data must live in a data store (SQL & NoSQL) external to each dyno. Databases and distributed data stores Static Assets – Should be stored outside the app in Amazon S3 or Akamai Configuration variables – Use environment variables for credential and connection storage for third party services Managing dependencies – Dependencies should be provisioned by the dependency manager driven by the PaaS. Dependencies should be outside the app Logging – Log streams sent out to a sink server, or a third-party log manager for robust storage and analytics Relying on external programs - An app should not rely on programs external to itself lying on external programs Scaling up vs Scaling out - Prefer scaling out with tight control on app and dependency size Binding to ports - Apps requiring more than one incoming port will need to be re-architected, as PasS provides only a single port to bind to per each running process Long running processes - Architect your apps to use background processes for any third-party backing service used with cron, or scheduler support provided by the PaaS Shutting down gracefully - write logic into your app to register a shutdown hook for SIGTERM and gracefully deal with the impending shutdown Moving your domain – Be mindful of SSL being terminated at the load balancer tier. Check for X- Forwarded-Proto HTTP header indicating the protocol used to send the request from the user’s browser
  23. 23. Application Migration across PaaS Prototype tools to migrate applications across platforms • Capture application from PaaS platforms starting from Cloud Foundry and Heroku • Migrate applications from Heroku to BlueMix • Enable portability of application from Cloud Foundry/Heroku etc to IBM SCO/Pure Contribution to open standards like TOSCA
  24. 24. System Diagram of Cloud Application Migration BlueMix Heroku Application Template engine CF/BlueMix Deployer Applicatio n Model TOSCA template repository TOSCA Pattern composer SCO/Pure TOSCA Pattern Deployer TOSCA Archive 1. capture 2. compose 3. deploy
  25. 25. Canonical Application model captured from Heroku
  26. 26. Thank You