We haven’t provided integration for traditional WebSphere in PaaS environments in the way that we have for WebSphere Liberty. I am sometimes asked whether it is OK to run traditional WebSphere in a PaaS (Platform-as-a-Service) environment.
Liberty is integrated into Cloud Foundry in Bluemix using a build pack that can also be used with your own local Pivotal Cloud Foundry. The addition of a thin wrapper added around that build pack creates the Liberty Open Shift V2 cartridge, which again you can use with your local deployments. Both of these are available as open source as well as fully supported binaries from Fix Central. However, we haven’t provided similar integration for traditional WebSphere in these PaaS environments despite providing ways to run both flavors of WAS in Docker containers; why is that? There are really two aspects to this.
Liberty in a PaaS environment
First, the nature of the Liberty runtime makes it much better suited to a PaaS environment than most Java application servers, including traditional WebSphere. In a PaaS environment, a runtime is a commodity; runtime instances are spun up and down regularly in response to changes in demand and to facilitate failover. Liberty is designed to restart extremely quickly: through using only the features that the application needs and also by delaying initialization of individual services unless/until they are used. This gives Liberty a really fast startup, so in a PaaS it provides faster scaling and faster recovery.
Liberty’s composable nature makes the install footprint small; important when every running instance has its own copy of the binaries. It also provides a small memory footprint, which matters when you are paying by the gigabyte-hour. The simple configuration files are easily created and modified by a build pack or cartridge, and the zip deployment makes it easy to deploy new instances on the fly. That’s not to say that it isn’t possible to run traditional WebSphere in a PaaS; some people are doing this today. It’s just that Liberty is faster, simpler, and smaller so it is a better runtime for a PaaS.
Handling the application restrictions of a PaaS environment
The second consideration is the applications that are targeted for these environments. There are restrictions in a PaaS environment that can limit the deployment of many existing Java applications. By default, the file system under the Java process running in a PaaS is ephemeral, so the application can’t persist data to local files and (more importantly) the server can’t rely on the local XA transaction log files for recovery after a failure. The routers don’t handle IIOP traffic (for remote EJB requests) and the server generally can’t open multiple ports.
These restrictions mean that many people are using PaaS mainly for deployment of new, stateless, ‘cloud-ready’ applications and micro services rather than a new way to manage existing, traditional SOA applications. If you are writing a new cloud application, Liberty is a much better runtime to choose, providing more efficient development and more flexible deployment. If you are modifying traditional WebSphere applications to accommodate the restrictions of a PaaS environment you may find that it is a better investment to move them to Liberty at the same time.
Liberty licensing in PaaS environments
PaaS environments typically provide traffic routing, instance management, load balancing etc. and provide a more generic alternative to the advanced management capabilities of the Network Deployment (ND) edition of WebSphere. In licensing terms, then, you can choose between WAS Liberty Core and WAS (Base) editions to run in a PaaS, depending on the API needs of your application. Liberty Core provides the Java EE 7 web profile, Liberty in Base provides Java EE 7 full profile. Again, Liberty is providing an advantage over traditional WAS by offering a lower cost option if your applications don’t need the full Java EE 7 stack and can thus run on Liberty Core. Liberty in the Bluemix PaaS (Instant Runtimes) has the full API stack.
Think about your investment and long-term strategy
I don’t want anyone to think that they absolutely cannot run traditional WebSphere in a PaaS; if you really want to do that then go ahead. However, before you do so, think carefully about the investment you are making and whether it would be a better long-term strategy to move those applications to Liberty and get a better fit for the technology. Of course, if you’re writing brand new applications then Liberty is absolutely the best choice.