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:

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:

Conclusions

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.