When migrating off IBM Cloud Capabilities, IBM Cloud Code Engine is among the doable deployment targets. Code Engine gives apps, jobs and (lately perform) that you may (or want) to select from. On this publish, we offer some dialogue factors and share suggestions and methods on find out how to work with Code Engine features.
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 printed the weblog publish “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 publish, I’m going to take a contemporary take a look at that subject and focus on the choices on find out how to transfer from IBM Cloud Functions to Code Engine.
Apps, jobs and features
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 job 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 normally run considerably longer than features (“batch processing”).
There are numerous extra characteristics that help distinguish between apps, jobs and features. In brief, apps are a superb match if you wish to craft a REST API or deploy an internet software with backend/frontend performance. You will 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, features can react to incoming HTTP requests in a short time. They serve low-latency use instances effectively, 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 could have skilled that there are numerous use cases supported by Cloud Functions. Equally, a perform might have completely different attributes which can be essential relying on the case:
- The invocation or start-up time (chilly begin) is likely to be essential, resulting in an total quick response time.
- In different instances, the fee (billing) may need been the aggressive issue.
- The simplicity and agility, brought on by a perform as unit for growth and deployment in a DevSecOps course of leads some tasks to go for features.
Typically, it’s a mixture of the above that results in individuals preferring features (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 should 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 massive 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 assist you to pick the perfect entity in your present workload. Moreover, the present Code Engine function limitations and the overall limits and quotas for Code Engine should be taken into consideration. The part Migrating IBM Cloud Functions Actions to Code Engine Functions FAQ would possibly assist you determine find out how to migrate.
Suggestions and methods for Code Engine features
The next suggestions and methods are primarily based on my experiences with transferring present code from Cloud Capabilities to Code Engine features. They assist in reducing down deployment cycles by first using native checks to implement comparable performance in combining Code Engine features and jobs and designing built-in APIs by making use of Code Engine system variables.
Native testing of features
Apps are common net functions, jobs are like scripts, and each could be examined domestically in a number of methods. As a result of features are code snippets, some wrapper is required to show them into packages. The next method has served me effectively up to now.
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 father or mother listing. There, I additionally preserve information with check 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 end result
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 end result
console.log(func.foremost(JSON.parse(knowledge)));
Job-like features
Typically, you would possibly want the HTTP endpoint of a perform and the presumably 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 method, 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 will discover a pattern implementation of this sample within the Code Engine code examples.
Setting variables and API design
For designing your API and features namespace, you’ll be able to make the most of Code Engine-injected environment variables like __ce_path
and __ce_method
. The previous holds the trail element 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’ll be able to serve a number of API features from the identical Code Engine perform. The profit is a single base URL.
Relying in your undertaking and code administration, you would possibly even need to mix this method with separating every API perform implementation into its personal file—much like the wrapper method proven above.
Conclusions
IBM Cloud Functions have many use instances and properties, so there is no such thing as a easy mapping to a particular Code Engine entity (i.e., app, job or perform). By evaluating an present (Cloud Capabilities) perform’s attribute to these of the Code Engine entities, you’ll be able to decide the perfect match. In lots of instances, a Code Engine perform is likely to be a sensible choice. For these instances, we shared suggestions and methods that you should use in your Capabilities-as-a-Service undertaking with Code Engine.
Use the next IBM Cloud Code Engine documentation to get began:
In case you have suggestions, solutions, or questions on this publish, please attain out to me on Twitter (@data_henrik), Mastodon (@data_henrik@mastodon.social) or LinkedIn.