Demystifying Liberty for WebSphere administrators

IBM WebSphere Liberty has been around for more than a decade, yet many WebSphere administrators are more familiar with WebSphere Liberty’s predecessor, WebSphere Application Server (WebSphere traditional, or tWAS). WebSphere Liberty is a modular, Jakarta EE and MicroProfile application runtime that is built from the open source Open Liberty project. All applications that run on Open Liberty can also run on WebSphere Liberty, and both flavors of Liberty can be supported by IBM Support.

Liberty takes a different approach from WebSphere traditional in its approach to application deployment and operations, reflecting changes in the broader IT industry and evolving development practices.

If you're used to WebSphere traditional but are planning to migrate applications to Liberty, you probably have a lot of questions. This article addresses some of the most common Liberty operations questions we hear and tries to clarify and debunk some of the myths that have surfaced over the years.

Each question in this article is answered briefly in the text. The fuller answer is given in the accompanying video by Alasdair Nottingham, Chief Architect of WebSphere traditional and Liberty. The clips are taken from the recording of a presentation he gave in early 2025.

If you have questions that are not answered in the videos, visit the WebSphere and Liberty wiki to see if it’s answered there; if it’s not there, raise an issue on the wiki.

What if you use Modernized Runtime Extension for Java (MoRE)?

This article is not aimed at WebSphere traditional administrators who are planning to adopt MoRE. Modernized Runtime Extension for Java (MoRE) is an extension to WebSphere Application Server that enables organizations to migrate WebSphere traditional applications to Liberty while still managing those Liberty servers as part of existing WebSphere traditional cells and by using the WebSphere traditional administration tools (administrative console and wsadmin scripting).

Some myths shift when using MoRE; we’ll cover those updates separately elsewhere. This article is for the many WebSphere traditional users who are exploring migrating applications to Liberty but who aren’t planning to adopt MoRE and have questions about what that transition really means for their operations.

Myth #1. Liberty is only for deploying in containers

The first myth is that Liberty is only deployable in containers or the cloud. This is not true. In fact, when Liberty first came out, there were no containers. They didn't exist. So, Liberty can be deployed on-premises in virtual machines (VMs) just as well as it can be deployed in containers in the cloud.

Liberty installation options in VMs

Liberty fix packs are released about every four weeks, in line with Open Liberty continuous delivery (CD) schedule. If you are a WebSphere traditional customer, use your IBM entitled login details to access Liberty downloads from IBM Support.

In VMs, you have several installation options for Liberty:

• Installation Manager. Download the Liberty binaries and fix packs.
• Self-extracting JAR file that installs all the features. Download the latest wlp-nd-all-<fix\_pack>.jar file then run the java command with the acceptLicense option.
• ZIP file containing just the Liberty kernel. Download the latest wlp-kernel-<fix\_pack>.zip file, unzip the file, then use the installUtility command to install just the features you want on top.

So, there's a lot of flexibility in a VM-based installation. Also, Liberty follows a principle of zero migration, which means you can stay current with Liberty's frequent releases to help mitigate security risks and benefit from bug fixes, while your applications continue to run unchanged.

Deployment patterns and topologies

With Liberty, you can follow a range of different deployment patterns (described in Chapters 1 and 5 of this IBM Redbook) depending on your application requirements:

• Single server that receives HTTP traffic directly
• Single server with a web server to route traffic to it
• Multi-server topologies

None of this requires you to run Liberty on containers, or even on the cloud. If you want the VMs to run on IBM Cloud, Amazon, or Azure, go ahead. You absolutely can do that—if you want to. But you don't have to. You can run this on-premises.

Myth #2. Liberty does not have centralized management

It is true that (unless you are using MoRE) you can't manage Liberty servers in a WebSphere traditional cell, but Liberty has its own centralized management environment called a collective.

Collectives can scale to about 10,000 JVMs. WebSphere traditional cells have a cell size limit of only about 100 JVMs, which some customers find constraining. Liberty collectives were therefore designed to be a very different management environment.

“Shared nothing” architecture of collectives

Collectives have a “shared nothing” environment. There is no centralized view of configuration that is owned by the central administration point to be distributed to all the servers. The servers don't talk to each other in general, so it's a much lighter weight model than a WebSphere traditional cell and therefore it can scale much higher.

Some key features of collectives include:

• High availability and scaling. As well as running 10,000 JVMs in a single collective, you can configure the collective controllers for high availability (HA).
• A collective controller. You can use the collective controller to visualize and manage the environment, with the HTTP server routing the traffic to the servers.
• Managing Liberty servers from any Liberty edition. A single Liberty collective can manage Liberty Core servers, Liberty base servers, and Liberty ND servers. There are some capabilities that aren't available to Liberty base and Liberty core servers; for clustering, auto-scaling, and health management, you need an ND license so that you can use collectives. But to manage Liberty servers in collectives just as a single point of control for the environment, only the collective controllers need an ND license.
• Communication methods. There are two ways that the collective controller connects to the servers. One is by using HTTP and the other is by using SSH. The collective is agentless. There is no process running on the hosts to do things like file transfer or server control. Instead, Liberty collective controllers use an SSH daemon to connect to and control servers

