I have worked with WebSphere Application Server (WAS) for the better part of 15 years.

My experience with WAS has generally been fantastic, great up time, great performance, few if any failures to speak of, a truly rock-solid workhorse. However, it’s heavy and not always the simplest to configure.

WebSphere Application Server

Start-up time

The start-up time is more like a middle-distance runner than a 100m sprinter. While I always enjoyed watching Usain Bolt, I cannot remember a middle-distance runner.

However, while WAS is not the fastest to start, we’ve been re-platforming from Sun Solaris to Linux on Power-10 & x86, and have seen some truly amazing results, in not only the start-up time, but also the runtime performance.

Admin console

The WAS admin console offers everything one could want, but if we’re truly honest, we only use maybe 20-pages or so, and the rest is just noise. How many times have you found yourself click, click, clicking away to find a page, only to think, “after all these years you’d think I could go straight to the page I was looking for”. To my frustrations, I still do this today!

Scripting

How many use Jython scripting to configure WAS, not just basic scripting to deploy an app, but full 100% configuration of an app? For those who do, how easy is Jython to use and maintain? I still find it challenging today. We use Jython for all our configurations and wouldn’t do it any other way. However, experience shows, unless you come from a programming background it can be difficult and overwhelming to use, especially when starting out. Surely there’s an easier way – the simplicity of Open Liberty eliminates this complexity.

I suspect many configure WAS from installation documents, or worse yet from memory, with all the associated issues of typing mistakes, missing configurations and inconsistency across environments – I’ve seen them all.

Many years back while I was scripting all our WAS apps using Jython, I asked a colleague to show me their app config. After around half an hour I asked, “how do you remember all that”. The reply came: “I’ve done it so many times, I remember all the steps”. That person eventually left and so too all of the config knowledge.

Config files

Then there’s the XML config files, all of them, hundreds of them, thousands of them (ok, I exaggerate somewhat). And the directory structure, so many directories. None of this makes life simple. Forget about editing the XML files directly, other than basic changes, a risky proposition.

I did a quick check on my test profiles. The numbers don’t lie, they clearly show the benefit of moving away from traditional WebSphere to Open Liberty.

Developers

I don’t consider WAS a developer friendly product, however, I’m an admin and not a developer so my experiences may be different. For the times I’ve developed a servlet for testing, I much prefer using Open Liberty than WAS. Perhaps that’s why I often see developers using Tomcat, or Open Liberty, fast, lightweight, responsive development runtimes.

Lastly

While the above is perhaps not ideal, for the most part, the WAS environment is easy to manage, and most importantly it is a robust and reliable product – that is essential for mission critical production workloads.

WebSphere Liberty/Open Liberty

Traditional WAS has served us well over the years, however, all good things must come to an end. It’s time to move on. If you haven’t already done so, you need to try WebSphere Liberty/Open Liberty. You won’t look back. I didn’t.

Many may not be aware, but WebSphere Liberty has been around since 2012, while Open Liberty since 2017.

You may be wondering what’s the difference between Open Liberty and WebSphere Liberty. For all intentional purposes, they’re the same.

Open Liberty is the open-source variety, free to use all the way to production (with optional purchased support), whereas WebSphere Liberty is a licensed product from IBM. As I found out recently while using Transformation Advisor (TA), WebSphere Liberty has additional features not available in Open Liberty, such as the Heritage WebSphere APIs feature.

Why use WebSphere Liberty? There are many great articles out there on this topic, so I’ll not focus too much on those, rather I’ll focus on some pain points it solves, plus some cool things (at least to me).

Throughout this post I use WebSphere Liberty and Open Liberty interchangeably. Know that when I do, I am still referring to the same product.

The following sections contains “simple” tests performed on my home PC:

• HP Omen, 12th Gen Intel Core i7-12700K, 3600 MHz, 12 cores, 20 logical processors
• NVMe WD WD_BLACK Gen4 1TB disk

Server creation

The first thing to do after installing WAS or Open Liberty is to create a server.

To be honest, I’ve never been able to remember the profile creation command for WAS. I’ve always resorted to a cut-n-paste. The Open Liberty server creation command is not only fast it’s super easy to remember.

