WebSphere Liberty has now ‘grown-up’ to provide the full Java EE 7 platform. Combining that API set with operational capabilities that have been rapidly expanded over the past three years, Liberty is now a great deployment choice for many Java applications. WAS traditional remains fully strategic, however, and will evolve to the Java EE 7 standards itself in time, so how do you choose between the two?
This article will introduce some of the aspects that you should consider when choosing between traditional WAS and WebSphere Liberty. For a deeper dive into these aspects, please read the full white paper (PDF).
Programming Model (API)
The first aspect to consider in placing your application is which programming models (APIs) it requires. Liberty now provides the full Java EE 7 platform, as well as many of the related open standards and proprietary WAS APIs that are available in traditional WAS. There are only a few strategic APIs that are not available with Liberty, including some of the OSGi Application support (although that gap has continued to close with each quarterly delivery), and some of the Java EE standards beyond the Platform specification, including Portlets and SIP servlets. Less strategic programming models that are not available with Liberty fall roughly into four categories: APIs deprecated by the Java EE specification, WebSphere extension APIs that have been superceded by Java EE capabilities, APIs used mostly by extending products, and some other WAS APIs that have low use among customers.
There are tools available to examine your application code and to identify the use of any of these APIs.
Administration and Topology Choices
There are key differences in the administration and underlying configuration models of the two profiles. If you have extensive investment in automation scripts for traditional WAS that cannot be used with Liberty, you may choose to stay with traditional WAS for the time being. However, the radically simpler configuration and more flexible administration choices for Liberty are also compelling reasons for some to move. If you are starting from scratch, or building a next-generation application infrastructure, Liberty provides a simpler, more flexible administration model that fits very well with modern dev-ops flows and tools.
There are some hybrid management options which allow Liberty servers to be managed in existing traditional WAS cell topologies. These models may allow a more rapid integration of Liberty servers through using familiar tools, but will generally still require new scripts to be written for automation.
Both profiles provide a web admin GUI. Traditional WAS has a mature Administration Console which allows fine-grained configuration updates, provides many wizards to accomplish common tasks, and allows deployment of applications as well as most other administrative actions. Liberty has a more modern Admin Center feature, which provides a highly scalable view of the Liberty topology with more focus on monitoring than fine-grained control, in keeping with the general trend towards automated dev-ops flows.
Management of HTTP traffic is very similar for both profiles, as are options for session distribution. There is no failover provided in Liberty for stateful web service or remote EJB requests. There are still some differences in the provision of security services, including SAML and programmatic access to users and groups in security repositories.
As alluded to above, server start time and memory footprint are generally much lower for Liberty, but because of the extensive sharing of code for transports, containers and application services, the production throughput performance of both profiles is very similar.
Version migration is simplified on Liberty; user configuration does not need to be modified for use with new versions of the runtime, and the continued support of existing API features means that applications don’t need to be migrated either; this could be a significant cost-saving going forward.
Reasons to choose traditional WAS
- It costs nothing to move (if you’re already there and it does what you need)
- Still has more function than Liberty
- Full API, full admin console, security options
- Some applications can’t move or would take too much effort
- Uses existing admin skills and assets
- plus larger existing body of knowledge/information
- more training courses available
- Integrated with more products for management/production
- Common stack for key Portfolio products
- Portal server, BPM
Reasons to choose Liberty
- Smaller, simpler, faster to set up
- easier to have common development and production runtimes
- More flexible to install, update and manage
- packaged server ‘master image’ deployments are popular
- Composable, right-sized runtimes
- More choice of deployment environments
- Bluemix, other PaaS, containers
- Liberty on z/OS has higher throughput, lower resource use
- Servers of any edition can be centrally managed (although not clustered)
- Greater management scale with collectives than cells
- Earlier support of new technology through continuous delivery
- Easier version to version migration once using Liberty
This article provided a brief overview of some of the aspects to consider when choosing between traditional WAS and Liberty for application deployment. The full white paper (PDF) provides more detailed information about the differences described here and some additional characteristics to consider when making this choice.