Migration and Modernization – WebSphere Liberty

Migration and Modernization -

WebSphere Liberty
Introduction/Overview

Introduction/Overview
Introduction/Overview: What, Why and IBM Strategy Alignment

 What?
• Migrate traditional WAS to Liberty

 Why?
• Align with IBM product strategy
• Benefits of Liberty and cloud native

 IBM Strategy Alignment

• IBM Traditional WAS strategy

• tWAS 8.5.5 and 9.0.5 support through 2030 but limited to IBM WebSphere Java 1.8
• Liberty is a strategic product, has been available for some time & supports industry-standard Java 11
WebSphere Traditional standard support 2030
Stability & Longevity for Existing Workloads

Stay the course on key priorities From 8.5.5 to 9.0.5

Standard Support Extended Support

Version Release Date
(with IBM JDK 8) (with IBM JDK 8)

WAS 8.5.5 2012 2030 2033

WAS 9.0.5 2017 2030 2033

IBM will provide standard support for WebSphere Application Server versions 8.5.5 and 9.0.5, with IBM JDK 8,
through at least 2030. For WAS 8.5.5 and WAS 9.0.5 - WAS ND, WAS (Base) and WAS Family Edition.
Concerns About Ramp Up and Adoption
 Concerns About Ramp Up and Adoption

 Technical details shown in this presentation are to show some of the underlying mechanisms

 OpenShift Administrators will need more in-depth knowledge (Administration is not covered in this deck)

 Do developers have to go through a big learning curve and ramp up on Docker, OpenShift, etc?
• See slides for deployment and config mgmt using docker and OpenShift, automation insulates developers

• Eventually, they'll need to ramp up, but they can be immediately productive on a team b/c of the automation

• Adoption pays off: workflow is arguably easier and better (e.g. faster turn-around for debugging) than traditional workflows

 Migration from WebSphere to Liberty - Hard part is automated by TA

• I don't need to be an SME and spend lots of time figuring out code compatibility issues and determining the fixes

• TA's knowledge base (tWAS  Liberty issues + fixes) regularly updated with what SMEs find on each of IBM's migration engagements
WAS Family + Why Choose Liberty - Benefits of Liberty and Cloud-Native

WAS Family + Why Choose Liberty -

Benefits of Liberty and Cloud-Native
Why Choose Liberty
 Why Choose Liberty - Benefits of Liberty and Cloud-Native
 Liberty optimized for Cloud native
Add CI/CD Pipeline automation: developers focus solely on
• 25% Improvement in developer productivity
• Container and Cloud Native experience, Rapid Inner Loop their application; no need to write and use commands for
• Faster debugging and RCA via cloud native cycle Dockerfiles and OpenShift artifacts for deployment

 Optimized vs other runtimes used for cloud native

• Startup & response time and throughput better than Tomcat
• 4x increased density over Tomcat & Spring Boot

 App runtime, scaling, & load balancing independent from other apps

 Secure images and support from IBM

You can migrate your monolith to Liberty and later decide to
 Supports monoliths, microservices, and in between refactor to Microservices: no need to switch app/web servers for
• Right-sized images: kernel image + just features the app needs Monolith to Microservices. Liberty's composable app server lets
you then put in just the needed runtime.
 Zero Migration
• 100% backward version compatible
• Feature versions can stay the same
The Total Economic Impact Of WebSphere Liberty

 Developer Tools integration, Cloud Native workflow, Zero

Migration, Composable Runtime, Runtime independence
from other applications

 $500,000 in developer time spent on migration efforts.

 better throughput than other Java EE
 Save 1.2 administrator FTEs
 $3.75 million in incremental revenue per year due to app
availability, performance, and innovation improvements
 No cost for Open Liberty (development); pay only for
WebSphere Liberty license & support in production
 Smaller footprint reduces infrastructure costs
WebSphere Family of Products

WAS Product Family:

• WebSphere ND: WebSphere Base + Clustering
• WebSphere Base: Full WAS features w/o Clustering
• 2 Profiles: WAS Profile & Liberty Profile
• Liberty Core: subset of Liberty Profile Base: just web profile features
• Open Liberty

Liberty
• Deployed in Container (via Liberty Image) or on VMs / Bare Metal
• Different server than WAS Profile
• IBM's strategic direction
• Composable via adding features in server.xml
• For container deploy, image is either 'full' or 'kernel' & add features to kernel to achieve
'Liberty Base', etc.
WebSphere Family of Products - Packaging, Licensing
 Packaging/Licensing
• WebSphere Hybrid Edition
• Suite of WAS Family Products + tools
• CP4A is no longer sold (replaced by WHE)
but it's supported

 IMPORTANT: Deploying Liberty in a

container involves using a Liberty
Container Image
• No separate 'installation' of WebSphere
Liberty in a container; its image is added
to application image that you create

 Flexible Licensing Option

WebSphere Hybrid Edition
 WebSphere Runtimes
Support current and future runtime needs

Liberty
traditional WebSphere
Cloud-Native
Stability
Containers/Kubernetes
O/S, Database Currency Modernization
Lightweight/Efficient
Security Currency
Latest Technologies
Java 8 support till at least 2030

© 2021 IBM Corporation

11
WebSphere Liberty – CI/CD Optimized - Zero Migration & Continuous Delivery

No configuration behavior changes Stay current with a rebuild

(no app or config changes necessary)

No runtime feature behavior changes

