Technically, containers simplify development and operations by building all dependencies and the application itself in a single immutable image. They eliminate the “it works on my machine” excuse. An Immutable binary of the product code provides the following advantages:
- can create multiple homogeneous environments from the same product code
- upgrading that single product binary results in all systems getting the latest version or fixes
Several Business Automation Workflow (BAW) on-premise customers are interested in these benefits that come from containers but are not ready to move their BAW workload to Kubernetes. This article describes how to build a BAW VM image that can address the basic requirements when the customer is considering setting up a VM environment on the cloud, given the following assumptions:
- The use of VM from a cloud provider has been decided.
- The centralized IT team want to control OS and basic software refreshes to address Common Vulnerabilities and Exposures (CVE) by providing a base VM image. Regular refreshes are typical; for example, a new base VM image is released monthly; and the application (BAW) team must create a new application VM image based on that.
- The VM instance must be rebuilt regularly even without an image update for security hardening purposes.
Compared with using a container via Kubernetes, the VM instance itself still needs additional resource consumption at the OS level and cannot be easily scaled, but it has the following unique values:
- No additional learning curve for container and Kubernetes.
- No additional resource consumption for Kubernetes.
- No need to upgrade process applications to be container compatible.
Core ideas of how to decouple
This idea is based on WAS swinging profiles and BAW swinging profiles, which move the profiles to a new location away from the WebSphere Application Server (WAS) installation root. As result, you can install BAW on two disks:
- Binary disk – install Workflow/WAS/IHS binary on this disk. The whole disk can be replaced with a new VM image for “upgrading” to the next level.
- Profile disk – contains customized configuration/transaction log/key store. This disk is kept when you replace the binary disk. Setting up the profile (and other data) on a separate disk decouples it from the lifecycle of the machine/VM.