Migration Recipes
You should consider the following options when lifting and shifting apps to Cloud Foundry:1. Deploy app as a VM/Job with BOSH + persistent disk
2. Dockerize with patterns and Recipes
3. Lift and Shift JavaEE Full profile apps to TomEE BP, JBOSS BP, Liberty Profile BP, WebLogic BP
4. Lift and Shift JavaEE Web profile apps to Tomcat Java BP.
5. Refactor heavily used portions of app with decomposition patterns.
6. Bootify: Create a self-contained fat jar, including the app server runtime into the app.
7. Covert app to a managed service by creating a app-service broker that provisions and manages the app. Expose the app as a service bindable to other apps.
8. Employ VM Templating technologies like TOSCA, vRealize or vCaC brokers to deploy app VMs.
9. Rewrite app following 12 factor, modern cloud native app architectures
Apps cannot live without data. In addition to the app-code the persistence tier may also need to be refactored to accommodate the migrated app.
Key Features in Cloud Foundry that Enable App Migration
1. Deigo2. CF v3 app-service
3. TCP Routing
4. Persistence Support for Deigo
5. Context Path Routing
6. Routing service
Remediations when moving apps to a PaaS
| Anti-Cloud Pattern | Remedy |
|---|---|
| Multiple Inbound protocols like RMI, JMX, Custom-TCP | TCP Routing, Tunneling |
| Persistence in local VMs like Caches, Transaction logs, CMS | External managed data services, Persistent volume support, sshfs service, EBS & S3 blob store, mount external NFSTransations |
| JTA & 2-pc commit | Use standalone transaction managers like Atomikos and Bitronix. Introduce eventual consistency patterns |
| Spaghetti Configuration | Externalize, plugin config via Config Server , init script in .profile.d directory that injects the config. as environment variables |
| Logging and Monitoring | Punch holes in outbound security groups, CF v3 API, Different process types |