Skipping a release does not introduce
additional migration work
No removals

Effortlessly eliminate technical debt and

Full release every 4 weeks stay secure
App Modernization

 Modernization goals and benefits

 Overview of app modernization tools

 Demo
Modernization Goals and Benefits

Modernization Goals and

Benefits
What is driving modernization ?

Clients can’t Application

Application
develop architecture
is expensive
features at the is hindering
to maintain
pace business ability to add
and extend
requires functionality

15
 Modernization Benefits
Architectural Runtime Operational
Modernization Modernization Modernization

Align Application Align Application Adopt on-demand compute

Delivery to business Development to modern and immutable
change dynamics Java standards infrastructure

Increased Agility Right-sized runtime Easier automation

Rapid Innovation Reduced tech debt Increased density
Leverage new capabilities

16
Modernizing Java Application Estate
Progressive modernization

Application
Estate

Traditional
Traditional WebSphere Liberty
Application ‘base’
Server
in VMs
Containers VMs/Containers Containers

Modernize Modernize Modernize

Monolith
Operations Runtime Architecture

Transformation Advisor ?
✅ ?
✅ ?
Modernizatio
n Tools App Migration Toolkit ✅ ✅

Mono2Micro ?
✅
Modernization Tools

18
App Modernization Tools
accelerate the planning, sizing and execution of the modernization journey

• Cost/complexity of cloud- • Generates migration

Operational Modernization enabling the application artifacts to assist with build,
deploy, operation in Cloud
• Interdependencies with other
apps and services • Based on cloud native best
practices
Transformation
Runtime Advisor
Modernization
WebSphere Application
Migration Toolkit

How an application can be:

• Decomposed along • Generates code enabling

Architectural Modernization responsibility boundaries communication between
and/or Liberty microservices
IBM • Refactored into a set of
Mono2Micro microservices
19
(Migration) IBM Cloud Transformation Advisor

(Migration) IBM Cloud

Transformation Advisor
Why Choose IBM Transformation Advisor
 Lowering costs – Reducing development and
management cost
 Transform and innovate
 Agile delivery
 Improving developer productivity. Adopting cloud-
native and containerization technology enables self-
service for developers.
 Improving operational efficiency and
standardization. Drives a culture of automation and
transformation of operations.
 Accelerating digital transformation - build
capabilities and deliver them quickly.
 Assessment - Evaluates applications based on business needs.
Provides a migration complexity
 Strategic planning –
• Identifies key applications that require replacement or upgrade
• Estimates effort for resolving migration issues
1. TA finds each migration issue (e.g. code change,
compatibility issues) and the fix required.
2. Determining code changes and each specific change
needed are time consuming and require SMEs. TA do this
automatically.
1. TA generates the java project structure and identifies all the
app's dependencies including the somewhat time-
consuming determination of WebSphere shared libraries
used by the app.
2. TA generated the server.xml, dockerfile to build our app
image, Custom Resource Definition file used by the Liberty
Operator to deploy the application and automatically
manage its lifecycle
3. Add CI/CD Pipeline automation: developers focus solely on
their application; no need to write and use commands for
Dockerfiles and OpenShift artifacts for deployment
IBM Cloud Transformation Advisor
Accelerates the enterprise-wide modernization journey through identification of common Workloads:
code and modernization costs. Quickly discovers and analyzes on-premise Java EE
and/or integration workloads to help determine and execute the optimum modernization
steps for each. Leverages practitioner expertise to provide developer cost estimation,
recommendations, detailed reports, and configuration and deployment artifacts.
Java EE
⎼ WebSphere
Containers, Java EE, monoliths & microservices…
Application Server
⎼ Oracle WebLogic

Traditional ⎼ Red Hat JBoss

Traditional
WebSphere Liberty
WebSphere ⎼ Apache Tomcat
‘base’
network
deployment
VM/Docker/K8s VM/Docker/K8s VM/Docker/K8s

Monolith
Modernize Modernize Modernize Integration
Operations Runtime Architecture
⎼ App Connect
Enterprise (IIB)
Optimum modernization depends on workload needs!
http://ibm.biz/cloudta 22
How IBM Cloud Transformation Advisor works
RHOCP or Desktop
1. Install Transformation Advisor from the IBM Catalogue
Transformation on RHOCP, or use TA Local on your desktop and access
Advisor
the UI from your browser.
Migration 2. Download and run the Data Collector (or the
Artifacts
latest Binary Scanner) on your on-premise servers,
where your applications are already deployed.
Liberty Container
3. Data Collector sends results back to TA or are uploaded
through the browser.
On-premise 4. Transformation Advisor’s analysis provides
TA Data app-specific insights, guidance and developer effort
Collector
sizings based on practitioners’ experience to move your
application to the cloud.
5. Use the customized migration artifacts created by TA
allow you to easily configure the runtime, containerize and
deploy the application.
IBM Transformation Advisor (TA) includes

Containerized runtime target analyses Holistic views of related components

(Liberty, WebSphere Base, ACE)
• Dependency mappings
• Modernization complexity assessment (shared libs, middleware relationships)

• Issue identification and severities • Cumulative issue summary and

resolution costs
• Resolution cost assessments

Detailed Reports Application-specific customized migration plans and

deployment artifacts
• Issue identification and remediation
• Configuration for containerized runtime
• Workload inventories
• Build and deployment files
• Dependency identification
 Transformation Advisor – Complexity Assessment

Simple:
No code changes
required