Myth #3. Liberty doesn't have an admin console

The next myth is that Liberty doesn't have an admin console. Liberty does have a web-based admin console but it's called the Admin Center.

Liberty's Admin Center takes a different approach from the WebSphere traditional admin console. Liberty's Admin Center provides a task-based administrative interface, rather than just exposing everything under the sun and hoping the user can work it out. Admin Center enables certain user activities and user behaviors rather than enabling doing everything in the web interface.

These key tools are available in the Admin Center:

• The Explore tool, which allows you to see servers and applications and get some basic performance numbers, like average response time, and request counts for web applications. The metrics are not as extensive as the Tivoli Performance Viewer in the WebSphere traditional admin console, but the statistics it has are the ones that most users are most likely to need easily at hand.
• The Configure tool, which is a form-based editor and an XML-based editor for editing the Liberty configuration. When you use the Configure tool, it's connecting to the Liberty server that's running, reading the server's XML file, and displaying the configuration in the browser. This allows you to very easily see the server configurations. The configuration shown is based on each server’s XML file that it accesses, as opposed to the logical view that the WebSphere traditional admin console has.

Security and setup

As with collectives, to set up Liberty Admin Center, you must enable admin security. The Admin Center runs in collectives or on a single Liberty server; you just get more function if the Admin Center runs in a collective controller.

Liberty has two basic registries that are built in: Quick start security and basic registry. You shouldn’t use either of these for production because there's no password expiry and no bad password guessing protection. These two basic registries are just there for developer ease-of-use. To configure the Admin Center security, you need a registry and then you can configure the roles. You can use an existing LDAP registry.

Myth #4. You cannot script Liberty

Scripting in Liberty is the biggest difference between Liberty and WebSphere traditional. With WebSphere traditional, you have wsadmin which provides a rich Python scripting environment. Liberty doesn't provide a Python shell, or all of the scripting support that WebSphere traditional provides. But this difference is intentional and for good reasons.

Although wsadmin provides a great scripting environment for WebSphere traditional, the Python language itself tends to make breaking changes between versions. It’s also difficult to maintain a version of Python that suits everyone. Some customers have lots of scripts that they don't want to ever change, while other customers want to use new language features from newer versions of Python.

With Liberty, the XML configuration files are very simple and easy to reuse. So, it's very easy to use Jython by bringing your own Jython scripting engine (or JRuby, or Groovy). You can bring the version that you want for your scripts, read the XML files, make changes to the XML files, and then write them back to disk very easily from within a Jython environment.

See the video for an example script for the installation of an application (upload and extract a WAR file) with Jython by using the Liberty REST connector to access the JMX management beans (MBeans). Using the REST connector, you can perform common admin tasks such as checking server status, uploading files, starting applications, and more.

Automation with templating engines

The Liberty configuration files can be easily overridden by other configuration files, which enables operations teams to override configuration set by developers in applications without having to edit the application source code directly.

Liberty's text-based configuration can also be parameterized using variables and be shared and controlled using a version control system. This also makes it very simple to automate using templating languages and by DevOps frameworks like Ansible.

Myth #5. It is very hard to configure Liberty with IBM HTTP Server

A myth that comes up quite often is that it is very hard to configure Liberty with IBM HTTP Server. This usually comes up because Liberty does it differently from how you would do it in the WebSphere traditional admin console. WebSphere has a set of features that generate the plugin configuration and upload it to the web server. Liberty doesn't have those features.

Dynamic routing and collectives

Instead, Liberty has dynamic routing. Dynamic routing requires that you run a collective.

If you have configured dynamic routing in the collective controller, the web server plugin checks with the collective controller to find out where applications and servers exist in the topology before routing traffic there.

The important thing to note is that the collective controllers are not involved in the routing of actual HTTP requests. The collective controller is just being used to get an up-to-date view of the state of the collective.

If you add or stop servers, or if you add or remove applications, the collective controller automatically finds out from any collective member servers about that change.

If all of the collective controllers are down for some reason, the HTTP server just uses the last known good state of the system. A lack of running collective controllers doesn't stop the web server from routing HTTP traffic to collective member servers. The web server plugin wouldn’t, of course, get live state of any servers being started and stopped or applications being added or removed, so it would have to fall back to the mechanisms it uses for static plugin configuration.

