WebSphere Application Server & Liberty

 View Only

6+3 Reasons Why Liberty is the Runtime for Hybrid Cloud

By Shane ORourke posted Thu November 04, 2021 02:40 PM



In a previous article we covered in detail the benefits of Liberty for developing and deploying microservices. In this article, we revisit the values of Liberty, and demonstrate why we believe it is the destination runtime of choice for both migrated enterprise Java workloads for Hybrid Cloud, and Cloud-Native workloads. 

There are two flavours of Liberty.  IBM® WebSphere Liberty which was created in 2012 is an lightweight, agile runtime which is suited for both new Cloud Native development, including microservices and in containers, as well as delivering additional features that make it easier to modernize traditional enterprise applications. The open source version is Open Liberty which was created in 2017.

Liberty is uniquely placed in the market to address both these requirements. WebSphere Liberty's  modular architecture is lightweight and flexible for Cloud Native, and is a comprehensive, flexible and secure Java EE, Jakarta EE and MicroProfile runtime  for modernizing your existing Java applications.

Let’s look in a bit more detail at the top six reasons why Liberty is an ideal choice for Cloud-Native workloads, including microservices and an additional 3 reasons why Liberty is perfectly suited for migrated enterprise Java workloads for Hybrid Cloud.

6 + 3 Reasons Why 

  1. Right Size Runtime 
  2. Low operating cost (with IBM Semeru )
  3. Kubernetes  Optimized 
  4. Continuous Delivery 
  5.  Zero Migration 
  6. Developer Experience 
  1.  Availability on Public Clouds 
  2. Breadth of Architecture Support 
  3. Breadth of API Support 

Reason 1. Right Size Runtime – no extra baggage

Liberty is a fully modular runtime, letting you pick and choose the capabilities you need for your application. With Liberty, you have one runtime, one approach, to developing and deploying applications that scales from small microservices all the way up to full modern enterprise monoliths, and anything in-between.

Sample Memory Profiles
The following table shows disk and memory measurements for three example runtime packages. You can see that as we right-size Liberty for a reducing set of needs, the disk and memory requirements also decrease, which is exactly what you would want from a runtime.

Package Example Size on disk Memory
Java EE 8/Jakarta EE 8 + MicroProfile 3.3 Modern Cloud-Native monolith 121MB 165MB
MicroProfile 3.3 Typical microservice 59MB 113MB
Servlet 4.0 Simple web framework 24MB 72MB

Reason 2. Low operating cost – less memory, higher throughput are key

Liberty has significant memory, performance and throughput benefits when compared to other runtimes, and provides a 100% open source Java EE, Jakarta EE and MicroProfile core.

IBM Semeru Runtimes Benefits
The higher performance, higher throughput, faster startup and lower memory footprint in Liberty is underpinned by IBM Semeru Runtimes. 

Startup comparisons

Liberty’s time to first response is approximately 1 second , and there is continuing innovation to bring startup times directly in line with compile to native runtimes.  Given the expected usage profile of tens to hundreds of services with thousands of requests, the most important performance metrics are memory consumption and throughput; these are the ones that will have the biggest impact on cost. There 

Memory footprint comparisons

Bar graph memory footprint comparison of Open Liberty, WildFly, TomEE, Payara, and Helidon

Memory Footprint Comparison

In the Acme Air Microservices benchmark,  Liberty uses 2.5x-10x less memory than other runtimes.

Memory Footprint Comparison (Spring Boot)

If you’ve chosen Spring Boot for your application, then there’s approximately a 2x memory footprint benefit from running on Liberty, as per the Spring Boot Petclinic application.

Bar graph showing a 2x memory footprint benefit when running Spring Boot Petclinic on Liberty, versus Tomcat, under load

Throughput comparisons

Bar graph showing Liberty throughput better than WildFly, 2x better than TomEE, and 5x better than Payara and Helidon

Throughput Measurements
(against the Acme Air Microservices benchmark).

Liberty has the overall best performance across the runtimes tested and is significantly better than most of them.

Throughput Measurements (Spring Boot on Tomcat)

2x throughput benefit when running the Spring Boot Petclinic application on Liberty, rather than Tomcat.

Bar graph showing a 2x throughput benefit when running Spring Boot Petclinic on Liberty, versus Tomcat, under load

  • Combining the memory and throughput benefits equates to an over 4x saving (throughput per MB) for this Spring Boot application on Liberty and a 3.5x benefit over the nearest of the other runtimes compared. That’s potentially a greater than 3x saving on Cloud and license costs.

Reason 3. Optimized to Kubernetes – auto-tuning, native integration

Containers and Kubernetes are  integral to the delivery of cloud-native microservices. Continuous delivery of container-based microservices needs a runtime that supports container and container orchestration (Kubernetes) best practices. It needs to be easy to:

  • Achieve the best performance without knowing where the container will be deployed.
  • Create and maintain secure and supported images.
  • Integrate the runtime and application with the container orchestration environment.

Auto-tuning runtime

To get the best performance out of the application in containers Liberty does two things:

  • It provides great defaults that you are highly unlikely to ever have to change.
  • Provides a thread pool that is auto-tuning, optimizing for the environment in which it finds itself running.

Liberty throughput based on different latencies of requests.

You can see that the auto-tuning quickly reaches the optimal performance. And if latency were to change over time, Liberty would adjust appropriately.