Moderate:
Some
well-understood
remediation needed

Complex:
May need to rearchitect
or continue as-is

25
Distribution of 3800+ customer applications

16%
83%
1%
Simple Moderate Complex

26
Application Dev Cost

+
700
Applied Results in

against a list of
Application issues

Expertise gained in
modernization services
engagements

Application’s
Dev cost to Dev cost to Dev cost to Dev cost to
Dev Cost
remediate remediate remediate remediate
issue 1 issue 2 issue 3 issue X

27
Individual Application Recommendations

28
TA’s Enterprise-wide Modernization View

Customer-configured common code:

JAR files from shared libraries
App3 App4
TA also dynamically discovers common code: App 5
JAR files included in multiple applications App2
App6
(identified by a combination of
name and checksum) App1

Jar2 Jar3

Jar4
➤ Remediating common code in a JAR one time Jar1
speeds modernization of all applications
that depend on it

➤. Developer effort to remediate common issues

Issue1 Issue2 Issue3 Issue4
will be significantly less than it might
appear when looking at apps one-by-one
Enterprise-Wide Workspace View
Enterprise-wide Development cost:
Common code is identified for enterprise-
wide planning
Cluster-aware Migration
• Low-cost, low risk first step to operational and runtime modernization
• Familiar topology, modern runtime, modern platform
• Accelerates cloud-native adoption, reduces skills gap
Kubernetes
KubernetesCluster
Cluster

IBM HTTP Server Route / Ingress

dmgr WebSphere plugin
Operator
Service
manages
load-balances Transformation Advisor
load-balances manages
Cluster
tWAS Cluster
Pod
Pod
tWAS cluster tWAS cluster
Pod
Container
member member
Pod
Container
App A App B App A App B Container
Liberty
Container
Generated artefacts:
• Co-location aware Dockerfile & server.xml App A Liberty
App B
tWAS cluster tWAS cluster • Replica aware Custom Resource Liberty
member member Liberty
App A App B App A App B

Futures: customizable Custom Resource, secrets migration

WebSphere Application
Migration Toolkit
WebSphere Application Migration Toolkit

http://ibm.biz/wamtdownloads 33
 WebSphere Migration Toolkit - Binary Scanner
– Commandline tool that can be incorporated
smoothly into DevOps Pipeline

– Customization through command line

arguments or scanner.properties file

– Binary analysis

– WebSphere, WebLogic, JBoss, and

Tomcat to Liberty

– Java SE and WebSphere v-to-v

– WebLogic, JBoss,
Tomcat to Liberty

– WebSphere
version-to-version – Core analysis within Transformation Advisor data collector

– Can now create Transformation Advisor data collection zips in

WebSphere environments
34
 WebSphere Migration Toolkit - Source Scanner
Confidently apply remediations recommended by binary analysis and Transformation Advisor

• Eclipse IDE plugin

(Eclipse, WDT, RAD)
• Executes source code
analysis and provides
developer assistance
with remediations
• WebSphere to
Liberty
• Java SE
• WebLogic, JBoss,
Tomcat to Liberty
• WebSphere
version-to-version

35
Migration from WebSphere to Liberty in OpenShift And Developer 'Cloud Native' Workflow

Migration from WebSphere to

Liberty in OpenShift And Developer
'Cloud Native' Workflow
Migration Application Analysis for Migration Decision

• Changes needed
Migration Decision: • Time estimate for
Automated analysis IBM Transformation changes
App on tWAS • Compatible
of app for migration Advisor (TA)
runtimes
decision IBM Knowledge
Base (TA)
Decision Tree
Liberty Benefits

TA fully automates the analysis of the application for migration

estimation of the migration; without TA, it would be time-
consuming and require SMEs
Migration Application Analysis for Migration Code Changes (if needed)

Each required code change

and the specific fix needed
are identified by both TA and
Migration: Identify MT
any code migration
IBM Transformation /
changes, determine Advisor (TA)
fixes, make changes
App on tWAS IBM Knowledge
Base (TA)
IBM WebSphere
Liberty IDE Plugin for
Migration Toolkit (MT) IBM WebSphere immediate testing of changes
Migration Toolkit (MT) made for Liberty migration

Note: IBM WebSphere Migration Toolkit (MT) is for Eclipse. If you're using another
IDE, just keep Transformation Advisor (same analysis) open next to your IDE

Without TA or MT, determining code changes and each specific change needed are time consuming and
require SMEs. TA and MT do this automatically.

TA's Knowledge Base is regularly updated with what SMEs find on each of IBM's migration engagements

If your app doesn't use any tWAS-only features, then no changes will be needed
Application Migration - Determine target runtime compatibility issues and find fixes for each issue
 Application Migration - Determine target runtime compatibility issues and find fixes for each issue
 Transformation Advisor and WebSphere Migration Toolkit automate this

• Transformation Advisor's Binary

scanner finds each migration issue
(e.g. code change) and the fix
required
• This would take a LONG time and
require subject matter expertise

• WebSphere to Liberty
WebSphere Migration Toolkit (MT)
is integrated into Eclipse to make • WebLogic, JBoss,
this easier Tomcat to Liberty
• WebSphere
version-to-version

Note: IBM WebSphere Migration Toolkit (MT) is for Eclipse. If you're using another IDE, just keep
Transformation Advisor (same analysis) open next to your IDE
Application Migration - Generate Java project w/ dependencies, Create Containerization Artifacts
 Application Migration - Generate Java project w/ dependencies, Create Containerization Artifacts
 Transformation Advisor generates these artifacts for us

