Application Platform Cloud Pak blog series: Part 2
This blog is Part 2 in the Application Platform Cloud Pak series. Check out Part 1 if you haven’t already.
Offload workloads to the cloud. Improve your DevOps and speed-to-market. Tap into the consistency and reliability of containers.
These are just some of the benefits of application modernization. But what if you can’t yet afford to rebuild your applications into a modern, built-for-the-cloud application server such as WebSphere Liberty? You can still be cloud-enabled and embark in the journey to containers with the new WebSphere Application Server (WAS) Cloud Pak!
This path starts as you evaluate your on-premises application portfolio with Transformation Advisor (which provides a visual report of each application’s ability to move into a cloud-native environment) and ask yourself: These applications over here are ready to be modernized and run in WebSphere Liberty docker containers. But what about the ones that don’t fit this pattern?
Generally, these are apps that depend on traditional APIs. If they have truly strong ties both at the application level and at the operational level, they are a good fit for the lift-and-shift pattern via provisioned VMs. However, if these traditional APIs do not have a strong tie to Network Deployment, they are able to refactor their operational attributes to run under a different management plane. We refer to this as operational modernization—which is a stepping stone into the full application modernization.
Putting this into more specific WebSphere terms: These are apps that can run under a traditional WebSphere base Docker container and replace ND functionality with Kubernetes, typically mapping to the moderate results from Transformation Advisor. During this move into containers (either via traditional WAS containers or directly to Liberty containers) is a perfect time to break down the monolith application into smaller microservices.
Much like the WebSphere Liberty Cloud Pak, the traditional counterpart focuses on simplifying production-grade deployments by providing a base Docker image that follows the container industry’s best practices and a Helm chart that adds consistency and standardization to your enterprise devOps pipeline. This is fully supported when deployed on IBM Cloud Private (ICP).
Let’s look at the individual pieces that compose this Cloud Pak.
Build your custom Docker application image
The new traditional v9 WAS images are available from Docker Hub, and they have been redesigned to allow customers to reuse their Jython scripts and properties file while building their application image. This pattern takes advantage of existing WAS administration skills and assets.
Its corresponding documentation, available freely on GitHub, has also been rewritten to clearly guide customers on proper usage and best practices. Check out the samples today to start using this image and provide feedback to us via the GitHub issues tracker.
Production-grade deployment with our Helm chart
We have also provided a production-grade helm chart on GitHub, which is loaded by default into IBM Cloud Private‘s catalog. This chart is extremely secure by design, able to run in IBM’s most secured policy (which means it does not require any elevated privileges nor run as root), and contains a rich set of configurable parameters using standard Helm mechanisms to ensure consistent enterprise deployments, such as Ingress setup and Horizontal Pod Autoscaling.
Two new value-adds:
Dynamic startup properties: You can create a Kubernetes ConfigMap containing a set of traditional WAS properties and bind them to the application container during startup by simply specifying the name of the ConfigMap.
Persisted logs: The logs from traditional WAS are written into the container’s /logs folder, which can be written to a Persistent Volume by enabling a single boolean attribute.
Enough talk, let’s see this in action. In the following video, we will walk through our Hello World sample, which demonstrates how to use the components of the Cloud Pak to deploy your traditional WAS application into ICP!
Try out all this today for free! Start by building your application image and then deploy this into any Kubernetes using the Helm chart
Some things to consider
In the operational modernization journey, there are a few things to take into consideration:
JSON logging: Currently, the traditional WAS container does not emit JSON logs. Watch this space in the next month or so for a possible update.
Load balancing: The load balancing of services in a Kubernetes environment is done via the Ingress Controller. This is the preferred way because it lets the same management plane coordinate the PODs lifecycle and traffic into them.
Other QoS functionality: Watch the traditional WAS base Helm chart documentation for future updates on other QoS functionality, such as EJBs and transaction recovery and how it maps into the Cloud Pak capabilities.
The traditional WAS image, for entitled WAS customers, is supported anywhere Docker runs—including any third-party Kubernetes. The entitlement is included as part of all the standard WebSphere Application Server purchase options.
The full Cloud Pak, which also includes the Helm chart, is supported only when these entitled customers run on IBM Cloud Private or IBM Cloud Kubernetes Service.
Our clients tell us SAP applications are central to their success and strategy for cloud, with a deadline to refresh the business processes and move to SAP S/4HANA by 2025. Now is the time to assess, plan and execute the journey to cloud and SAP S/4HANA