IBM Cloud Code Engine: Three Tips for Migrating from Cloud Foundry
2 min read
Recently, IBM announced the deprecation of IBM Cloud Foundry. This post looks at migration options using IBM Cloud Code Engine.
IBM Cloud Code Engine is a fully managed, serverless platform that runs your containerized workloads, including web apps, microservices, event-driven functions and batch jobs. In this post, I am going to share what I've explored so far and tips for migrating from Cloud Foundry to Code Engine.
The goal here is to manually migrate a Node.js app on Cloud Foundry to Code Engine. In this example, I used a blank Cloud Foundry Node.js template and enabled a toolchain so that the source code exists in a private repository in
Later on, for a production migration, we should automate deployment using a new toolchain, but tips in this post should help your first step to migrate your microservices:
Tip 1. Write a Dockerfile and test
Make sure you create an appropriate Dockerfile for your app. Cloud Foundry apps on IBM Cloud used buildpacks and a Dockerfile was not mandatory as it is in Code Engine. However, it is a perfect time to move to Dockerfile to have more control and better performance. Due to the nature of Docker (run anywhere concept), I recommend you to check if your app starts in your local environment, if possible. Debugging a container build on IBM Cloud would be inefficient.
Tip 2. Configure repository access for a private repository
If you are directly pulling source code from a private repository, you must give Code Engine sufficient permission to the repository. If it is private, make sure you create a Code repo access. Please refer to this page for more details:
Tip 3. Check your service binding
Many existing Cloud Foundry apps use
Service binding to access other services, such as DB and Cognitive services. Service binding is a quick way to create service credentials for an IBM Cloud service, and if your Cloud Foundry app has been using service bindings, you need to create new bindings for your Code Engine app and update your source code.
To be specific, service binding information for your Cloud Foundry apps is stored in the
VCAP_SERVICES environment variable. However, for your Code Engine apps, it will be stored in
For example, I used Node.js and set console logs to show service bindings. I migrated it to Code Engine, and now you see
CE_SERVICES shows service binding between Cloud Object Storage, but
VCAP_SERVICES is undefined:
This is the console log I used:
Nowadays, it is common to have an automated build and deploy chain for many reasons. I recommend you try the Develop a Code Engine application template to understand the entire flow:
Please feel free to contact IBM client support for any questions or concerns.