Lessons learned from converting an IBM Cloud Code Engine app to a job.

Last year, I blogged about how to set up scheduled tasks on IBM Cloud with cron-like jobs. In that article, I discussed an app hosted on IBM Cloud Code Engine — that app was a Twitterbot. The cron subscription service would invoke the app based on the configured schedule. Then, the bot would retrieve a news/blog feed, compose a tweet and publish it as status update on Twitter.

Times have changed (pun intended) and IBM Cloud Code Engine has evolved. It introduced jobs for batch-oriented processing, followed by subscription support for jobs. Thus, a solution like the bot is now served best by a job. In this blog post, I am going to show you what it took to turn the Code Engine app into a job. I conclude by discussing the advantages of that job approach over the app:

Solution architecture: The bot is coded in Go and runs as a Code Engine job.

Twitterbot overview

My bot is quite simple and, regardless of being an app or job, the architecture is the same. The Twitterbot is coded in Go and deployed as a container on IBM Cloud Code Engine. The container images is created from the source code on GitHub using the Code Engine build capabilities. Once built and deployed as a job, its runs (job executions) are triggered by a timer — a cron subscription.

For each run, the Go program has access to its configured environment variables and the payload data as set up as part of the cron subscription. That way, the bot knows which RSS feed to consume, how many recent blog posts to consider, how to compose the tweet itself and the credentials to access the Twitter account. With that information, the program contacts the feed server, fetches the recent articles, composes the tweet and finally posts it as Twitter status update.

The sequence of steps is the same for my old Code Engine app and the new job. So, what are the differences?

Moving from Code Engine app to job

Changing the Twitterbot from a Code Engine app to a job required two code changes:

  1. Apps are programs that run an http server. The former Twitterbot started the http server and then waited for incoming POST requests, which triggered the tweets. Jobs, on the other hand, are programs that are invoked, perform some processing and then terminate
  2. The task information about which RSS feed to process the payload was delivered to the bot as data of the POST request. A job gets invoked with parameters. Therefore, the way information is passed needs to be adapted.

Everything else can be kept as is. Code Engine apps and jobs both are containerized workloads that run in a serverless fashion. The container images can either be built by Code Engine from your source code or directly provided by you via a container registry. In both scenarios, a cron subscription (i.e., a time event) triggers the Twitter status. Moreover, both the app and job are part of a Code Engine project. For the migration, I simply added a job to the existing project, configured a new build based on its new GitHub branch and then reconfigured the existing subscriptions.

The code migration has some benefits. The code itself and the container image for the job are smaller because I could remove the code for the unnecessary http server. The job is also more secure because it does not require the app to have a REST API (i.e., an open port with required authentication). Jobs are simply invoked internally by Code Engine. As a consequence, I could remove the secret token from the event payload. If required, I could still manually run the job on demand, without a subscription event. And that’s exactly what caused the first tweet by the updated job-based Twitterbot:

The first job-based tweet.


In this blog post, I discussed how I converted an existing IBM Cloud Code Engine app into a job, which is a better fit for the presented Twitterbot solution. The code migration required only two changes but led to benefits like smaller code, smaller image size and improved security.

If you want to learn more about IBM Cloud Code Engine, I recommend the “getting started tutorial” for beginners or the advanced scenario of a serverless web app and eventing for data retrieval and analytics.

If you have feedback, suggestions, or questions about this post, please reach out to me on Twitter (@data_henrik) or LinkedIn


More from Cloud

Kubernetes version 1.28 now available in IBM Cloud Kubernetes Service

2 min read - We are excited to announce the availability of Kubernetes version 1.28 for your clusters that are running in IBM Cloud Kubernetes Service. This is our 23rd release of Kubernetes. With our Kubernetes service, you can easily upgrade your clusters without the need for deep Kubernetes knowledge. When you deploy new clusters, the default Kubernetes version remains 1.27 (soon to be 1.28); you can also choose to immediately deploy version 1.28. Learn more about deploying clusters here. Kubernetes version 1.28 In…

Temenos brings innovative payments capabilities to IBM Cloud to help banks transform

3 min read - The payments ecosystem is at an inflection point for transformation, and we believe now is the time for change. As banks look to modernize their payments journeys, Temenos Payments Hub has become the first dedicated payments solution to deliver innovative payments capabilities on the IBM Cloud for Financial Services®—an industry-specific platform designed to accelerate financial institutions' digital transformations with security at the forefront. This is the latest initiative in our long history together helping clients transform. With the Temenos Payments…

Foundational models at the edge

7 min read - Foundational models (FMs) are marking the beginning of a new era in machine learning (ML) and artificial intelligence (AI), which is leading to faster development of AI that can be adapted to a wide range of downstream tasks and fine-tuned for an array of applications.  With the increasing importance of processing data where work is being performed, serving AI models at the enterprise edge enables near-real-time predictions, while abiding by data sovereignty and privacy requirements. By combining the IBM watsonx data…

The next wave of payments modernization: Minimizing complexity to elevate customer experience

3 min read - The payments ecosystem is at an inflection point for transformation, especially as we see the rise of disruptive digital entrants who are introducing new payment methods, such as cryptocurrency and central bank digital currencies (CDBC). With more choices for customers, capturing share of wallet is becoming more competitive for traditional banks. This is just one of many examples that show how the payments space has evolved. At the same time, we are increasingly seeing regulators more closely monitor the industry’s…