Survival Guide to WebSphere’s and WebLogic’s End of Life
Enterprises running older versions of Oracle WebLogic Server or IBM WebSphere must manage the impending loss of support for these vital application server products.
First, both products are affected by EOL for Java 6, which is rapidly approaching in December 2018. After this point, Java 6 is exiting Oracle’s extended support, meaning Oracle will no longer provide any patches for Java 6 unless you, as the customer, purchase lifetime support for that Java version. Second, the WebLogic versions tied to Java 6 are exiting extended support one year later on December 2019 (all dates referenced are from Oracle's support page).
IBM customers using WebSphere Application Server (WAS) are in a similar boat. Support for WAS versions 7 and 8 ended in April 2018, and support for WAS 8.5 is ending in September 2019. The same goes for their corresponding Liberty distribution versions.
Although one year seems far away, if you are a part of a traditional IT organization, one year is closer than you think.
For this reason, it’s important to start planning against these important dates immediately. Both WebLogic and WAS have versions you can upgrade to (12.2.x and V9.0 respectively); however, those upgrades have their own challenges.
The Pain of an Application Server Upgrade
The pain of an application server upgrade begins with the actual license cost changes to upgrade your application servers. Both Oracle and IBM have complex license calculators that factor in environment, different ways to calculate virtual CPU usage, and peak load assumptions. Inevitably, as new versions come up and licenses are revisited, unexpected and unwelcome expenditures in licensing arise.
As soon as licensing is out of the way, the planning begins. Because these application servers are such core pieces of technology infrastructure, upgrades affect every team with an app deployed on these servers.
The result is a central IT mandate for all application development teams to upgrade their apps to the new application server version by a particular date. This mandate is a painful process all around. Most development teams already have a planned-out set of releases and commitments to their business partners, and oftentimes those get pushed aside for these central mandates. For the infrastructure teams, it’s a laborious and painful process to audit, contact, and coordinate transitions through dev, system integration, staging, and production for dozens of teams. This becomes especially difficult if the systems happen to be tied to other products, such as identity or ERP platforms.
After the planning is complete, the actual implementation is next. This involves downtime in lower environments to update. The developers must then consider any patches or updates to their own apps, which might depend on the underlying app server libraries.
Testing locally with heavyweight app servers is an exercise in patience — start-up times can extend into multiple minutes. Once the apps have been updated, they are then passed to testers, who must then consume precious cycle time regression testing the apps through one or more testing environments.
In some cases, this might result in other bugs. These bugs might be due to underlying app server issues or, most likely, insidious package conflicts between the apps and the servers. These types of errors are particularly time-consuming to fix.
Assuming you are able to overcome all of these hurdles, you are now ready for the actual production deployment. Approval to begin production is usually a fairly large change control process.
For a change of this magnitude, the change control process probably results in dozens of meetings and spreadsheets, not to mention the struggle of scheduling this change along with all of the other competing changes vying for a precious change window.
So you may ask yourself, “all of this, and for what?” Does any actual benefit to the end users of these apps exist? They will still be dealing with large application servers where requests are single-threaded through the infrastructure team managing this resource, and they will remain tied to platforms with slow start-up times and limited ability to elastically scale with demand.
In addition, many of these applications will still have legacy frameworks such as EJBs that are obsolete and have a dwindling set of experts who can work with them. Many more will have old versions of libraries (for logging, ORM, and security) that development teams would rather move away from. For all of that time spent, application teams and their stakeholders gain little, if any, value for their business.
There’s a Better Way
With these looming deadlines approaching, instead of spending all of this development, project management, and testing time to achieve no business value, why not consider re-platforming or rewriting your application to work in a cloud-native way?
One of the 12 factors of a cloud-native app is that the app is able to run in a self-contained executable. This inverts the application server from a core platform whose changes affect every app to just another library that the application development team maintains.
For an application that still provides value but requires little in the way of changes to support current business needs, you can re-platform the app in a cloud-native way. Re-platforming involves getting just enough done such that the app can run without an external dependency and without sharing state between instances.
By re-platforming, you will instantly gain an application that is less dependent on shared core infrastructure. In addition, you will also have a platform with higher availability, more elastic scalability, and an easier, quicker deployment path — all for nearly the same effort as upgrading to support a new app server.
Rewriting your app from scratch can seem daunting, but if the application has enough business value and undergoes frequent changes, it may be your best choice. Rewriting an app provides you with an opportunity to eliminate technical debt and increase the speed with which development teams can deliver features and bug fixes. Modern software practices such as agile and devOps, with modern PaaS platforms, can accelerate development and reduce costly quality issues that slow down development timelines.
When you finish rewriting a key business application in a cloud-native manner, you will, as a result, successfully eliminate bulky legacy application platforms such as WebSphere and WebLogic and all of the technical debt the app has incurred.
In fact, a recent report by Stripe estimates that companies collectively incur more than $300 billion annually paying down technical debt.
According to this same report, "Businesses need to better leverage their existing software engineering talent if they want to move faster, build new products, and tap into new and emerging trends.”
Completing massive upgrades, while using the same tired old technologies, doesn’t better leverage your talent. There’s a better way.