Upload
rohit-kelapure
View
4.189
Download
2
Embed Size (px)
DESCRIPTION
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.
Citation preview
© 2014 IBM Corporation
‘
2259: Migrate Heroku & OpenShift
Applications to BlueMix/ Cloud
FoundryRohit Kelapure
IBM Senior Software Engineer
Platform Introduction
Dzone Survey of open source cloud platforms of over 600 IT
Professionals
Vendor comparison
4
BlueMix/Cloud Foundry
Bolierplates RuntimesWeb &
Application
MobileData
ManagementBig Data
Dev Ops
Screenshots
5
6
OpenShift Cartridges
7
OpenShift Application Portal
8
Heroku App Dashboard
9
Heroku add-ons
Architecture
11
Cloud Foundry Architecture
12
OpenShift Architecture
13
Heroku Architecture
Commonalities and
Differences
14
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
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
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
18
Services, Addons and Cartridges
Porting Applications
19
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
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 PasSprovides 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
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
System Diagram of Cloud Application Migration
BlueMix
Heroku
Application Template engine
CF/BlueMixDeployer
Applicatio
n Model
TOSCA
template
repository
TOSCA Pattern composer
SCO/PureTOSCA Pattern
Deployer
TOSCA
Archive
1. capture 2. compose
3. deploy
Canonical Application model captured from Heroku
Thank You