What is Pivotal Cloud Foundry (PCF)?

Pivotal Cloud Foundry (CF) is a multi-cloud platform utilized for supporting the development, management, and continuous delivery of software applications. Any major IaaS tool like AWS, Openstack etc., can host CF on top of them and provide a set of unique features/functionalities. It allows enterprises to configure the underlying platform in a cost optimum manner and then deploy and run applications as cloud native apps.

How to migrate legacy Cloud Foundry applications to a Red Hat OpenShift cluster.

Key Pointers & Runtime Components

• Provides a PaaS with an abstraction at application level
• Allows developers to focus on code rather than the underlying infrastructure or platform
• Utilizes Open Service Broker API to make use of services from apps
• Manages apps as Diego containers (Internally)
• BOSH is a deployment manager tool used in PCF & Build packs for app deployment
• OAuth2 server (the UAA) and login server work together to provide identity management
• Application logs are available to developers as stream via Loggregator (log aggregator) system
• Availability of metrics collector for metrics and statistics of the components
• HTTP & HTTPS protocols are in use during communication establishment between CF component VMs or data stored in Diego's Bulletin Board System (BBS)
• Incoming traffic routes are either to a cloud controller component or to a hosted application running on a Diego Cell. Router is responsible for route management

What is Red Hat Openshift?

Red Hat Openshift is an enterprise offering, an open-source platform for deploying and managing containers i.e., Kubernetes. It is a Platform as a Service offering which manages storage, network, compute and provides consolidated managed platform for developers to deploy their applications and other helpful tools e.g., security and monitoring.

Key Pointers & Runtime Components

• Provides many benefits of PaaS with the flexibility of IaaS
• Orchestrates computing, networking, and storage  infrastructure on behalf of user workloads
• Enables portability across infrastructure providers
• Runs application as docker container inside abstraction layer known as pod
• Exposes API for all internal work requests and enables third party integration at ease
• Since containers with root privileges can execute, it brings high security to the platform
• It has support for different application image build i.e., source to image, docker build etc.
• Developer can deploy container image using container run time interface API command e.g., docker run and can also use advanced mechanism like Helm charts to code application manifest as deployment manager
• Can be installed in bare metal servers, VMs or use managed cluster provided by major cloud providers

Similarities

• Namespaces, Orgs & Spaces: Cloud Foundry uses Orgs (Organizations) & Spaces to categorize the resources and segregate so that the resources of one group cannot touch the resource of others. A similar concept in Openshift (Kubernetes) is to use projects (namespaces).
• Control and Runtime Planes:  Both share similar concepts when it comes to splitting up (Virtual Machines) VMs to have different roles on each platform. In Red Hat Openshift, some VMs are used to run containers like worker nodes and some VMs run everything else such as API servers, schedulers known as master nodes i.e., control planes. CF also follows something like this where the Concourse server is on the control plane, and remote workers collocated with PCF foundations. Different services are deployed in dedicated VMs.
• Cell & Pods: In Cloud Foundry, each app instance corresponds to a container running on a cell. On scaling the application instances, developers will have more copies of that container running on different cells. In Openshift, there is the concept of a pod. A pod runs one or more containers. It cannot share nodes, which means it cannot be running in multiple nodes at the same time. Pod is nothing but a virtual layer of containers and all openshift master API connect to the pod.
• Handling persistent data: Anything with persistent data – such as a postgres database – needs to be bound separately. Communication between containers is handled using Silk. You can use Pivotal Cloud Foundry command ($ cf ssh ***) into these app instances to look around the file system and observe the running processes. In Openshift for persistent data, you need to bound persistent volume and persistent volume claim (PV/PVC) via storage classes.
• Handling secret data: In BOSH/Cloud Foundry the default secrets generation and store is CredHub. It has a CLI (Command Line Interface) for admins to view & edit secrets that are nothing more than key+value with the keys at a particular path.  In Red Hat Openshift, secrets are part of the primary kubectl cli and are stored in etcd on the master nodes. Secrets are managed by namespace and are mounted in a special folder structure within a pod or as environment variables.

Differences

• Developer Experience: Pivotal Cloud Foundry is completely developer oriented. It provides an excellent experience by removing all overhead associated app build and deployment as it pushes the code into CF with a single command (cf push). On the other hand, Openshift is a configuration-friendly platform where developers have the flexibility to deploy/run app as per their custom needs and it provides a variety of developer’s tools and abstraction at different levels.

• Flexibility: CF is very prescriptive and recommends specific standards, architecture for developing and deploying the application as well as managing the platform itself. Openshift supports a wide range of tools and strategies to deploy, run, and manage the applications.

• Running Cost: CF is very costly as its infrastructure requirement is high and annual subscription model is applied, whereas Openshift requires minimal infra and offers the pay-as-you-use model or terms license model.
• Operational Experience: CF provides abstraction of everything except developer’s app, thus on the operational side, there is not much work left except updates. For Openshift, many custom config is possible and that brings flexibility to the table, as it supports different build / deployment strategies and there is always something for everyone.

Why to Switch?

• Nothing ‘wrong’ with CF:
  • Very easy to get apps running, relatively low learning curve, etc.
  • Used in some way by at least half of the Fortune 500 companies /organizations

The below section presents cases where the idea of migration will be helpful.

• Openshift (Kubernetes) offers several advantages on top of being PaaS:
  • More granular control to better manage large, complex microservice system
  • Improved memory and CPU usage (dynamic allocation)
  • Integrated monitoring stack with Prometheus & Grafana
  • Ability to run own services with custom config (e.g., Redis)
  • Simpler ’front door’ stack with built-in Ingress proxy to avoid extra network hops
  • Easy integration with major CI/CD solutions
  • Existing operator framework which accelerates automations
  • Built-in image and operator repositories
  • Outstanding out-of-the-box dashboard to ease manage & monitor workloads
  • Beneath OS is immutable (coreOs) and no container with privileged access strengthens the overall security
  • Strong RBAC isolation makes it easy for single shareable platform
  • Local network plugin makes communication among microservices secure and untouched from external network, whereas calls between microservices in CF require going out over the public internet
  • No need to rebuild app if you switch and migrate to a different cloud PaaS provider. Your existing images are ready to run in any k8s implementation

Various Stages of Application Migration from PCF to Openshift

Conclusion

CF is a great technology, but Openshift better meets the needs of our microservice  system. Openshift allowed us to achieve greater performance, scalability, reliability, and security than before, and has cost-friendly solutions for scalable microservices application execution. Openshift provides no vendor locking system and images deployed here can be deployed in any k8s implementation solution provided by any major cloud PaaS provider. For any existing business where applications are running in CF, even the migration approach described above is not a tough nut to crack.