From this (WAS)

manageprofiles.bat -create -profileName Test -cellName TestCell01 -nodeName TestNode01 -serverName TestSrv01 -profilePath C:/IBM/WAS90ND/AppServer/profiles/Test -templatePath C:/IBM/WAS90ND/AppServer/profileTemplates/default -validatePorts -enableAdminSecurity true -adminUserName wasadmin -adminPassword wasadmin -omitAction samplesInstallAndConfig deployIVTApplication

To this (Open Liberty)

server.bat create Test

Admittedly I could shorten the WAS command, but not by much. It’s clear to see Open Liberty adds a simplicity not possible with traditional WAS.

The timing is even more impressive. While the profile creation using traditional WAS took 1 minute and 42 seconds, the server creation using Open Liberty took around 1 second.

C:\IBM\WAS90ND\AppServer\bin>echo %time%
20:28:13.48

C:\IBM\WAS90ND\AppServer\bin>manageprofiles -create -profileName Test -cellName TestCell01 -nodeName TestNode01 -serverName TestSrv01 -profilePath C:/IBM/WAS90ND/AppServer/profiles/Test -templatePath C:/IBM/WAS90ND/AppServer/profileTemplates/default -validatePorts -enableAdminSecurity true -adminUserName wasadmin -adminPassword wasadmin -omitAction samplesInstallAndConfig deployIVTApplication
INSTCONFSUCCESS: Success: Profile Test now exists. Please consult C:\IBM\WAS90ND\AppServer\profiles\Test\logs\AboutThisProfile.txt for more information about this profile.

C:\IBM\WAS90ND\AppServer\bin>echo %time%
20:29:55.15

Time 1 min 42 seconds

C:\IBM\OpenLiberty\openliberty-22.0.0.13\wlp\bin>echo %time%
20:37:01.70

C:\IBM\OpenLiberty\openliberty-22.0.0.13\wlp\bin>server create Test
Server Test created.

C:\IBM\OpenLiberty\openliberty-22.0.0.13\wlp\bin>echo %time%
20:37:02.90

Time 1 second

Server start times

One of the more frustrating things about WAS is the slow start times. While I don’t find this a big problem most of the time, it can be an issue when needing to quickly restart production servers to fix issues or while needing a controlled restart during app deployment. This is especially significant for developers where start times are important.

The most notable difference between WAS and Open Liberty is the fast start times with Open Liberty. This combined with the responsiveness of Open Liberty to dynamically detect and apply changes, makes Open Liberty a perfect runtime for developers.

Comparing WAS and Open Liberty start and stop times

The below “simple” tests compare the differences with the start times:

• Start the server the first time
• Stop the server
• Start the server a second time

The reason for multiple starts was to account for the difference between starting the server for the first time versus every other time. Note that this testing is for the server runtime only, without any deployed applications. While application start times are also important, for the point of this comparison, it is clear that Open Liberty is an improvement over WAS in this area.

Starting WAS for the first time took around 29 seconds while Open Liberty took around 15 seconds.

Starting WAS for the second time took around 21 seconds while Open Liberty took around 2 seconds. This highlights the major improvement with the Open Liberty runtime as compared to WAS.

The server stop times were similarly different with WAS taking around 13 seconds to stop and Open Liberty around 3 seconds.

Detailed results from the tests

C:\IBM\WAS90ND\AppServer\profiles\Test\bin>echo %time%
20:43:53.50

C:\IBM\WAS90ND\AppServer\profiles\Test\bin>startServer TestSrv01
ADMU0116I: Tool information is being logged in file
           C:\IBM\WAS90ND\AppServer\profiles\Test\logs\TestSrv01\startServer.log
ADMU0128I: Starting tool with the Test profile
ADMU3100I: Reading configuration for server: TestSrv01
ADMU3200I: Server launched. Waiting for initialization status.
ADMU3000I: Server TestSrv01 open for e-business; process id is 6744

C:\IBM\WAS90ND\AppServer\profiles\Test\bin>echo %time%
20:44:22.11

Time 28 secs

C:\IBM\WAS90ND\AppServer\profiles\Test\bin>echo %time%
20:45:46.71

