How to move from IBM Cloud Functions to IBM Code Engine

When migrating IBM Cloud Functions, IBM Cloud Code Engine is one of the possible deployment targets. Code Engine provides apps, tasks, and (recent features) you can choose from or need. This post provides some discussion points and shares tips and tricks on how to use Code Engine features.

IBM Cloud Code Engine is a fully managed serverless platform that runs containerized workloads. We’ve come a long way since March 2021, when I published the blog post ‘Migrating Cloud Functions Code to Code Engine’. In 2021, there were only Code Engine apps and jobs. Earlier this year, Code Engine added support for Functions-as-a-Service, or FaaS.

In this post, we’ll take a fresh look at the topic and discuss your options for moving from IBM Cloud Functions to Code Engine.

Apps, tasks and features

IBM Cloud Code Engine provides three ways to execute business logic.

• not app A continuously running process that responds to HTTP requests.
• all job It runs to process its work and then terminates.
• all function A stateless piece of code that is called by an HTTP request and terminates after generating a response. Moreover, jobs typically run much longer than functions (“batches”).

There are many more characteristics that can help you distinguish between apps, tasks, and features. This means that the app is perfect for you if you want to build a REST API or deploy a web application with backend/frontend functionality. You have full control over your HTTP server and its resources.

Tasks, on the other hand, are long-running processes that do not require user interaction. This could be a general batch activity, analytical processing, or AI model training.

Finally, functions can react very quickly to incoming HTTP requests. Ideal for low-latency use cases such as chatbot integrations or webhooks. Unlike apps, HTTP servers cannot and cannot be defined and configured.

If you’re new to Cloud Functions, you’ve probably experienced the many use cases that Cloud Functions supports. Likewise, functions may have other properties that are important in some cases.

• Call or startup times (cold starts) can be significant and result in shorter response times overall.
• In other cases, cost (billing) may have been a competitive factor.
• The simplicity and agility that comes from having a feature as the unit for development and deployment in the DevSecOps process makes it a choice for some projects.

It is often a combination of the above that leads people to prefer a feature as a service (FaaS) over other runtimes or compute options.

From Cloud Functions to Code Engine

When moving from Cloud Functions to Code Engine, you should consider the following feature characteristics when deciding on an app, task, or Code Engine feature.

• Do I need an http endpoint to call my code?
• Is processing triggered by events?
• What programming language is used for the existing functionality, and how large are the libraries required?
• How long does it take to process, what computing resources are required, and is parallel processing required?

The IBM Cloud Functions to Code Engine migration guide includes a detailed overview of Code Engine apps, tasks, and feature characteristics. It helps you choose the entity that best suits your existing workloads. You should also consider current code engine feature limitations and general limits and quotas for the code engine. The Migrating IBM Cloud Functions Actions to Code Engine Functions FAQ section can help you decide how to migrate.

Tips and tricks on Code Engine features

The following tips and tricks are based on our experience moving existing code from Cloud Functions to Code Engine functions. First, you can leverage local testing to implement similar functionality when combining Code Engine features and operations, and leverage Code Engine system variables to design integrated APIs to help shorten your deployment cycle.

Local testing of functionality

Apps are regular web applications, tasks are similar to scripts, and both can be tested locally in several ways. A function is a piece of code, so you need some wrapper to transform it into a program. The following approach has served me well so far:

Take the function code in the subdirectory “func” and place it in the parent directory leveraging the Python or Node.js wrapper code shown below. This is where the code engine maintains a file containing your test configuration as a JSON object, similar to what you pass to your function when you call it. For testing, we run the wrapper with the configuration file as a parameter. Here are wrappers for Python and Node.js:

# syntax: python wrapper.py params.json

# import the Code Engine function: func/__main__.py
from func.__main__ import main
import sys, json

if __name__ == "__main__":
    # open file, read JSON config
    with open(str(sys.argv(1))) as confFile:
        params=json.load(confFile)
    # invoke the CE function and print the result
    print(main(params))

// syntax: node wrapper.js params.json

// require the Code Engine function: func/main.js
var func=require('./func/main.js')

// read the file with function parameters
const fs = require("fs");
const data = fs.readFileSync(process.argv(2));

// invoke the CE function and log the result
console.log(func.main(JSON.parse(data)));

Work-like functions

Sometimes you may need an HTTP endpoint for your function and the task may take longer to run. In this case, create both a function and an action. You then leverage the Code Engine API to create task executions within your function. In this hybrid approach, the function can be called through an HTTP endpoint and starts executing the task before exiting. The job can then run for up to 24 hours and take advantage of Code Engine’s parallel job processing capabilities. You can find a sample implementation of this pattern in the Code Engine code examples.

Environment variables and API design

You can leverage the following code engine injection environment variables to design your API and function namespaces: __ce_path and __ce_method. The former holds the path component of the requested URL, such as “/object”, while the latter has HTTP methods, such as GET or POST. By turning on the provided values ​​for these variables, you can provide multiple API functions from the same code engine function. The benefit is a single base URL.

Depending on your project and code management, you may want to combine this approach with separating each API function implementation into its own file, similar to the wrapper approach shown above.

conclusion

Because IBM Cloud Functions has many use cases and properties, there is no direct mapping to a specific code engine entity (such as an app, task, or function). You can compare the properties of your existing (Cloud Functions) function with the properties of your code engine item to choose the best fit. In most cases, the Code Engine feature may be a good choice. In these cases, we’ve shared tips and tricks you can use for your Functions-as-a-Service projects using Code Engine.

Use the following IBM Cloud Code Engine documentation to get started.

If you have any feedback, suggestions, or questions about this post, follow us on Twitter:@data_henrik), Mastodon (@data_henrik@mastodon.social) or LinkedIn.