Goodbye, WebSphere Traditional; Goodbye, My Youth

2024/11/05 Update: As of 2024, IBM has officially canceled the previously planned end-of-support (EOS) for WebSphere Application Server (tWAS) v8.5.5 and v9.0, which had been scheduled for 2030. The updated announcement can be found here: IBM WebSphere Application Server Support (previous announcement URLs now redirect to this page).
IBM will continue to release fix packs for tWAS, and it is likely that there will not be a tWAS v10. Additionally, the JDK will remain on IBM JDK8 (not OpenJDK-based). Currently, customers actively migrating from tWAS to Liberty are focusing on three main directions:

1. Embracing Cloud Architectures: Deploying WebSphere on Kubernetes (K8s) or other modern cloud platforms.

2. Java Modernization: Upgrading JDK to versions higher than 8 for compatibility and new features.

3. Resource Optimization: Leveraging Liberty’s efficiency, such as reducing memory usage by over 45%.

These focus areas highlight the transition towards modernized, cloud-native, and efficient application infrastructures.

Recently, some old friends invited me to teach a class, and during the preparation process, I realized that tWAS hasn’t seen updates beyond version v9.0.x. IBM now recommends that customers start adopting the Hybrid Edition.

The Hybrid Edition appears to provide the following benefits:

1. Licenses for Both tWAS and WebSphere Liberty: Customers gain access to both products.

2. Additional Support Tools: Includes tools to facilitate management and migration.

3. Developer Tool Support: Supports WebSphere Developer Tools and Liberty Developer Tools.

After tWAS v9.0 was released in 2015, it seems that IBM underwent multiple internal discussions about the product roadmap. Eventually, they decided not to release a tWAS v10.0, focusing instead on extending support for tWAS v8.5.5 and v9.0 until 2030. This decision aligns with IBM’s strategy of gradually transitioning customers toward Liberty while ensuring long-term support for the existing tWAS versions.

https://www.ibm.com/cloud/blog/announcements/ibm-websphere-2030-support-announcement

As a result, only WebSphere Liberty continues to release new versions and features, while tWAS now focuses solely on fix packs. This shift positions Liberty as the next generation of WebSphere—a lightweight, containerized middleware solution.

The versioning scheme for WebSphere Liberty has also adopted a modern, streamlined approach. Each year corresponds to a major version increment, and updates are released at least monthly (resembling a sprint cycle). For example, as of October 2022, the latest version was 22.0.0.10—the 10th release of 2022.

This approach emphasizes agility and compatibility with cloud-native and DevOps-driven workflows, aligning with the needs of modern enterprise IT environments.

Time flies—it’s been 22 years since I first encountered tWAS v3.5 back in 2000. Before tWAS v6.0, installing and managing WebSphere was truly a nightmare. A single misstep could mean restarting the entire installation or management process, which was incredibly frustrating.

However, everything changed with the release of tWAS v6.0 in 2004. Installation and management became much simpler, and this architecture persisted all the way to v9.0.x, remaining largely unchanged for an impressive 18 years. This stability speaks volumes about how well-designed the architecture was to last for nearly two decades without significant modifications.

Yet, as the industry shifts towards cloud-native architectures, middleware must adapt to the container model. The traditional WebSphere architecture struggles in this environment. It’s not only difficult to fit into a container due to its traditional installation processes but also hindered by slow startup and shutdown times, making it unsuitable for cloud-based operations.

When WebSphere Liberty debuted in 2012, it marked a turning point. Liberty’s lightweight and container-friendly nature was a clear signal of the future direction for WebSphere. It became evident that tWAS was approaching the end of its journey, as the industry moved firmly towards cloud-native and containerized middleware solutions.

Although WebSphere Liberty was introduced in 2012 and tWAS is set to reach end-of-support (EOS) in 2030, many tWAS customers in Taiwan still haven’t started transitioning toward Liberty. From my observations, this hesitation primarily revolves around cloud architecture-related challenges. Some key reasons might include:

• Still evaluating cloud architecture.
• Under the cloud architecture, there are too many Java middleware options to choose from.
  • Apache Tomcat (even Spring Boot)
  • Eclipse Jetty
  • Redhat JBoss (Wildfly)
• Under the cloud architecture, it is necessary to consider changes in infrastructure and middleware configurations.

The above are more architecture-related issues, but there is one aspect that might be more easily overlooked: developer productivity.

Let’s take a look at the current support status for development tools:

• WebSphere Developer Tools (for tWAS) is no longer being updated. Currently, it only supports installation on Eclipse versions prior to 2020-06 and relies on a version released over two years ago. This older Eclipse version has significantly slower startup speeds compared to the 2022 versions and still contains some bugs that were only resolved in the past two years (such as certain issues with Eclipse Maven integration).
• tWAS cannot be installed on the latest versions of macOS (currently, IBM Installation Manager only supports up to Big Sur 11.0: Compatibility Report), whereas WebSphere Liberty can run on the latest versions of macOS.
• Liberty Developer Tools is continuously being updated and is currently compatible with Eclipse version 2022-06 (though upgrading to version 2022-09 causes issues, which is unfortunate). Additionally, there are official plugins available for IntelliJ IDEA and VS Code, which meet most of the modern developers’ needs.

In summary, considering the architectural and tooling issues mentioned above, customers currently using tWAS should carefully evaluate their future strategies. Moving forward, I plan to write a series of comparative articles on tWAS and WebSphere Liberty. This will serve as both a learning opportunity for myself and a reference for friends and colleagues who may need it.