C:\IBM\WAS90ND\AppServer\profiles\Test\bin>startServer TestSrv01
ADMU0116I: Tool information is being logged in file
           C:\IBM\WAS90ND\AppServer\profiles\Test\logs\TestSrv01\startServer.log
ADMU0128I: Starting tool with the Test profile
ADMU3100I: Reading configuration for server: TestSrv01
ADMU3200I: Server launched. Waiting for initialization status.
ADMU3000I: Server TestSrv01 open for e-business; process id is 31044

C:\IBM\WAS90ND\AppServer\profiles\Test\bin>echo %time%
20:46:07.76

Time 21 secs

C:\IBM\WAS90ND\AppServer\profiles\Test\bin>echo %time%
20:45:04.99

C:\IBM\WAS90ND\AppServer\profiles\Test\bin>stopServer TestSrv01 -username wasadmin -password wasadmin
ADMU0116I: Tool information is being logged in file
           C:\IBM\WAS90ND\AppServer\profiles\Test\logs\TestSrv01\stopServer.log
ADMU0128I: Starting tool with the Test profile
ADMU3100I: Reading configuration for server: TestSrv01
ADMU3201I: Server stop request issued. Waiting for stop status.
ADMU4000I: Server TestSrv01 stop completed.


C:\IBM\WAS90ND\AppServer\profiles\Test\bin>echo %time%
20:45:17.53

Time 13 secs

C:\IBM\OpenLiberty\openliberty-22.0.0.13\wlp\bin>echo %time%
20:46:33.61

C:\IBM\OpenLiberty\openliberty-22.0.0.13\wlp\bin>server start Test
Starting server Test.
Server Test started.

C:\IBM\OpenLiberty\openliberty-22.0.0.13\wlp\bin>echo %time%
20:46:48.69

Time 15 secs

C:\IBM\OpenLiberty\openliberty-22.0.0.13\wlp\bin>echo %time%
20:47:33.81

C:\IBM\OpenLiberty\openliberty-22.0.0.13\wlp\bin>server start Test
Starting server Test.
Server Test started.

C:\IBM\OpenLiberty\openliberty-22.0.0.13\wlp\bin>echo %time%
20:47:36.09

Time 2 secs

C:\IBM\OpenLiberty\openliberty-22.0.0.13\wlp\bin>echo %time%
20:47:13.81

C:\IBM\OpenLiberty\openliberty-22.0.0.13\wlp\bin>server stop Test
Stopping server Test.
Server Test stopped.

C:\IBM\OpenLiberty\openliberty-22.0.0.13\wlp\bin>echo %time%
20:47:16.84

Time 3 secs

Summary of test results

The below table summarizes the timings from these simple tests.

Simplicity

The simplicity of Open Liberty is perhaps the most striking difference with WAS.

WAS Admin Console to the Open Liberty Admin Center

The WAS admin console allows you to change pretty much every WAS config imaginable. Upon first glance, it shocked me how simple and lacking the Open Liberty Admin Center appeared to be. I discovered you can easily edit the server.xml file using the Open Liberty Admin Center and personally liked the embedded help. I found it to be a fresh and simple look from the overly complex WAS admin console.

However, over time I came to realise there is no need for a fully-fledged Admin Center as Open Liberty is so simple to use and configure. The Admin Center is useful for operations teams who need, or prefer, a convenient and easy way to start and stop apps. I am finding, however, that we rarely deploy the Open Liberty Admin Center.

Alternatively, the Open Liberty REST API can start and stop apps, but this is not as simple or convenient as an Admin Center.

It is interesting (in my experiences) that some app teams have asked for the Admin Center to restart their apps while others are happy to use the Open Liberty REST API.

Changes dynamically picked up

In the previous section I touched on using the Admin Center to restart apps. As Open Liberty automatically detects changes and restarts the necessary components as required, the usefulness and requirement for an Admin Center becomes a lesser concern.

I have found cases where changes were not detected and a manual restart was required. For example, with changes to config files that reside outside of the Open Liberty installation path. I’m not sure whether that’s something we did wrong or whether this is by design. Changes to keystores have needed us to restart the Open Liberty server; not just the app. I have since found there is a REST API that can do this, but I am yet to try.

