WebSphere Application Server & Liberty

IBM Cloud Foundry Migration Runtime: Getting Started

By Daniel Xu posted Tue March 23, 2021 03:25 PM

  
Overview

I
BM has been involved with the Cloud Foundry community since the early days.  And we run the world's largest cloud foundry environment via our Public Cloud, so our knowledge can be of benefit as we help clients look forward to the use of new tools and technologies in the kubernetes space


IBM's advocacy remains firmly with OpenShift development methodologies being the superior approach for our clients. Our clients existing technology investments are a rich tapestry reflecting their historic decisions shaped by many talented people, inspired by the promises, sometimes fulfilled, of vendor and opensource innovations and prioritized by an ever-evolving business landscape.  Through it all, one client "North Star" steadfastly remains - the need to continuously deliver business value to differentiate and compete in a client's respective marketplace. 


This brings us to the exciting announcement that IBM Cloud Foundry Migration Runtime (CFMR) was available to the public on Jan 14, 2021 as a component of WebSphere Hybrid Edition (WSHE), and the standalone version of CFMR was debuted in December 2020. The rationale behind developing this new tool was that we strongly believe that there are an increasing platform fatigue in the IT world across companies as we observed, and people want a centralized platform where they can develop and manage not only Cloud Foundry apps, but all the other applications as well. Therefore, Red Hat OpenShift Container Platform (OCP) is an ideal choice for that, and migrating your existing Cloud Foundry apps to OCP would make you one step closer to a centralized platform, while leveraging all the runtime, buildpacks and ecosystem support provided by OCP, and at this moment, CFMR can only be run on OCP. 


WebSphere Hybrid Edition provides many tools for app modernization, such as Transformation Advisor(TA), Mono2Micro, and WebSphere Migration Toolset that may complement with CFMR to accelerate your app modernization progress and make managing them easier in one place. App Modernization is about helping clients with their existing investments. Mono2Micro, TA and CFMR all work against that space. There are mixed technology solutions where you can have microservices hosted on WAS + Cloud Foundry + Kubernetes all working together to provide business value. CFMR is a natural fit within that App Modernization narrative given the amount of investment that occurred with Cloud Foundry over the past 4-5 years.That is how CFMR adds value to the Hybrid Edition.


What is CFMR?

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


As cloud technologies advanced, many organizations adopted Cloud Foundry in the past decade, made significant investments in the platform, and rewrote applications to take advantage of it. Over time, containers and Kubernetes, more specifically, 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 existing estate movement towards a more unified hybrid cloud platform posture while minimizing development culture disruption and protecting migration timelines and goals from technical and operational risks.


Value Propositions

We provide three main value propositions for CFMR. 


Firstly, it is cost saving through licensing: it reduce costs by up to 50% vs Application Instance based licensing. And it is compute-based entitlement metric to ensure that clients only pay for the resource consumption (value) of their deployed workload. 


Secondly, it achieved operational consolidation: Lift & Shift existing Cloud Foundry applications to containers on OpenShift.  For solutions with mixed heritage (Cloud Foundry and Kubernetes Native) development, a unified operational posture improves operational efficiency and allows your ops team to use because there are common operational runbooks, multi-cloud management Tool, common monitoring and logging. and common security policies


Thirdly, it minimizes migration risks. Development culture is slow to evolve and change. Modifications to code and pipeline automation can introduce a spectrum of risk that needs organizational assessment. All of this increases the difficulty with migrations.  CFMR accelerates your Kubernetes cloud strategy by minimizing these disruptions while unifying your operations on the hybrid cloud platform of open possibility, Red Hat OpenShift. To complement CFMR, we provide a structured approach to assess your cloud foundry migration risk while accelerating your journey to OpenShift.  We have a well-defined process to help you in four phases: phase 1 "Discover" what your existing Cloud Foundry estate contains and identify where cost savings and return on investment is greatest. Phase 2 "Triage" existing workload present within your Cloud Foundry environment against approaches spanning "lift-and-shift", "rewrite", "retire" and "modernize" to ensure the right mix is defined for your financial, technical, cultural and strategic goals. Phase 3 "Assess" through a well-defined PoC how quickly you can lift-and-shift your Cloud Foundry estate to OpenShift and phase 4 "Scale" your migration with the assistance of a wide range of IBM and IBM Partner services.


Based on numerous customer feedback, these 3 are the most important aspects they care about, and we received positive comments regarding these features from prospect customers. 


For those who want to get more technical and in-depth understanding of the CFMR underlying components, please read on. The product leverages the Eirini project and uses a fresh approach to make the developers almost unaware of the migration process, and the operators happier when managing the compute resources.



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 that takes a Cloud Foundry BOSH release and converts it into Kubernetes resources. The next is KubeCF, a distribution that deploys Cloud Foundry using the cf-operator.


IBM Cloud Foundry Migration Runtime builds on KubeCF to deploy an opinionated install re-based on Universal Base Images (UBI) 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.
Developers interact with IBM Cloud Foundry Migration Runtime through the community standard CF CLI used with all Cloud Foundry distributions. This provides the cf command. The platform also provides a Stratos based Web Interface for those who prefer a point-and-click experience.


Administrators interact using the same tools as developers but in addition are also likely to interact through the OpenShift console via the oc CLI tool. The platform also provides an nginx ingress to manage traffic into the both Cloud Foundry components and the Stratos-based UI.


IBM Cloud Foundry Migration Runtime Containerized 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 containerized components can be grouped by function as follows:
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.
tcp-router
Routes TCP traffic to user applications.
uaa
User account and authentication.


Other links: 


#DevOps
#WebSphereApplicationServer
#CFMR
#WebsShereHybridEdition
#whatsnew
#WebSphereHybridEdition
0 comments
68 views

Permalink