This page provides an overview of the Cloud Foundry build process you need tomigrate from, and provides a description of the various ways you can migrate fromthat to a process that builds OCI-compliant containers.

Cloud Foundry build process overview

When an application is pushed to Cloud Foundry, it goes through a build stagewhere the source code is compiled by theCloud Foundry v2 buildpacks.

The output of a Cloud Foundry build process creates a runnable archiveknown as adroplet.Droplets are not directly compatible with the Open Container Initiative (OCI)specification for running containers on Cloud Run.

When migrating applications from Cloud Foundry to Cloud Run you mustchange the application build process to generate industry standard OCIimages (sometimes referred to as Docker images).

Strategies to achieve OCI-compliant images

There are three migration strategies you can choose from to build OCI-compliantcontainers:

• Modify the existing Cloud Foundry application (sometimes referred to as "lift and shift")
• Use Cloud Native buildpacks
• Use self-managed Dockerfiles

Modifying a Cloud Foundry application (lift and shift)

The core components of the Cloud Foundry ecosystem (v2 Buildpacks, Stemcells,etc.) are open source. This means you can re-create the applicationcontainerization process by following our guide to "Dockerize" the core buildcomponents to create a new OCI-compliant image.

Pros:

• It requires the least amount of application refactoring and customization.
• The process is repeatable for all application instances.

Cons:

• The pipeline for building application containers is self-managed.
• Older Cloud Foundry components have diminished maintenance and support.
• There are ongoing security maintenance costs, including:
  • Routinely re-building the build components to ensure you getsecurity patches.
  • Routinely re-building the "dockerized" applications to take on the security updates from therebuilt build components.

Using Cloud Native Buildpacks

TheCloud Native Buildpacks (CNB) specification wascreated to modernize and unify the buildpacks ecosystem. Builders compatible withthe CNB specification follow open standards and create OCI-compliant images.Three common CNB providers are:

• Google Cloud's buildpacks
• VMware's Paketo buildpacks
• Heroku's buildpacks

Pros:

• Buildpack maintainers and platform providers are responsible for maintenanceof the buildpack.
• Buildpacks support rebasing containers on new images for fast securityupdates without rebuilding application containers.
• Buildpacks generate portable OCI images.
• The CNB project isincubating under the Cloud Native Computing Foundation (CNCF) and has an active community of maintainersand contributors.

Cons:

• Functionality and configuration gaps between v2 and v3 buildpacks.
• Frameworks and integrations installed on your behalf in theJava v2buildpacks may not beavailable in the Java CNB buildpack.

Using self-managed Dockerfiles

You can author completely new Dockerfiles to containerize your application.Refer tobuilding containers to learn aboutcontainer images accepted by Cloud Run.

Pros:

• Gives you the most flexibility in designing your applications.
• Leverage your company's existing container tooling & build strategies.

Cons:

• Dockerization and custom configuration must be performed for each application,leading to potentially time consuming debugging and rewrites.
• Difficult to standardize implementations across multiple teams.
• Patching images requires a full rebuild and redeploy.

Recommendations

Teams that are resource-constrained and looking to move as many applicationsas possible should first consider theLift and Shift strategy to modify Cloud Foundry. Oncethe applications are modernized to towards being OCI-compliant images, werecommend that you consider using Cloud Native Buildpacks orself-managed Dockerfiles.

Teams that are ready to migrate immediately should try Cloud Native Buildpacksand then move to self managed Dockerfiles if they need a high level of controlover their environment.

What's Next

• Follow thesample Spring Music migrationwhich uses the lift and shift strategy.
• Migrate to OCI containers