How to move from IBM Cloud Functions to IBM Code Engine

When migrating off IBM Cloud Capabilities, IBM Cloud Code Engine is without doubt one of the potential deployment targets. Code Engine provides apps, jobs and (just lately perform) that you would be able to (or want) to choose from. On this put up, we offer some dialogue factors and share ideas and methods on learn how to work with Code Engine capabilities.

IBM Cloud Code Engine is a totally managed, serverless platform to (not solely) run your containerized workloads. It has evolved a lot since March 2021, after I revealed the weblog put up “Migrating Cloud Functions Code to Code Engine.” In 2021, there have been solely Code Engine apps and jobs. Earlier this year, Code Engine added support for functions (Capabilities-as-a-Service, or FaaS).

On this put up, I’m going to take a contemporary have a look at that matter and focus on the choices on learn how to transfer from IBM Cloud Functions to Code Engine.

Apps, jobs and capabilities

IBM Cloud Code Engine options three different ways to run your business logic:

• An app is a constantly run course of that solutions to HTTP requests.
• A job runs to deal with a process after which terminates.
• A perform is a stateless code snippet that’s invoked by an HTTP request and, after producing a response, terminates. Furthermore, jobs often run considerably longer than capabilities (“batch processing”).

There are various extra characteristics that help distinguish between apps, jobs and capabilities. In brief, apps are a great match if you wish to craft a REST API or deploy an online utility with backend/frontend performance. You could have full management over the HTTP server and its sources.

Jobs, however, are long-running processes that don’t require any consumer interplay. They may very well be typical batch actions, analytics processing and even AI mannequin coaching.

Lastly, capabilities can react to incoming HTTP requests in a short time. They serve low-latency use instances nicely, like chatbot integrations or webhooks. In distinction to apps, you don’t and can’t outline and configure the HTTP server.

When coming from Cloud Capabilities, you will have skilled that there are various use cases supported by Cloud Functions. Equally, a perform could have completely different attributes which are vital relying on the case:

• The invocation or start-up time (chilly begin) could be vital, resulting in an general brief response time.
• In different instances, the associated fee (billing) might need been the aggressive issue.
• The simplicity and agility, attributable to a perform as unit for improvement and deployment in a DevSecOps course of leads some initiatives to go for capabilities.

Typically, it’s a mixture of the above that results in individuals preferring capabilities (FaaS) over different runtime or compute choices.

From Cloud Capabilities to Code Engine

When transferring from Cloud Capabilities to Code Engine, the next perform traits must be taken into consideration when deciding to on an app, a job or a Code Engine perform:

• Is an http endpoint wanted to invoke the code?
• Is the processing triggered by an occasion?
• What programming language is used for the prevailing perform and the way large are the required libraries?
• How lengthy does the processing take, what compute sources are wanted, is parallel processing desired?

The information Migrating IBM Cloud Functions to Code Engine has an in depth overview with Code Engine app, job and performance traits. They provide help to to pick out the most effective entity in your current workload. Moreover, the present Code Engine function limitations and the final limits and quotas for Code Engine must be taken into consideration. The part Migrating IBM Cloud Functions Actions to Code Engine Functions FAQ may provide help to determine learn how to migrate.

Suggestions and methods for Code Engine capabilities

The next ideas and methods are based mostly on my experiences with transferring current code from Cloud Capabilities to Code Engine capabilities. They assist in slicing down deployment cycles by first using native checks to implement related performance in combining Code Engine capabilities and jobs and designing built-in APIs by making use of Code Engine system variables.

Native testing of capabilities

Apps are common internet functions, jobs are like scripts, and each could be examined domestically in a number of methods. As a result of capabilities are code snippets, some wrapper is required to show them into applications. The next strategy has served me nicely to date.

With the perform code in a subdirectory “func,” I make the most of both the Python or Node.js wrapper code proven beneath and place it within the dad or mum listing. There, I additionally keep information with take a look at configurations as JSON objects, similar to what is passed by Code Engine to the function on invocation. For testing, I run the wrapper together with the configuration file as parameter. The wrappers for Python and Node.js are proven beneath:

# syntax: python wrapper.py params.json

# import the Code Engine perform: func/__main__.py
from func.__main__ import foremost
import sys, json

if __name__ == "__main__":
    # open file, learn JSON config
    with open(str(sys.argv[1])) as confFile:
        params=json.load(confFile)
    # invoke the CE perform and print the consequence
    print(foremost(params))

// syntax: node wrapper.js params.json

// require the Code Engine perform: func/foremost.js
var func=require('./func/foremost.js')

// learn the file with perform parameters
const fs = require("fs");
const knowledge = fs.readFileSync(course of.argv[2]);

// invoke the CE perform and log the consequence
console.log(func.foremost(JSON.parse(knowledge)));

Job-like capabilities

Typically, you may want the HTTP endpoint of a perform and the probably longer execution time of a job. In that case, create each a perform and a job. Then, make the most of the Code Engine API to create a job run from inside the perform. On this hybrid strategy, the perform can get referred to as by way of its HTTP endpoint and it terminates after kicking off the job run. A job may then run as much as 24 hours and profit from the parallel job processing capabilities in Code Engine. You could find a pattern implementation of this sample within the Code Engine code examples.

Surroundings variables and API design

For designing your API and capabilities namespace, you may make the most of Code Engine-injected environment variables like __ce_path and __ce_method. The previous holds the trail part of the requested URL like “/object”, and the latter has the HTTP methodology like GET or POST. By switching on the provided values for these variables, you may serve a number of API capabilities from the identical Code Engine perform. The profit is a single base URL.

Relying in your undertaking and code administration, you may even wish to mix this strategy with separating every API perform implementation into its personal file—much like the wrapper strategy proven above.

Conclusions

IBM Cloud Functions have many use instances and properties, so there isn’t a simple mapping to a selected Code Engine entity (i.e., app, job or perform). By evaluating an current (Cloud Capabilities) perform’s attribute to these of the Code Engine entities, you may decide the most effective match. In lots of instances, a Code Engine perform could be a sensible choice. For these instances, we shared ideas and methods that you need to use in your Capabilities-as-a-Service undertaking with Code Engine.

Use the next IBM Cloud Code Engine documentation to get began:

You probably have suggestions, solutions, or questions on this put up, please attain out to me on Twitter (@data_henrik), Mastodon (@data_henrik@mastodon.social) or LinkedIn.