With dynamic routing, the web server plugin configuration (in plugin-cfg.xml) tells the web server plugin where the collective controllers are. This configuration is common between the dynamic routing function in Liberty and the equivalent function in WebSphere traditional; it’s the same code. It's called ODRLIB in WebSphere traditional. In Liberty, the web server plugin gets the state information from the collective controller; in WebSphere traditional, the state information is obtained slightly differently from the deployment manager.

Myth #6. Liberty doesn’t support high availability (HA)

WebSphere traditional servers are usually run in clusters, which handles high availability (HA) concerns. It's often believe that Liberty, with its different approach to centralized management doesn't support HA. This is not true because Liberty supports HA through its collectives architecture:

• Security and LTPA key sharing. A lot of WebSphere traditional users use LTPA. In a cell, the deployment manager manages the LTPA keys between all the servers, in such a way that you generally don't need to think about it. Liberty also supports LTPA, but by default every server has its own LTPA keys. You can copy the same LTPA keys to multiple Liberty servers, so that they have the same LTPA keys, and are in the same security domain.
• HTTP session persistence. HTTP session data can be stored into either a database, like DB2, or it can be stored into a JCache caching implementation, such as Hazelcast or Red Hat Data Grid. WebSphere traditional also supports using a database, but with WebSphere traditional you can use session replication within a cluster, so many people don't really think about this, but you can do it with Liberty; you just need this external system to manage the state.
• Transaction recovery. Another part of HA is transactions. If you're making database updates or messaging updates inside Liberty and the server goes down, you tend to not want to leave those transactions in doubt. With Liberty, you can store the transaction logs in a database and then configure the Liberty server so that if one of the servers falls over, the other servers can perform recovery. A recovery server notices that the original server has gone away because of state in the database that tells it that it is no longer around.
• Security cache persistence. As well as HTTP session state and transaction state, you can store security information, the authentication cache, in JCache. The LTPA logout cache can be persisted using JCache. That means that if somebody were to log out from one Liberty server, they would be logged out from any other Liberty server that is sharing that persistent cache store.

Myth #7. Liberty doesn’t perform as well as WebSphere traditional

A myth that comes up reasonably often is that Liberty doesn't perform as well as WebSphere traditional. And that's just not true.

From the large set of benchmarks comparing Liberty to WebSphere traditional (including Acme Air and Trade 7 applications, shown in the following graph), Liberty outperforms WebSphere traditional.

The Liberty runtime was created on the back of the WebSphere traditional runtime, so Liberty benefited from all the work that the engineering team has done over the years to performance tune WebSphere traditional. Since then, Liberty has had a lot of development to improve its performance further, including to have fast startup with Liberty InstantOn while retaining competitively fast throughput speeds.

Of course, as with all performance benchmarks, your mileage may vary. Your application may do something unusual that has been optimized in WebSphere traditional and not in Liberty.

In most cases, though, Liberty performance is as good, if not better, than WebSphere traditional. And Liberty is certainly better in terms of memory footprint and startup time.

Myth #8. I don't have licenses to run Liberty

A lot of WebSphere traditional customers think of Liberty as a separate product from WebSphere traditional. While Liberty is a separate runtime, existing WebSphere traditional customers don’t have to buy Liberty separately.

If you are already using WebSphere traditional or WebSphere Network Deployment (ND), you can choose between running WebSphere traditional, WebSphere Liberty, or Open Liberty with the same license. Running WebSphere traditional or Liberty servers in cells or collectives means you can run fewer servers than if running them as standalone servers under the same number of purchased “cores” (the licensing units used). For example, if you have purchased two cores of IBM Enterprise Application Runtime (EAR), you can run two cores of servers in cells or collectives, or you can run 11 cores of standalone servers. The servers can be WebSphere traditional, WebSphere Liberty, Open Liberty servers, or a mixture.

The total number of servers you can run varies according to which licensing bundle you purchased, as shown in the following table (where the ratios show the number of cores of servers to the number of cores of license purchased):

Summary

Migrating applications from WebSphere traditional to Liberty can seem daunting, especially with so many myths and misconceptions circulating. This article, supported by expert insights from Alasdair Nottingham, has addressed some of the most common myths about Liberty operations, from deployment flexibility and centralized management to performance and licensing.

Liberty is a modern, lightweight, and highly capable runtime that supports a wide range of deployment models, including on-premise and cloud. It offers centralized management through collectives when running on VMs rather than in containers, a user-friendly Admin Center, scripting capabilities, and robust support for high availability. Additionally, Liberty’s performance rivals that of WebSphere traditional, Liberty’s zero migration is a significant benefit for maintenance, and your existing WebSphere traditional licenses usually cover using Liberty instead.

For WebSphere administrators, Liberty offers a compelling path forward, with modern development practices and reduced operational complexity. If you still have questions, explore the WebSphere and Liberty wiki to get the answers you need.