TA generates the java project

• Create target java project
structure and identify java
dependencies
• Note: we manually add
the dependencies to the
maven pom.xml, but the
needed dependencies
are identified by TA
structure and identifies all the app's
dependencies including the
somewhat time-consuming
determination of WebSphere
shared libraries used by the app

• Create right-sized docker image

by adding application's needed
technologies and searching for
image
• Create artifact(s) to deploy to
OpenShift
• Create container, deploy to
OpenShift and manage app
lifecycle in OpenShift
- TA scanned the app for the
technologies it uses and generated
server.xml to have just the needed jars
added to the image (this is non trivial)
- TA generated the dockerfile to build
our app image which includes TA
including the correct target base image
- TA generated the Custom Resource
Definition file used by the Liberty
Operator to deploy the application and
automatically manage its lifecycle
Migration (and Developer 'Cloud Native' Workflow) - Determine App's Liberty features, build dependencies, deploy to OpenShift

 TA analyzes app and This flow is for both the initial migration and
Liberty for ongoing developer build / test / deploy
generates the app's features
Developers do NOT have to know what workflows
required Liberty needed by app
features features to add for their 'just what's needed'
Liberty server. Nor do they need to know
anything about creating this file.

server.xml
IBM Transformation
Advisor (TA)
App's maven
 TA analyzes build; build
