Once an application is built it is ready to be deployed, updated, and accessed. As mentioned earlier using JBoss EAP on OpenShift, an application that is built using the S2I process typically includes many of the objects needed to run it. Specifically, when using the out of the box JBoss EAP 7 application template for OpenShift v3.x, multiple objects with be created. Some are most useful for developers while others of of greater use for IT operations.

Table 1. Developer objects

Object Purpose
Build A special container that runs once in OpenShift to build your applications. The types of builds possible are standard Dockerfile, OpenShift source-to-image, or a custom chain of build tools.
  • Defines the specified number of container images to run.
  • Drives automated deployments in response to events.
  • Transitions from the previous deployment to the new deployment through user-customizable strategies, e.g. rolling deployment.
  • Rollbacks to a previous deployment.
  • Manual replication scaling.


Table 2.  IT operations objects

Object Purpose
Image stream Automatically performs an action, such as updating a deployment, when a new image, such as a new version of the base image that is used in that deployment, is created.
Route Allows the OpenShift cloud to be reached using an externally-reachable hostname such as www.
Service Allows service discovery and load balanced access to deployed services. For example deployed microservices deployed and accessed using REST.


JBoss EAP and OpenShift, together, provide developer benefits beyond just a software build:

  • Automatic scalability of applications
  • Load balancing of scaled applications
  • Versioning of deployed applications, including tearing down a running old version and replacing it with a new version
  • Rollback of applications to a previous version
  • Ability to test an application internally plus the option to expose ports for external testing

By default, Pivotal build activities for defining runtimes are less comprehensive and can require post-build work to get an application ready to run reliably at scale, such as  creating Cloud Foundry routes, domains, and defining scaling parameters.

The Pivotal Java buildpack is preconfigured to run applications created using Grails, Groovy, Java code with a Main function, Play Framework, Spring Boot, and Servlet. However, the buildpack is provided with many pre-set parameters that can be overridden either using environment variables or using a forked buildpack. The forked buildpack allows various YAML files to be modified. Users must determine which method of setting parameters is more convenient and reproducible.

IBM build activities for defining runtimes are less comprehensive and can require post-build work to get an application ready to run reliably at scale. For the WebSphere Liberty Profile service running on Cloud Foundry you deploy applications to a service and then scale that service.  Scaling is either defined statically using the BlueMix console or automatically using a policy using the IBM Auto-Scaling for Bluemix service.

When running WebSphere Liberty Profile on IBM Containers in BlueMix, two different methods are available for grouping and scaling containers. One is a container group for multiple instances of a single container. The other is Docker Compose for collections of containers that should be run together. Compare this to OpenShift by Red Hat which has the concept of pods for running one or more containers deployed on one host. A single consistent concept to administer that reduces the potential confusion IBM BlueMix administrators face.

Once your containers on BlueMix are grouped you then have to distribute traffic between them. When using a single container image within a container group, BlueMix provides a built-in load balancer. However, when using Docker Compose to group containers, BlueMix users must provide their own load balancer and link to to the containers defined using Docker Compose.

Configuration of the Oracle cloud runtime is initially performed using a web process that allows you to select the WebLogic edition to use, billing frequency, and various service details such as memory per instance, cluster size, and load balancing. Oracle provides defaults for all values making it relatively easy to get a default configuration up and running. The more tailored an environment is needed, the more manual configuration work must be done during the setup process, schoosing shapes (CPU, memory)  to allocate to the virtual machines that will contain the WebLogic servers, setting up load balancing options, and configuring backup and recovery.

JBoss EAP running on OpenShift is also set up using default values that can be manually overridden. OpenShift provides administrators the ability to repeatedly deploy customized cloud configurations, a capability that is missing from the Oracle Java Cloud Service.

Comments are closed.