Your SlideShare is downloading. ×
Migrate Heroku & OpenShift Applications to IBM BlueMix
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Migrate Heroku & OpenShift Applications to IBM BlueMix

3,989
views

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 …

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

0 Comments
8 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,989
On Slideshare
0
From Embeds
0
Number of Embeds
42
Actions
Shares
0
Downloads
83
Comments
0
Likes
8
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. © 2014 IBM Corporation ‘ 2259: Migrate Heroku & OpenShift Applications to BlueMix/ Cloud Foundry Rohit Kelapure IBM Senior Software Engineer
  • 2. Platform Introduction
  • 3. Dzone Survey of open source cloud platforms of over 600 IT Professionals
  • 4. Vendor comparison
  • 5. 4 BlueMix/Cloud Foundry Bolierplates Runtimes Web & Application Mobile Data Management Big Data Dev Ops
  • 6. Screenshots 5
  • 7. 6 OpenShift Cartridges
  • 8. 7 OpenShift Application Portal
  • 9. 8 Heroku App Dashboard
  • 10. 9 Heroku add-ons
  • 11. Architecture
  • 12. 11 Cloud Foundry Architecture
  • 13. 12 OpenShift Architecture
  • 14. 13 Heroku Architecture
  • 15. Commonalities and Differences 14
  • 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. 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. 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. 18 Services, Addons and Cartridges
  • 20. Porting Applications 19
  • 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. 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. 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. 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. Canonical Application model captured from Heroku
  • 26. Thank You