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.