Other cases where a server restart is perhaps best is after an application deployment, particularly for production environments. At times we’ve needed to use the –clean option to ensure all works as expected.

The above appears to be more exceptions. For the majority of the time, Open Liberty detected the change and dynamically reflected it without needed a server restart or manually application restart. This is somewhat different to WAS and is particularly useful for developers.

Jython, python, and config automation

From what I have observed and heard, many people manage and configure their WAS installations using the WAS Admin Console and an installation document or from memory. This leads to all sorts of problems from missing configurations, inconsistencies across environments and loss of knowledge when people leave the team.

Scripting

We use Jython scripting for the majority of our configurations but it comes with a steep learning curve. And to be honest, it’s not always the simplest to use. It takes effort to maintain but the benefits we’ve gained over the years has made it well worth it.

Coming from a WAS background, when I started exploring WebSphere Liberty, I asked about a scripting language. I found there wasn’t one. This somewhat concerned me at the time. Very quickly I discovered that there’s not a great need for a scripting language when using WebSphere Liberty.

We are now using Python for our WebSphere Liberty installations and configurations with similar benefits we get from using Jython with WAS. It sure makes things simpler and much faster to deploy. However, it has come with some issues, especially around trying to maintain the server.xml file with scripting. It is not practical.

Config as code

As we now use Ansible extensively for our WAS and WebSphere Liberty installations and patching and are exploring options for profile and server creation and configuration, I’ve realized WebSphere Liberty is so simple that we need to re-consider how we do things. We need to think of the server.xml and other files as ‘configuration as code‘.

The simplicity of maintaining config files using an IDE, and the great integration of Liberty Dev mode with Eclipse, VS Code and IntelliJ, it makes more sense to maintain config files using tooling rather than any scripting. There is after-all only one server.xml file, unlike the 100’s of config files with WAS.

We’ll still use Python and Ansible as part of our automation (software installation, server creation, file permissions and other config), but there is little need for a config based scripting language when using Open Liberty, unlike the case for using Jython with WAS.

Developers

While not being a current developer, I have come from a development background before entering the admin world. I still dabble in java programming and the odd servlet creation.

I have created basic servlets with WAS and now with Open Liberty, and can most definitely say my experiences developing with Open Liberty are considerably better than developing with WAS. Using Open Liberty dev mode was an immersive experience for me, and did speed up the servlet creation and testing I was doing.

But I’d like to re-iterate, I’m not a true developer so I’d encourage you to try this out for yourself and form your own opinions.

Liberty InstantOn and the Cloud

Open Liberty is perfect for using in the Cloud. It is lightweight, fast to start and easy on resources. There are many articles on this topic, much better than anything I could say here, so I’ll leave to them to sell the benefits. Needless to say, with the introduction of Liberty InstantOn improving start-up times 10x, there’s an even more compelling reason to consider Open Liberty for Cloud workloads.

Open Liberty URL’s

WebSphere Hybrid Edition

If you’re looking to modernize your WebSphere runtime, look no further than WebSphere Hybrid Edition. Not only does it simplify your licensing model it offers the tools to help modernize your apps to WebSphere Liberty and the cloud.

[9 August 2024] Since first writing this post, IBM Cloud Pak for Applications (CP4Apps) may now be a better option to use as part of your modernizing strategy.

Licensing

No more creating WAS-ND pools, WAS-base pools and Liberty-core pools to manage your licensing costs, you simply create WebSphere Hybrid Edition pools and mix-and-match. With the license ratio being 1 VPC for WAS-ND, 4 VPCs for WAS-base and 8 VPCs for Liberty-core, we’ve not only managed to process the same workload, but we can now do it cheaper (for suitable apps).

We’re moving apps from WAS-ND to WAS-base, particularly for apps that, strange as it sounds, use no WAS-ND features. It is possible to trade-up WAS-ND licenses to WebSphere Hybrid Edition licenses. While there is a cost, it does allow for re-purposing the expensive WAS-ND licenses to the more cost efficient WAS-base/Liberty-base or Liberty-core licenses, without losing the total investment in the WAS-ND licenses. This helps with the modernization journey of the application runtime from traditional WAS to Open liberty for suitable apps.

