Upgrading TIBCO BusinessWorks Container Engine Runtime in Docker

Summary

I considered an alternative Title ? ?How Containerisation massively reduces your upgrade process?, as this is applicable for any technology that you containerise, but I wanted to show you how to do this specifically with TIBCO BusinessWorks Container Edition as it removes one of the biggest costs/effort of upgrading a BusinessWorks infrastructure.

Let?s consider a scenario with ?classic? BusinessWorks ? either version 5.x or 6.x. Here, you will have a set of servers (deployed on either physical/virtual/cloud) where you deploy the applications that you build. These applications are tested, running and scaled to the right level to cope with your peak demand.

Let?s say you have BusinessWorks 6.7.0 running and things are nice and stable (as all things TIBCO are of course!). TIBCO release 3 new versions of BusinessWorks over the next 2 years, let?s call them 6.8.0, 6.8.1 and 6.9.0. This means that you are now 3 versions behind and TIBCO?s support policy means that they will announce an end of support date for 6.7.0 in due course. Once that happens ? if you raise a Support Call ? you are quite likely to be asked to perform an upgrade before support is provided.

So ? to keep up with support you need to upgrade your TIBCO platform to the most appropriate version in order to stay current and make sure that TIBCO will provide support for your version.

The above policies are valid for most Enterprise Software Vendors in the market today ? so you can replace TIBCO with any other vendor name to suit your environment.

What it means though, is that you and your development team must build into your plans the appropriate time and effort as part of your BAU process alongside building new projects and providing maintenance for existing projects to ensure you can upgrade the platform.

Unfortunately, this doesn?t always happen and it can come as an unwelcome surprise that you are going to have to plan an unscheduled upgrade.

As TIBCO BusinessWorks runs many of the world?s core businesses ? upgrading a classic BusinessWorks infrastructure means a lot of planning. I know of organisations that process Billions of $ orders EVERY DAY on TIBCO ? so your upgrade can?t go wrong. There?s a lot of planning, testing, re-testing and potential downtime too.

Alongside this ? you?ve also decided to move to Containerisation as part your digital transformation planning and that includes moving your TIBCO BusinessWorks applications to Container Edition.

If you are already on BusinessWorks 6.x ? moving those applications to Container Edition is pretty straightforward, from BusinessWorks 5.x TIBCO provide tooling to help as well as a migration factory for large projects ? but I want this article to focus on what it means to upgrade the container runtime for a deployed container edition application as there are other resources and blogs that cover migrating to Container Edition.

If you?ve seen some of my previous blogs ? you?ll recognise my simple Greeting microservice that is a simple REST API that responds with a message and the container hostname:

This application is built using the following Docker File:

 FROM bwce:latest LABEL maintainer="Dave Winstone" ADD greeting_1.0.0.ear / EXPOSE 8081 7777

You?ll notice the first line tells the docker build command that I?ll be using the latest version of my TIBCO BusinessWorks Container Edition (bwce) base image. Best practice though is to specify a specific version to ensure you are pulling the right image for your deployment. It also means that you should be maintaining your Docker files in source code control too.

It goes without saying (almost) that you should also be building and deploying your applications with a DevOps pipeline to automate everything and remove human error ? but I want to show you how you would upgrade the runtime manually.

The greeting application itself is the ?greeting_1.0.0.ear? file. In this example I?ve changed the output very slightly to include the BusinessWorks runtime engine version as part of the output.

Building the BusinessWorks Container Edition Base Image

There?s lots of instructions and different examples of how to do this at TIBCO?s official github repo here that I?d recommend you take a look at.

I?m going to start with my application built using version 2.7.3 of BusinessWorks Container Edition, then upgrade the runtime to 2.8.0.

Once you?ve followed the instructions from the TIBCO GitHub to clone the BWCE repo. and downloaded the BWCE runtime from TIBCO?s download site you are ready to build the base image using a command similar to the following from the cloned bwce repo:

 ./createDockerImage.sh ~/bwce-runtime-2.7.3.zip bwce:v2.7.3

The first argument is the BWCE runtime zip file that you downloaded from TIBCO, and the second argument is the tag we?ll be using.

Building the Application Container Image

I?ll adjust my application Dockerfile to include the correct base image tag as follows:

 FROM bwce:v2.7.3 LABEL maintainer="Dave Winstone" ADD greeting_1.0.0.ear / EXPOSE 8081 7777

Now to build the application:

 docker build -f Dockerfile -t greeting-app:1.0 .

And to run the application:

 docker run -p 8081:8081 greeting-app:1.0

To see the results, I can issue a simple Curl command and see the response:

So all good.

But now we have a new version of the BusinessWorks Container Edition Runtime that we want to use ? but I don?t want to rebuild the original EAR file, as that would result in a code change ? leading to regression testing, UAT etc. Plus usually it means that the whole platform needs to be upgraded ? but we only need this single microservice to be updated as there?s a bug that?s been fixed by TIBCO that we need for this single microservice.

In this instance, all we need to do is rebuild the base image for BusinessWorks Container Edition, alter the Dockerfile of my application to use that new image and then rebuild the container image and re-run.

Update the Base Image

To rebuild the base image to use v2.8.0 of BusinessWorks Container Edition, we first need to remove the bwce-runtime-2.7.3.zip from the resources folder under the cloned bwce repo, then run the command (assuming I have downloaded the bwce-runtime-2.8.0.zip file from TIBCO):

 ./createDockerImage.sh ~/bwce-runtime-2.8.0.zip bwce:v2.8.0

Make a small change to our Dockerfile to use this new version (tag is bwce:v2.8.0):

 FROM bwce:v2.8.0 LABEL maintainer="Dave Winstone" ADD greeting_1.0.0.ear / EXPOSE 8081 7777

And to rebuild the application:

 docker build -f Dockerfile -t greeting-app:1.0 .

And to run the application:

 docker run -p 8081:8081 greeting-app:1.0

And using my Curl command I can test the new version of the application to see if the BusinessWorks Container Edition runtime has been upgraded:

Conclusion

As you can see ? we have successfully upgraded the BWCE runtime within our container for our Greeting microservice.

This is a huge benefit to containerisation ? particularly where your microservices utilise other frameworks or integration frameworks like TIBCO for your API strategies.

What?s even more interesting is that this approach does not force you to upgrade every microservice to the same runtime version all at the same time? different versions can co-exist at the same time, which allows you to better plan upgrades alongside existing development and maintenance activities rather than having to plan a separate activity just for upgrading the platform. Co-Existence of containers running different versions of the core run-time is actually a better way of making the best use of developers and operations time.

If you think about the time, resources and money that you would normally spend on performing this type of upgrade and comparing that to what you save using this approach, I think you?ll agree that taking this approach is well worth the effort.