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

IBM Cloud VMware as a Service introduces multitenant as a new, cost-efficient consumption model

4 min read - Businesses often struggle with ongoing operational needs like monitoring, patching and maintenance of their VMware infrastructure or the added concerns over capacity management. At the same time, cost efficiency and control are very important. Not all workloads have identical needs and different business applications have variable requirements. For example, production applications and regulated workloads may require strong isolation, but development/testing, training environments, disaster recovery sites or other applications may have lower availability requirements or they can be ephemeral in nature,…

IBM accelerates enterprise AI for clients with new capabilities on IBM Z

5 min read - Today, we are excited to unveil a new suite of AI offerings for IBM Z that are designed to help clients improve business outcomes by speeding the implementation of enterprise AI on IBM Z across a wide variety of use cases and industries. We are bringing artificial intelligence (AI) to emerging use cases that our clients (like Swiss insurance provider La Mobilière) have begun exploring, such as enhancing the accuracy of insurance policy recommendations, increasing the accuracy and timeliness of…

IBM NS1 Connect: How IBM is delivering network connectivity with premium DNS offerings

4 min read - For most enterprises, how their users access applications and data is an essential part of doing business, and how they service those application and data responses has a direct correlation to revenue generation.    According to We Are Social’s Digital 2023 Global Overview Report, there are 5.19 billion people around the world using the internet in 2023. There’s an imperative need for businesses to trust their networks to deliver meaningful content to address customer needs.  So how responsive is the…

IBM Cloud Databases for MongoDB (Enterprise Edition): Changes to backup functionality

< 1 min read - We are announcing that IBM Cloud Databases for MongoDB (Enterprise Edition) will no longer support the creation of On Demand backups beginning on March 1, 2024. On Demand backups are being replaced by the recently deployed Point in Time Recovery (PITR) capabilities in the Enterprise Edition of our popular fully managed MongoDB service. With PITR, you can restore a copy of your database to any point in the past seven days. This gives you granular access to the past state…