I personally find the topic of licensing to be a complex and confusing area, but using specialized license scanning software, and using WebSphere Hybrid Edition, it is possible to reduce licensing costs

Transformation Advisor

I’ve been using the binary scanner for many years now as a standalone process. I’ve run this from WAS admin console but I like being able to centralize all the analysis in a single location. This has allowed us to analyse WAS apps for the suitability to modernize from traditional WAS to WebSphere Liberty. The reports are quite extensive and provide many useful details including the creation of a server.xml file listing the features required.

More recently I’ve been using Transformation Advisor (TA). This produces similar output as the binary scanner, but as I’ve found out, it produces much more. With the binary scanner we’d get a basic server.xml file, but TA produces a more detailed server.xml file including all config settings such as data sources, SSL settings, etc., a jvm.options file contain heap values, custom properties, etc. and also container artifacts such as docker files. The “Application modernization assessment and detailed analysis” section in the WebSphere Hybrid Editon pdf highlights the differences.

A detailed description of TA is out-of-scope of this blog, but the output and GUI presentation and analysis of the scanned apps is fantastic and definitely helpful with the modernisation journey.

One interesting file I found was a Jython file containing commands to create the WAS artifacts. I haven’t checked whether it contains all the commands for your app, but it could be handy if you need to re-install WAS or to re-platform it, where you don’t have any documentation or scripting of the installation.

Mono2Micro

WebSphere Hybrid Edition also has an impressive looking Mono2Micro offering. While I have only explored this briefly, and it was a little challenging for me being an admin and not a developer, the tool looks helpful for the process to break up monolithic apps into microservices with minimal risk and rewriting of code. As this is out-of-scope of this blog, I won’t comment further.

Hybrid Edition URLs

Time to start using WebSphere Liberty

If you haven’t started using WebSphere Liberty, it’s time to start now.

Many years back I couldn’t convince anyone to try WebSphere Liberty, now they ask me for it. They see the benefits. One time I installed WAS-base, the (app) team said, ‘thank you, but no thank you, we want Liberty’. I have many teams, including software vendors, jumping on board now.

You should do your own research, but WebSphere Liberty performs well, starts fast and is incredibly easy to configure.

Coming from a traditional WAS background, where configuring WAS, creating profiles, federating profiles and pretty much everything is time consuming and convoluted, it is refreshing to see the simplicity of WebSphere Liberty. You don’t get a feature rich admin console like WAS, but as I have found out, who cares. You no longer need it. But you do get a ‘load nothing, select what you want’ style with WebSphere Liberty rather than a ‘load lots, use what you want’ style you get with WAS. WebSphere Liberty only loads the features you use. Nothing more, nothing less.

And now with Liberty InstantOn, you can get lightning fast start-up in the cloud, particularly useful for scale to zero microservices. Or for when you need to ramp up the pods quickly to cater for heavy processing periods such as payroll days or marketing times when many customers login concurrently.

Final thoughts

Have you ever created a WAS installation, spent many hours configuring it, only to find you made a typo with the server name (I’ve done that) or cell name, or decided the name chosen wasn’t ideal (done that too). Or you wanted to clone (yep, this too) an installation – good luck with that. You either live with the mistake (for many years), or you spend many hours rebuilding from scratch. I have Jython scripts and automation I hear you say – we do. This helps to some degree and assumes you’ve managed to always keep your Jython scripts up-to-date.

With WebSphere Liberty, never mind, just rename the directory and you’re done. One second versus, maybe half a day or more. Want a clone, zip it, unzip it, same (Unix) server, different server, doesn’t matter, rename the Liberty server, maybe some (config file) edits, you’re done. We’ve done this and it works just fine. I’ve even zipped a WebSphere Liberty server on Sun Solaris and unzipped on zLinux and ran the app with no issues. To me, this highlights the power and flexibility of using WebSphere Liberty, a new philosophy maybe, what seems like a lifetime away from traditional WAS.

#IBMChampion (2021-24)

Last edited: