By Thomas De Vos, Senior Solution Architect - Cloud Native Labs, HCL Technologies

The Cloud Foundry Foundation was established in 2015 and holds all the Cloud Foundry IP. Cloud Foundry is written in Go, Ruby, and partially in Java and was developed initially by VMware and released in 2011. The open-source code of Cloud Foundry is distributed under the Apache 2.0 license. Corporates can choose to deploy Cloud Foundry on GCP, Azure, AWS, OpenStack, and vSphere and it offers support for Bare Metal. In addition, Cloud Foundry comes as a fully managed service by several certified providers such as IBM, Pivotal, and SAP. 

The big promise comes from "cf push", which inspects your app., wraps it up using a buildpack, no matter the language, and pushes your application to Pivotal Cloud Foundry or any other Cloud Foundry runtime. Within minutes your application is live. But only a few know what happens in the background. 

Cloud Foundry benefits significantly from being open source, supports multiple languages and application portability, has role-based access, and scales applications horizontally and vertically. What is there not to like about Cloud Foundry? 

By default, the OSS version of Cloud Foundry is not easy to install, does not come with support for stateful containers, does not have adequate facilities for logging and lacks focus on operational processes. Even if you wish to configure monitoring processes, you will notice that working with BOSH is rather challenging. Cloud Foundry locks corporates into their eco-systems in long commercial contracts, offering limited modernisation capabilities from a business perspective.  

In the last few years, Kubernetes has been one of the greatest innovations in the cloud-native world, defined as a set of building blocks that collectively provide mechanisms to: manage, scale, deploy, and maintain applications based on system resource consumptions or custom metrics. Kubernetes exposes an API for engineers to extend the functionality, unlike Cloud Foundry. The platform allows control over storage and networking resources by defining fully managed "Objects". Applications are deployed using containers running on top of the Docker runtime sharing the host system. 

Corporates are very keen on adopting a Kubernetes landscape for all their applications. They would like to use cost-efficient solutions offered by major cloud service providers built on top of Kubernetes, but manually migrating to these from Cloud Foundry is expensive and risky. The Kubernetes Migration Platform can help reduce the cost of migrations and ensure container workloads are always running on the most cost-effective platforms. 

Migrating workloads and data from Cloud Foundry - manually comes with several considerations. Are the correctly skilled application owners available? How will you deal with in-flight production data when migrating? How will you avoid production outages? How can you ensure that you maintain the same or stricter security models? How can you guarantee that you won't have any performance issues after migrating due to the misconfiguration of your target cluster? 

Hence, we need to tap into an arsenal of approaches and tools to guarantee successful migration for every Cloud Foundry application we want to migrate. Before we look into automation further, let's explore what is involved in migrating Cloud Foundry applications to Kubernetes. 

First of all, we need to discover the applications deployed into a Cloud Foundry space; this is something we can do using the "cf" command. Next, we need to get access to the source code of the running application. You can use "cf curl /v2/apps" and download the artefacts. Cloud Foundry does not use containers natively. However, you can also deploy and manage apps. running in Docker containers. In Kubernetes, we must deploy using containers; therefore, we need to create a container next from the downloaded source from Cloud Foundry. You will have different options: create a Dockerfile once you have established the type of the application, or you can use Paketo buildpacks to create a container image. 

Unless you want complete control, it is recommended to use buildpacks which does the hard work for you. Upload the container image to your preferred container registry, and ensure it is accessible from within your newly provisioned Kubernetes cluster. Now, we can start by creating the various Kubernetes deployment descriptors. This requires further source code inspection to determine services, storage requirements, ports, and network configuration to assemble the Kubernetes deployment files. At the same time, we need to apply Kubernetes specific security settings, deployment, and a rollout strategy and size the container resources. We're ready to deploy the migrated application; next we need to look at the in-flight data. 

In most cases, applications store data in a data source, Cloud Foundry can provision MySQL, PostgresQL or Redis. A direct migration would see Kubernetes managing this database in a container. This means that these containers need to be deployed, secured, and scaled in Kubernetes. Once this has been established, we need to sync the data between Cloud Foundry and Kubernetes; for this, we can utilise tools such as rsync. 

Manually migrating applications to Kubernetes is risky, not repeatable, and undoubtedly not efficient to repeat this for hundreds of applications. Hence, the Kubernetes Migration Platform or KMP from the HCL Cloud Native Labs is a SaaS-based application that can migrate hundreds of applications from Cloud Foundry to any Kubernetes distribution. KMP ensures that migrating applications to containers deployed in Kubernetes don't have to be complicated. It provides effortless migration without prior application knowledge, no production outages, avoids vendor lock-in, is repeatable, and does a complete data migration, often in minutes, using HCL's proprietary automated tooling, the Kubernetes Migration Platform. 

##

***To learn more about containerized infrastructure and cloud native technologies, consider joining us at KubeCon + CloudNativeCon Europe 2022, May 16-20.

ABOUT THE AUTHOR

Thomas De Vos Senior Solution Architect - Cloud Native Labs, HCL Technologies

Thomas De Vos is a Cloud-Native Architect, leading the Cloud Native Engineering team within the Cloud Native Labs at HCL Technologies in London. Thomas, a hands-on problem solver, has a wealth of experience and profound technical insight into designing enterprise applications for the last 20 years within large corporations, driving cloud-native innovations.