IBM Cloud Code Engine: Three Tips for Migrating from Cloud Foundry

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.

Goal

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 https://REGION.git.cloud.ibm.com.

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 CE_SERVICES.

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:

app.listen(process.env.PORT, '0.0.0.0', function() {
  console.log("server starting on " + appEnv.url);
  // CF Environment var
  console.log("Binded service : process.env.VCAP_SERVICES = " + process.env.VCAP_SERVICES);
  // CE Environment var
  console.log("Binded service : process.env.CE_SERVICES = " + process.env.CE_SERVICES);
  console.log("PORT : " + process.env.PORT);
  // Test for custom environment var "test"
  console.log("CUSTOM ENV VAR : " + process.env.test);
});

What's next?

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.