Line graph showing Liberty throughput quickly reaches peak performance by auto-tuning its thread pool

Production-ready images

For each new release of Liberty, new Universal Base Image container images are uploaded to Docker Hub. The images are free to distribute — OCI-compliant (Open Container Initiative), with support available if you choose. Images for Open Liberty and WebSphere Liberty are uploaded and maintained based on Liberty’s support policy. Fixes to critical security vulnerabilities are automatically applied and the images updated, so that you don’t have to.

Kubernetes integration

The Open Liberty Operator enables first-class management of Liberty within Kubernetes and OpenShift. It greatly simplifies deployment and configuration of applications, clustering, persistence integration, service binding, problem determination, and much more.

Reason 4. Continuous Delivery – low maintenance, zero technical debt

Liberty has a ‘continuous delivery’ release cycle, shipping a new release every four weeks. Any fixes shipped for the previous release are automatically rolled into the next. So with continuous delivery, there’s no need to apply service — you get it automatically. Every release of Liberty is made available in Maven Central and Docker Hub, making it much simpler to pick up the latest through build automation. Development teams can simply rebuild their containers to pull in the latest release, confident it contains fixes to the previous version. The second part of the answer is ‘zero migration,’ which is discussed in the next section.

Reason 5. Zero Migration – staying current, effortlessly

Liberty is the only Java runtime that provides ‘zero migration.’ Zero migration means, in just a matter of minutes, you can move up to the latest Liberty without having to change your application code or configuration. Historically, these kinds of moves filled teams with dread, having to be planned months in advance and taking over a year to complete — that’s a lot of investment just to stay current.

Coupling continuous delivery with zero migration means you can remain current with fixes, with minimal investment, and choose to invest in application changes when there’s a business need and benefit to doing so.

Reason 6. Developer tools that help, not hinder – container-aware, CD-focused

Liberty has always had a strong focus providing a first-class developer experience for developers on their tools of choice. Liberty integrates with the most popular build tools — Maven and Gradle — including releasing all the runtime binaries to Maven Central. Liberty’s Maven and Gradle support also provides, ‘dev mode,’ which means developers can make code and configuration changes and have those take immediate effect on a local running server, even a server running in a local container. 

For in-container testing, doing true-to-production integration testing with  ‘MicroShed‘ provides the ability to run JUnit integration tests against a Liberty application running in a container, including integration with containers running databases and Kafka.

Reason +1. Availability on Public Clouds

In partnership with Microsoft, we now have Azure Marketplace availability for WebSphere Liberty and Open Liberty on AKS and ARO

Azure Kubernetes Service (AKS)

  • This offer automatically provisions several Azure resources to quickly move to IBM WebSphere Liberty or Open Liberty on AKS. This includes Azure Container Registry (ACR), an AKS cluster and the Liberty Operator. The offer can conveniently deploy Open Liberty or WebSphere Liberty Container (e.g., Docker) images. After deployment you can focus on deploying your Liberty application to AKS, using DevOps tools such as GitHub Actions, UrbanCode Deploy, Gitlab Ultimate.

Azure Red Hat OpenShift (ARO)

  • The offers aim to cover a range of use cases from mission critical existing traditional workloads to cloud native applications. Offers include WebSphere Liberty and Open Liberty on Azure Red Hat OpenShift (ARO).

We also provide

  • Amazon AWS support for WebSphere Liberty and Open Liberty on Amazon Elastic Kubernetes Service (EKS) and Red Hat OpenShift Service on AWS (ROSA).
  • IBM Cloud support for WebSphere Liberty and Open Liberty on IBM Cloud® Kubernetes Service (IKS) and Red Hat OpenShift Service on IBM Cloud.

Reason +2 . Breadth of Architecture Support 

You should not have to change your runtime depending on what you Java application architectural requirements are.  Pick a runtime that is modular and has proven capable of running large scale enterprise monoliths in containers,  small microservices on containers and VMs, whether that is on premise, or in your Cloud of choice, either in  Kubernetes native or in OpenShift. 

Reason +3 . Breadth of API Support 

Liberty's breadth of API support, including MicroProfile, Jakarta EE, provided in a modular fashion, delivers the full spectrum of development support.  Liberty can minimize modernization efforts  by exploiting your existing investment to produce a modern, modular, Hybrid Cloud application, or alternatively a building Cloud-native (designed 100% for Cloud) replacement application from scratch. It also provides the performance benefits of running a Spring Boot application on Liberty, rather than Tomcat.


The move to finer-grained cloud-native microservice deployments leads to new challenges for development and operations teams: the need for runtimes with high throughput and low resource usage; the need for first-class container and Kubernetes integration; the need to be able to remain secure by upgrading simply and frequently; and more.

This article has highlighted six + three capabilities of Liberty that address these new challenges:

  • Right Size Runtime
  • Low operating cost (with IBM Semeru )
  • Kubernetes  Optimized
  • Continuous Delivery
  • Zero Migration
  • Developer Experience
  • Availability on Public Clouds
  • Breadth of Architecture Support 
  • Breadth of API Support 

These capabilities make Liberty an ideal choice for both migrated enterprise Java workloads for Hybrid Cloud, and new Cloud-Native workloads. 

WebSphere Liberty is available in IBM® WebSphere Hybrid Edition.  Try a 60 day trial of WebSphere Liberty here