app and dependencies
provides all of pom.xml is standard maven, but
the app's adding the correct build
dependencies : dependencies (jar files) is needed.
(shared tWAS
pom.xml
libs and other
jars used by
the app /
- App build properties: for ci/cd template-driven build/deploy automation; insulates developers from
knowing any of the build, openshift, etc. commands and mechanisms.
Build Runtime - App runtime env properties that will change (independent of any mechanism such as ConfigMaps)
props env props

Template-
driven CI/CD
Developer Pipeline
Emphasis: Developers Insulated from Containerization and Other Mechanisms For deployment and config management

 Emphasis: Developers Insulated from Containerization and Other Mechanisms For deployment and config management

 These 5 artifacts represent what the developer needs to provide

 Notice that there are no Dockerfiles, OpenShift artifacts, no docker or OpenShift commands, etc.
server.xml • Developers do not need to know this for deployment and ACM. It will be fully automated.
• Eventually, they'll need to ramp up, but they can be immediately productive on a team for the
main app activities of Deployment, Load Balancing, Scaling and Config Management
• Developer focuses on app; OpenShift, Docker, etc handled by pipeline

pom.xml  Even the server.xml is automatically generated

/
Application

Build When we get beyond Deployment, Load

props These are just simple property name/value pairs Balancing, Scaling and Config Management,
setting property values for OpenShift will involve
The mechanisms (Templates for Dockerfile and either using OpenShift resource files directly (and
Runtime OpenShift, ConfigMaps, etc.) that these are used in the commands), OpenShift Operator resource
env props are insulated from dev team files, or trying to abstract it away. Using the
resource files of the OpenShift Resources or
Operators may be arguably better/easier
Who Maintains What - Traditional vs Cloud-Native Deployment

(If cloud is
used)

CI/CD Pipeline Dev

automates
much of this !
Ops
CI/CD Automation for OpenShift Deployment

CI/CD Automation for

OpenShift Deployment
TA Generates Dockerfile and OpenShift Resource Artifact
TA generates:
• Dockerfile with all of the commands needed by docker to build the application's container image using Liberty base image (kernel) + features.xml
• Resource file for Open Liberty Operator that will create needed OpenShift resources (Deployment, Service, Route)

These can be used as-is, but require knowledge of some commands for docker & OpenShift (& how to add additional config to Operator's YAML Resource file

Instead, app teams don't need these; these will be used once for guiding creation of the Templates used to generate Dockerfile, OCP Deployment and OCP
Service resource files via the CI/CD Pipeline

Commands to build app
image using Liberty base
image (kernel) + features.xml
IBM Transformation
Advisor (TA)
Resource file for Open
Liberty Operator
T
Use the TA-generated Dockerfile as a guide when
creating the Dockerfile template (with properties
that will be replaced during the CI/CD Pipeline run
with app-specific build values)
T T
Use the TA-generated Resource File as a guide when
creating the OpenShift Resource file Templates (with
properties that will be replaced during the CI/CD Pipeline
run with app-specific build values)
Template-
driven CI/CD
Pipeline
CI/CD Automation Pipeline for Deploying to OpenShift - Slide 1 of 2

Developer commits all

files into their App's git
repo Commit to
+ + + +
remote git repo These are not needed when using the
Application Configurations Tool

Dev runs the pipeline (or, when available, uses the Application Configurations Tool )

Jenkins Pipeline is run for app, passing in:

Jenkins Pipeline
• Parameter to tell Pipeline script to build / deploy
Run for App
• specific property values to have app deploy to specific
Jenkins Pipeline for specific App but it
openshift cluster and namespace Pipeline uses the generic pipeline script Shared Library
• Specific runtime property values (eg db url) for App
Templates

Image registry
Automation of Docker and OpenShift:
• Image built and loaded into registry   OpenShift 
• App deployed in OpenShift (Deployment, PODs, Service, Route)
• ConfigMap in OpenShift App (image)

 Pipeline will automate Developers don't need to know the OpenShift mechanisms for
setting up autoscaling for + Autoscaling. Instead, they'll provide property values for
the app metric thresholds and # of app instances
CI/CD Automation Pipeline for Deploying to OpenShift - Slide 2 of 2

(1) Create App

Pipeline Tools Create App git
Application
Configurations repo
- App info
Tool UI - Company Git URL
Create Jenkins Jenkins Pipeline
- Info specific for app for
Application  Pipeline for App for App
generic pipeline script
- Company Jenkins URL Configurations Shared Library
Tool

(2) Set runtime env props +

OpenShift cluster targets Build info: Runtime env:
Application - App info UAT:
Configurations - Company Git URL - OCP URL/Namespace
UAT:
Tool UI - OCP URL/Namespace - Company Jenkins URL - db URL=<value>
- db URL=<value> - Info specific for app for PROD:
PROD: Application  generic pipeline script - ...
- ... Configurations Tool

Run Pipeline Jenkins Pipeline

(3) Run Pipeline
for App
(Build, Deploy, etc.) • Build / Deploy parm
Application for which part of
Configurations Shared Library
Build / Deploy parm for which Pipeline scrpt to run
Tool UI part of Pipeline scrpt to run (build, deploy,
(build, deploy, acceptance Application
 acceptance test, etc.)
test, etc.) • App, Build, runtime
Configurations Tool env data needed
CI/CD Pipeline and Toolchain for optimized developer experience
• Represents different tools you can use
• Ultimately, you want to try and automate as much as possible as shown but start off small

Inner Loop Outer Loop

Compliance Gate

AGILE Security
Code Requirement
Cloud Workbench Delivery Generation
Self Service Portal
Curated Authoring Write Local Test Code
AD group Build
IAM roles
Base Environment Code and Debug Continuous Code Unit Vulnerability Push to
Images Quality Docker
Ref. Architecture Integration Build Test Scan Repo
Scan Container
Target Environment Docker
Platform Type Code
CodeRepo
Repo
Image Repo
Microservices
CI/CD Pipeline
DEV Pipeline

Approve & Version

IDE with Java EE & Use industry- Local unit CI prod is SCM for Build Certified
Pipeline Control/ Run unit tests Run static code Multi-stage Security
Scan MicroProfile LSP & standard tests before code changes and Java Version
configuration Code and coverage analysis docker build compliance
Images Git integration frameworks code commit triggers the pipeline App artifact
review

Approval Gate Approval Gate

Configuration
Management
Playbook

Enterprise QoS Auto Report Performance Functional Auto Integration Deploy Continuous Deployment
Deploy Deploy
Change Compliance Test Test Container Change Test in Container
Container Cluster
Record Evidence Record
Continuous Release

Security and
Compliance
Center
MZRs

Create QA Package certified image and

QA/Prod

Local unit
Pipeline

Day 2 Deploy to Create PROD Report “facts” Performance Functional Deploy to Deploy to
change tests before Dev deploy to controlled
Operations PROD change ticket for audits Test Test QA
ticket code commit environments
Additional Details - CI/CD Automation Pipeline for Deploying to OpenShift - Slide 1 of 2

Build Runtime /
props env props
Application
pom.xml server.xml

(1) Get Application

from git

Build Runtime
(2) Use app's build props env props
app-specific (template prop vals repaced)
and env props to
create app-specific
containerization T T T Generate app's
containerization
artifacts from artifacts from
templates templates

Liberty Operator can still

be used b/c of Operator
benefits; its resource def
(3) Build app's for app deploy, load bal,
java artifact (EAR, / + EAR, WAR,
or JAR
scaling & config mgmt. in
WAR, JAR)) Application OpenShift will still be
pom.xml abstracted to insulate dev
team for this phase
Additional Details - CI/CD Automation Pipeline for Deploying to OpenShift - Slide 2 of 2

Build
(4) Build app's props Image registry
image and push it
to a registry + + EAR, WAR,
or JAR
Docker / OCI
Image for app
Route App (image)
server.xml App (image)

(5) Deploy app

Build
to OpenShift Runtime Runtime
props
env props prop vals
oc CLI
Liberty Operator can still (set prop vals as env vrbles in
be used b/c of Operator container)
benefits; its resource def Image registry
for app deploy, load bal,
scaling & config mgmt. in Autoscale POD uses docker
OpenShift will still be (metrics) to pull image &
abstracted to insulate dev App (image)
create container
team for this phase app-specific (template prop vals repaced)

Note: Docker is used to refer to the container engine. In reality, it's any OCI-compliant container engine. Note that both Kubernetes and OpenShift
have switched to using CRI-O instead of docker in their installation. Images created with docker CLI are fully compatible with CRI-O.
Additional Details

Additional Details
Application Migration Planning

Application Migration
Planning Example
Application Migration Planning

App Owners - Develop a Wave Formula

Consider these factors
 Create Application Rating System • Identify Candidates for “Decommissing” - save
1. Least Complex  to Most Complex yourself some work
2. Least Critical  to Most Critical • Enhance the Application Features
 Separate Tracks • Correct Flaws
1. Validated VS. Non-Validated • Port “As-Is” doing only what is required for
2. Custom Built VS. Vendor Application migration
 Factor In
1. Core Technology Requirements (JSF, EJBs, JSP, Servlets, JAX-WS, Spring, Hibernate, etc…)
2. Dependencies - Applications that Must Migrate together
3. Business Benefit (Application Enhancements Requested)
4. Group into Tier3, Tier2 and Tier1 Type Applications
• Expectations
1. Many Applications will be easy (little or no changes)
2. Some Applications will be difficult (moderate to large amount of changes)
3. Some will be in-between
Application Migration Planning – Rank Your Application

“Hypothetical” Ranking – Developing a Formula

Complexity Mission Critical

Low (1) Medium (3) High (5) Low (1) Medium (5) High (10) Total Score
1 1 2
3 1 4
1 5 6
5 1 6
3 5 8
5 5 10
1 10 11
3 10 13
5 10 15

Mission
Complexity Critical

Total JSF Servlet JAX WS Overall

Low Med High Low Med High Score Used? EJB Used? JSP Used? Used? Used? Total Score Score
App A 1 1 2 1 1 2 4
App B 3 1 4 3 3 7
App C 1 5 6 3 3 9
App D 5 1 6 1 3 4 10
App E 3 5 8 3 1 3 7 15
App F 5 5 10 3 3 3 9 19
 Traditional App Server vs Liberty
With a Traditional App Server, the Full Java EE API stack With Liberty, you control which features are loaded
as well as administration and operations features are into each server instance
loaded in each server instance

<feature>jsf-2.3</feature>
<feature>servlet-4.0</feature>

jsp-2.3 jsf-2.3
Java EE
servlet-4.0

http-2.0 appmgr
Kernel
55
 21.0.0.3
Liberty – The open composable Enterprise Java Runtime
batchSMFLogging-1.0 zosLocalAdapters-1.0 zosTransaction-1.0

zosRequestLogging-1.0 zosWlm-1.0 zosSecurity-1.0

collectiveController-1.0 dynamicRouting-1.0 healthManager-1.0 scalingController-1.0 zOS

clusterMember-1.0 healthAnalyzer-1.0 scalingMember-1.0
Security ND
cloudant-1.0 heritageAPIs-1.0 batchManagement-1.0

javaee-7.0 sipServlet-1.1 wsAtomicTransaction-1.2 Operations passwordUtilities-1.0 Base

javaee-8.0 wsSecurity-1.1
Core
jakartaee-8.0 wsSecuritySaml-1.0

bells-1.0 microProfile-4.0 adminCenter-1.0 acmeCA-1.0 audit-1.0

Open
concurrent-1.0 mpContextPropagation-1.0 collectiveMember-1.0 constrainedDelegation-1.0 ldapRegistry-3.0 Liberty
grpc-1.0 mpGraphQL-1.0 distributedMap-1.0 federatedRepository-1.0 oauth-2.0

javaMail-1.6 mpReactiveMessaging-1.0 eventLogging-1.0 jwt-1.0 openid-2.0

jaxb-2.2 mpReactiveStreams-1.0 logstashCollector-1.0 jwtSso-1.0 openidConnectClient-1.0

jdbc-4.3 opentracing-1.3 monitor-1.0 sessionDatabase-1.0 openidConnectServer-1.0

jpaContainer-2.2 osgiConsole-1.0 openapi-3.1 webCache-1.0 samlWeb-2.0

jsfContainer-2.3 springBoot-2.0 requestTiming-1.0 scim-1.0

json-1.0 webProfile-7.0 usageMetering-1.0 socialLogin-1.0

jsonbContainer-1.0 webProfile-8.0 restConnector-2.0 spnego-1.0

jsonpContainer-1.1 APIs sessionCache-1.0 transportSecurity-1.0

56
Simple config Simple to version control for DevOps

<server>
<featureManager>
<feature>jsp-2.3</feature>
</featureManager>

<httpEndpoint id=“defaultHttpEndpoint” host=“my.host”

httpPort=“8080” httpsPort=“8090”/>

<applicationManager autoExpand="true"/>
</server>
server.xml

https://openliberty.io/docs/latest/reference/config/server-configuration-overview.html
57
Customizable <server>
<featureManager>
<feature>jsp-2.3</feature>
</featureManager>

<httpEndpoint id=“defaultHttpEndpoint” host=“my.host”

httpPort=“8080” httpsPort=“8090”/>

<applicationManager autoExpand="true"/>
er </server>
server.xml
rd
O
ng
si

com.ibm.ws.logging.console.log.level=AUDIT
es

Configure bootstrap of server

oc
Pr

bootstrap.properties

-Xmx1g
-Dsystem.prop=value Configure JVM
jvm.options

JAVA_HOME=/opt/ibm/java
WLP_OUTOUT_DIR=/usr/wlp-out/ Configure server script
server.env
https://openliberty.io/docs/latest/reference/config/server-configuration-overview.html 58
Overridable
• ‘configDropins/overrides’ allows overriding of existing server configuration
• Use it to override development configuration with production configuration

Deployment Overrides ${wlp.install.dir}/usr/servers/<server_name>/configDropins/overrides/

overrides

Main Server Config ${wlp.install.dir}/usr/servers/<server_name>/server.xml

overrides

Company Defaults ${wlp.install.dir}/usr/servers/<server_name>/configDropins/default/

overrides

server/feature defaults

59
 Templatizable & Sharable
<server>
<httpEndpoint id=“defaultHttpEndpoint” host=“${host}”
httpPort=“${http}”
httpsPort=“${https}”/>
</server>

common-http.xml

<server>
<include location=“common-http.xml”/>
<include location="https://myHost/ports.xml”/>
<variable name=“host” value=“${my.host}”/>
<variable name=“http” value=“${my.host.http}”/>
<variable name=“https” value=“${my.host.https}”/>
</server>
server.xml

60
Dynamic
• Applications monitored for updates
• dropins folder for simple install of apps
• Configuration files monitored for updates
• configDropins overrides and defaults for config composition

Add <application/> Add

<feature>jdbc-4.0</feature>
<dataSource/>

running server

Add <library/> Modify

<dataSource>
<properties/>
</dataSource>

61
Container friendly
Kubernetes ConfigMaps and Secrets can be mapped to:
• Environment variables
• Files – e.g. bootstrap.properties, configDropins/overrides/prod.xml (e.g. role bindings)

configDrops/overrides/
prod.xml
prod.xml
Secret
Environment variables
db-name db-name
db-user db-user
db-pwd db-pwd
Secret Container

Kubernetes

62
 Build and DevOps

maven
<plugin>
<groupId>io.openliberty.tools</groupId>
<artifactId>liberty-maven-plugin</artifactId>
<version>3.2</version>
</plugin>

Automtically mirror release

install only build
required features

Internal Repository
gradle
dependencies {
classpath 'io.openliberty.tools:liberty-gradle-plugin:3.0’
}

63
 Containers and DevOps
FROM icr.io/appcafe/websphere-liberty:kernel-slim-java11-openj9-ubi
FROM docker.io/ibmcom/websphere-liberty:kernel-slim-java11-openj9-ubi

Docker Hub
(docker.io)
Automatically
mirror
install only release
required features build

Internal Registry

FROM icr.io/appcafe/open-liberty:kernel-slim-java11-openj9-ubi IBM Cloud Container

Registry (icr.io)
FROM docker.io/openliberty/open-liberty:kernel-slim-java11-openj9-ubi

64
 Liberty in Containers
IBM Cloud Kubernetes Service
app and config Azure Kubernetes Service
+ Hosted
Google Kubernetes Engine
Cloud
Amazon Elastic Kubernetes Service
liberty and java =
+
os config portable Red Hat Open Shift Container Platform
+ container
Private
Cloud Pivotal Kubernetes Service

docker Pivotal Cloud Foundry

FROM open-liberty
ADD myapp.war /config/dropins/myapp.war
65
Open Liberty & traditional WAS security
Feature / Capability
Minimal ports opened
Federated user registries
OAuth, OpenID Connect Client
OpenID Connect Provider
LTPA
SPNEGO tokens
SAML Web SSO
JSON Web Tokens (JWTs)
User and group API
Auditing
Certificate management built-in
Java EE 8 / Jakarta EE Security 1.0
Multi-realm support
Liberty traditional WAS
✔ ✘
✔ ✔
✔ ✔
✔ ✘
✔ ✔
✔ ✔
✔ ✔
✔ ✔
✔ w/ SCIM ✔ w/VMM
✔ ✔
✔ w/ ACME Let’s Encrypt ✔
✔ ✘
✔ w/ Collectives, 1 realm per server ✔
66
Open Liberty & traditional WAS security (2)
Feature / Capability Liberty traditional WAS
Local OS registry ✔ z/OS SAF only ✔
Kerberos native support ✔ w/ SPNEGO only ✔
Kerberos for database connections ✔ ✔
Fine-grained roles Admin/Reader ✔
Kerberos for LDAP connections ✔ ✔
TLS 1.3 support ✔ ✔ w/ IBM JDK 8
MicroProfile JWT (mpJWT 1.2) ✔ ✘
Jakarta EE 9 Security 2.0 Beta (21.0.0.3) ✘
LetsEncrypt (ACME CA) support ✔ ✘
JWE (JSON Web Encryption for JWTs) ✔ w/ mpJWT 1.2 No (pending)
DISA Security Technical Impl Guide (STIG) Pending ✔
OpenShift OAuth Token support ✔ ✘
OpenShift Operator security integration ✔ ✘

67
Certified Liberty images

• Available on IBM Container Registry and Docker Hub

2 tags: kernel-slim/kernel & full

IBM Semeru IBM Semeru

Runtimes Runtimes

IBM Semeru
Runtimes

68
Certified traditional WAS base image

Operational Modernization

Base

Runtime Modernization

ND Liberty

• A stepping stone for applications that can’t yet migrate to Liberty

• A way to deploy & manage legacy applications consistently until it is replaced by cloud-native apps 69
Consistent enterprise images

Config
Dockerfile
Certified image libs

FROM open-liberty OCI Container image

RUN yum …
COPY libs /config/libraries/ Image:
config app
COPY server.xml /config/configDropins/defaults/
libraries
runtime framework
runtime language

Enterprise base image

UBI (RHEL)

Consistency across the enterprise Improves performance w/ layer caching

70
Open Liberty Operator

71
Embracing Operators
• Extends Kubernetes functionality
• Makes use of Custom Resource Definitions (CRDs)
• Holds the knowledge of how an application needs to be packaged, deployed and managed

72
Without an Operator

Deployment StatefulSet Auto Scaling Route

• Inconsistency across the enterprise and GitOps

Service Pod Job Ingress

Persistent
Namespace ConfigMap Secret
Volume Claim

Service Binding
Application Service Monitor Certificate
Request

Knative Knative Knative Service Knative Route

Configuration Revision

73
With an Operator

• Enables:
auto-synchronization of runtime resources
OpenLibertyApplication
• Improves:
usage, maintenance, consistency

74
 Input: Application image or ImageStream

BuildConfig
S2I
buildah
CNB
Multi-stage
Application code Application Image or ImageStream
…
Runtime + App

CI/CD (Tekton / Jenkins / etc)

75
Open Liberty Operator

Open Liberty Operator

app-deploy.yaml

76
Open Liberty Operator
OperatorHub: Maturity level 5

https://github.com/OpenLiberty/open-liberty-operator
https://operatorhub.io/operator/open-liberty

Current features Future

•Creation & deployment of k8s resources
•Toggle to create Knative / Serverless resources
•Horizontal auto-scaling
•Resource constraints
•Built-in monitoring integration (ServiceMonitor)
•Integration with Certificate Manager
•Auto-creation of Routes or Ingress w/ TLS
•Custom microservice TLS trust
•Readiness / liveness probes
•Simplified persistent storage setup
•Environment variables setup
•App-app service binding
•Auto-updates from image stream changes
•Synchronization of labels and metadata
•Integration with Service Binding Operator
•Air gap support
•Day-2 operations to gather trace and memory dump
•Single sign-on (SSO) integration
• Multi-architecture deployment (power / zLinux)
• Service Binding governance
• Deployment and update governance (protected rollouts)
• Infinispan integration
• Transaction service / helper
• Auto tune of resource constraints
• Enhanced application security monitoring
• Auto scaling or restart based on specific events
• Exploration of Service Mesh capabilities
• Enhanced Analytics integration
• AI / Machine Learning plugins – app specific
77
Open Liberty Operator

Operator Hub:
https://operatorhub.io/operator/open-liberty

Open Source Community:

https://github.com/OpenLiberty/open-liberty-operator

Certified on 01/11/2020

78
OperatorHub

200+
operators

79
 Operations

> oc client Actions

app
Trace Gathering
OpenShift UI Open Liberty Operator

JVM Dump

Persisted Volume

80
Logging, Tracing and Additional Enabling Technologies

Logging, Tracing and Additional

Enabling Technologies
Centralized Logging and Correlated Tracing
 Recommended Best Practice: Centralized Logging
• Apps in Liberty in OpenShift: can use any solution
• Many apps are using Splunk; it's not deployed in OpenShift
• OpenShift provides ELK (deployed via Operator) Apps using centralized logging mechanisms such as Splunk or ELK,
developers don't need to use OpenShift commands to look at the logs for
• No app-specific code for ELK needed! Apps just use standard Java
applications in OpenShift (albeit, there's very little learning curve for this)
logging to write to console
• Best practice: Ensure standard logging format for easier searching
 Ops team sets up ELK to collect log from console of the running
PODs/containers

 Recommended Best Practice: Correlated Tracing

• App  App flow: difficult to know what each app's log files are for the flow
Collector:
Receives traces and
• Solution: Correlation ID (e.g. trace & span) generated & passed from App to
processes them
• App in flow, added to log files (therefore, seen on centralized log as well)

• Sent also to a centralized trace server

• OpenTrace using Jaeger for implementation is one solution. Query:
• Retrieve and
Ops team sets up Jaeger once
display traces
• Application f/w to hide a) adding the trace id's to the log and b)
commands to send the trace id's to the centralized trace server This diagram is solely to provide some of the technical details of
how Jaeger works - app teams do NOT have to set this up!
Other Cloud Native Enabling Technologies

• Cloud Native involves not only containers but also enabling technologies

• We've seen one key pair of technologies : Centralized Logging and Correlated Tracing

• Caching
• For performance and fallbacks
• Different solutions can be used provided as a cloud managed service, non-container service, containerized service
• OpenShift provides DataGrid
• WebSphere provides it (DynaCache) & need to provide alternative solution: e.g. Redis, OpenShift's DataGrid, Hazelcast

• Application Configuration
• Want Immutable Images = code and image don't change based on different property values for different environments
• One solution in OpenShift: App properties overridden by env variables whose values are populated from OpenShift ConfigMaps
• Other Solutions: Spring Config

• Messaging/Kafka:
• Kafka can be installed in OpenShift or outside of it
• Different patterns: Streaming, using Messaging for Events and Commands

• Metrics and monitoring and alarms

• For overall health of the microservices on a centralized server
• For leveraging metrics (e.g. cpu usage, response time, disk usage) to have automated scaling & automated resiliency
• Different solutions can be used provided as a cloud managed service, non-container service, containerized service
• OpenShift provides a Prometheus Operator to install Prometheus server
License

License
IBM Cloud Transformation Advisor License

IBM Cloud Transformation Advisor License Cost

• Use TA_Local for 90 days for free - after that they need entitlement (e.g. CP4A or CP4I)
• License https://www.ibm.com/docs/en/cta?topic=started-license-information
IBM WebSphere Liberty License

IBM WebSphere Liberty License Cost

Liberty entitlement is included with each WebSphere product with the exception of WebSphere Automation. A wide range
of pricing options exist to address the multitude of customer implementations of IBM® WebSphere®, including perpetual
PVU and monthly VPCs for licensing a server environment.

See License Information : IBM WebSphere Liberty https://www.ibm.com/support/customer/csol/terms/#license-search

and https://www.ibm.com/in-en/products/websphere-liberty/pricing
IBM WebSphere Liberty Product Features

IBM WebSphere Liberty Product Features

Questions

Questions