IBM Cloud Foundry Migration Runtime Overview

IBM Cloud Foundry Migration Runtime provides a KubeCF-based platform on Red Hat OpenShift as a pragmatic Kubernetes approach to workload migration.

As cloud technologies advanced, many organizations adopted Cloud Foundry, made significant investments in the platform, and rewrote applications to take advantage of it. Over time, containers and Kubernetes have created significant disruption in application development strategies, with organizations now facing new considerations as they modernize their existing and future investments to leverage the strategic value that Kubernetes offers.

IBM Cloud Foundry Migration Runtime, coupled with a Red Hat OpenShift platform, delivers a new intuitive toolset that can accelerate movement towards running one platform while protecting migration timelines and goals from technical and operational risks.

What is it based on?

IBM Cloud Foundry Migration Runtime builds on several of open-source projects including Cloud Foundry itself.

The first is cf-operator is a Kubernetes Operator from the Quarks project External link icon that takes a Cloud Foundry BOSH release and converts it into Kubernetes resources.

The next is KubeCF External link icon, a distribution that deploys Cloud Foundry using the cf-operator.

IBM Cloud Foundry Migration Runtime builds on KubeCF to deploy an opinionated install that works effectively with OpenShift. This makes use of Project Eirini to use the OpenShift Kubernetes scheduler directly for running user applications rather than the traditional Cloud Foundry Diego/Garden scheduler.

IBM Cloud Foundry Migration Runtime Architecture Overview

Main architecural diagram showing how users, developers, and administrators interact with IBM Cloud Foundry Migration Runtime components on an OpenShift cluster

Developers interact with IBM Cloud Foundry Migration Runtime through a standard cf CLI used with all Cloud Foundry distributions. This provides the cf command.

The platform also provides a Stratos External link icon-based Web Interface.

Administrators interact using the same tools as developers but in addition are also likely to interact through the OpenShift console an oc CLI tool.

The platform also provides OpenShift routes to manage traffic into the both Cloud Foundry components and the Stratos-based UI.

IBM Cloud Foundry Migration Runtime Containerised Components

There are two type of components in IBM Cloud Foundry Migration Runtime.

The first are long-running components that provide Cloud Foundry APIs, authentication and services. The second are transient components that start in order to build and deploy user application and then terminate.

In addition to the Cloud Foundry Platform components IBM Cloud Foundry Migration Runtime provides a a separate ingress and UI.

These containerised components can be grouped by function as follows:

Groupings of IBM Cloud Foundry Migration Runtime UI, Ingress, and Platform components by function

Component Summary

Component Description
adapter Manages connections to the syslog drains of user applications as part of the logging system.
cloud controller (api) The IBM Cloud Foundry Migration Runtime Cloud Controller, which implements the CF API.
bits Serves OCI images for droplets of user applications.
cc-worker Worker to process background tasks for the Cloud Controller.
credhub Credential management and secure storage component.
database A PXC database to store persistent data for components such as the cloud controller and UAA.
diego-api API for the Diego scheduler.
doppler Routes log messages from applications and components.
eirini An alternative to the Diego scheduler that allows scheduling on the OpenShift Kubernetes scheduler directly.
log-api Exposes log streams to users using web sockets and proxies user application log messages to syslog drains. Exposed using the router.
nats A pub-sub messaging queue for the routing system.
router Routes application and API traffic.
routing-api API for the routing system.
scheduler Service used to create, schedule and interact with jobs that execute on Cloud Foundry.
singleton-blobstore A WebDAV blobstore for storing application bits, buildpacks, and stacks.
uaa User account and authentication.


This is a diagram of how IBM Cloud Foundry Migration Runtime interact. Each component is exposed as Kubernetes service.

All user traffic is through an OpenShift routes. This directs traffic to only the router component and the cfmr UI component via an TLS-secured HTTPS connection. A user cannot access any other component directly.

Within the OpenShift project components communicate between using secure and insecure connections.

Flow diagram showing the protocols that IBM Cloud Foundry Migration Runtime uses to communicate between components

User Interaction

There are three types of user to illustrate:

Platform Administrator Login

Flow diagram showing the steps of a platform administrator login

Platform Developer - Push an application

A platform developer will deploy an application using the CF CLI with the cf push command.

Flow diagram showing the steps taken when a platform developer deploys an application

  1. Platform developer issues the cf push command in the CF CLI.
  2. The CF CLI connects to the Cloud Controller API and creates a record for the app.
  3. The Cloud Controller store app metadata in the database.
  4. The CF CLI requests any existing resources from the Cloud Controller and as uploads any source files that are not already in cached. The Cloud Controller then combines the newly uploaded files with the files in the cache to create an app package.
  5. The Cloud Controller stores the app package in the blobstore.
  6. The CF CLI issues a request to start the app.
  7. The Cloud Controller issues a staging request to Eirini. Eirini stages the app and downloads buildpacks and uses the buildpack to compile and stage the app.
  8. Eirini steams the output of the staging process. This is what the developer would use to troubleshoot any staging issues.
  9. Eirini creates a container with the compiled and staged app. This is stored in the blobstore. The buildpack cache is also uploaded to the blob store for the next time the app is staged.
  10. Eirini then informs the Cloud Controller that staging is complete.
  11. The Cloud Controller then schedules the app in the cfmr-eirini namespace in OpenShift. This is achieved by running jobs in the namespace to create the relevant StatefulSet.
  12. When the pods for the StatefulSet are the Cloud Controller is informed.

Swimlane flowchart showing the steps each component takes when a developer deploys an application using the IBM Cloud Foundry Migration Runtime CLI

Application User Access

Flowchart showing the protocols used by the IBM Cloud Foundry Migration Runtime components for each communication step in the application deployment process