For developers, the ability to automate builds and deliver them is important. As a practice, this is commonly called continuous integration and continuous delivery.

A developer with code to build and run on JBoss EAP in an OpenShift cloud has multiple options. Use a standard Dockerfile, use OpenShift source-to-image (S2I) capabilities, or implement a custom chain of build tools. OpenShift S2I is popular with developers as it takes application source code as an input and produces a new image representing the assembled application that runs as output.

For a developer using JBoss Developer Studio, the S2I process starts with creating a new OpenShift application project. As part of the project definition, a template is chosen that will simplify the creation of objects needed for the application to run OpenShift. As the developer creates the application and checks code into a Git repository, that repository can publish a notice that code has changed via a webhook. The webhook  makes a call to OpenShift that in turns pulls the latest source code and executes a build script that ultimately results in the objects needed to run on OpenShift. This includes the Docker formatted image along with deployment, image stream, route, and service objects. Basically all that is needed to get the application up and running and orchestrated by Kubernetes.

Templates can be used to define a group of components that an application is composed of. These resources could be for example the frontend, backend, cache, database, etc. Using templates, a developer can instantiate an entire application (e.g. microservices) on-demand as an example for creating test environments. Most developers will not need to know the details of templates. Simply that they exists and that they should use them as part of coding activities. A smaller community of advanced development and architects typically know the details of the templates and make adjustments as needed to meet deployment standards. All acceptable and anticipated activities when deploying to an OpenShift cloud.

Building Java applications for Pivotal tcServer varies from using the Java buildpack that runs on Cloud Foundry. For tcServer, Java code is compiled into WAR files that are deployed to a runtime directory.

For Cloud Foundry deployments, there are more coding options and the deployment process is more complicated. First code can be created using Grails, Groovy, Java code with a Main function, Play Framework, Spring Boot, and Servlet. The process for compiling and packaging code varies by the type of code being created. For example, Grails packages up WAR files, Gradle and Java code can be packaged as JAR files, Groovy is based on Ratpack, and Spring Boot can be deployed without packaging as POJOs. Developers must follow the Pivotal documentation to properly compile and package up code that will get pushed to Cloud Foundry.

Code is compiled and packaged into a JAR or WAR file using maven or Grails. From there, the JAR or WAR file is pushed to Cloud Foundry. Once in Cloud Foundry, tuning of the application runtime footprint can be started.

How you build applications for IBM BlueMix will vary depending on if you are using WebSphere Liberty profile running via a Cloud Foundry buildpack or a Docker image in the BlueMix container service. Applications built and deployed to WebSphere Liberty Profile or WebSphere Application Server running on BlueMix virtual machines follow the same procedures as if you were to build, connect, and deploy to any other virtual machine.

For the WebSphere Liberty Profile service running on Cloud Foundry, the IBM Eclipse Tools for BlueMix or the Cloud Foundry CLI utility can be used. The IBM Eclipse Tools for Bluemix is graphical and generally popular as it is easier to use. In either case, the developer must chose to push a compiled application (WAR or EAR file), a server directory, or a packaged server to BlueMix.

The packaging choice depends on the complexity and deployment needs of the application. If an application can work with just Java EE 7 web profile features or a subset of those, then a compiled application can be pushed. If more features  than are in the Java EE 7 Web Profile or a custom server.xml file is needed to configure WebSphere Liberty Profile, then the server directory or packaged server option can be used. For even more customized application runtime profiles using shared resources, the packaged server option is used.

Clearly the IBM BlueMix application developer needs a complete understanding of the application as well as how the WebSphere Liberty Profile needs to be configured at runtime to determine the appropriate packaging. Additional steps to configure scaling and load balancing for the application are also required. Compare this to JBoss EAP on OpenShift, where the build process uses templates to set up the core object that are later used for managing the runtime configuration.

For applications built and deployed to WebSphere Liberty Profile running on BlueMix containers, the build process is completely different. In this case, the developer is responsible for all steps required to create the Docker image that is upload to the private BlueMix repository for deployment, a private repository that is limited to just 25 images by organization. This is an extremely small number of images if your objective is to run Java applications using Docker containers, especially if you want to run a microservice architected application where it is not unusual to deploy large numbers of individual services, each packaged as a container. This IBM limitation calls into serious question if IBM containers can reasonably accommodate microservice deployments. Even when deploying a monolithic Java EE application using containers, there could be high enough utilization to challenge the 25 image limit.

Oracle cloud offerings do not include source to image utilities like those included with OpenShift by Red Hat. Instead, Java applications are built on a developer’s computer or centralized server and then deployed to a WebLogic server. DevOps toolchains and integration with source code control systems are the responsibility of the development team.

Once applications are built, deployment can be performed using an IDE, via manual transfer of files, or using the the administrative console provide by WebLogic server or the Oracle Cloud Server.

Comments are closed.