IBM demonstrated their continued dedication to open source recently with the introduction of Open Liberty, an open source implementation of their WebSphere Liberty application server. This new release supports the latest versions of both Eclipse MicroProfile and Java EE APIs for building microservices and cloud-native applications.
First introduced in 2012, WebSphere Liberty was designed to be small and lightweight, and has served Java EE 7 certified applications that are deployed in major platforms such as Docker, Kubernetes, and Cloud Foundry. From the IBM website:
Looking toward the future, we believe the combination of Java, open standards and open source is the best way to enable developers to create amazing applications. So, last year we got together with Red Hat, Payara, Tomitribe, and others to accelerate Java for creating Microservices, and we're taking the next step by creating open source from our MicroProfileTM runtime and Java EE.
This wasn’t their only collaboration. The release of OpenLiberty comes alongside IBM’s announcement of the open sourcing of their own JVM as Eclipse Open J9. Earlier this year, IBM also collaborated with Google and Lyft to introduce another open source project, Istio, a service mesh for monitoring microservices.
Open Liberty, combined with Open J9 and Istio, will serve as a full Java stack for developers to build Java microservices and cloud-native applications. Developers can also take advantage of Open Liberty Tools, a set of lightweight tools for developing, assembling, and deploying apps to Open Liberty, with all Open Liberty repositories available from GitHub.
Alasdair Nottingham, WebSphere and Liberty runtime architect at IBM, spoke to InfoQ about Open Liberty.
InfoQ: How will the Eclipse OpenJ9 JVM and Istio service mesh integrate into Open Liberty?
Alasdair Nottingham: Open Liberty is designed to work with any JVM provided it passes the TCK. At the moment though, Liberty doesn't work with Java SE 9, and Eclipse OpenJ9 only runs Java SE 9. This is something that we are working to address. Since Eclipse OpenJ9 is based on the IBM JVM when it and Open Liberty support the same Java SE versions, they will work very well together. In our experience, the J9 JVM technology has a much better memory footprint and startup time than Hotspot for Open Liberty workloads.
Istio has been designed to support multiple runtimes supporting different languages in a Docker and Kubernetes environment. The way they do this is by acting as a mediator between the runtime and the outside world. This means that you can get capabilities like service selection, service timeout, retry and circuit breaker function in the event of failure without making application code changes.
The architecture makes it very easy to run Open Liberty and Istio together. Open Liberty also supports the Eclipse MicroProfile Fault Tolerance specification which provides API's into the application for similar fault tolerance patterns, and you can choose between Istio or writing Java code to do a lot of it. The Open Liberty runtime can also disable the fault tolerance capabilities that are also in Istio through configuration when running with Istio, so you don't get application code and Istio configuration trying to do the same thing.
InfoQ: How much influence does MicroProfile have with development with Java EE 8 and/or vice-versa?
Nottingham: Java EE 8 is an important, but fairly constrained update to Java EE, while the Eclipse MicroProfile project has been looking further ahead at what new API's are needed to enhance Java EE for modern application patterns.
I think Eclipse MicroProfile has had a significant effect on the future of Java EE already by demonstrating how quickly progress can be made in the Eclipse Software Foundation - and the new EE4J charter recognises that MicroProfile will influence the evolution of EE as EE itself moves to Eclipse.
InfoQ: What was your experience in working with Red Hat, Payara, and Tomitribe over the past year to accelerate Java for creating microservices? Will there be continued collaboration with all of them?
Nottingham: It has been a really productive collaboration. Although the move to Eclipse was a steep learning curve for everyone, the work on MicroProfile 1.2 has been astounding. Everyone really pulled together to get it out for JavaOne. It has been really interesting to watch and participate in.
There will absolutely be a continuation of the collaboration going forward. It is critical to the success of the Eclipse MicroProfile project as well as the future success of Eclipse Enterprise for Java.
InfoQ: How will the new six-month Java release cycle affect development and subsequent future releases of Open Liberty?
Nottingham: What effect the accelerated release cycle has on Open Liberty will really depend on what changes go into the JVM. In our experience, the thing that tends to make adoption new Java SE versions take time is updates to the bytecode version.
Java EE relies heavily on processing and weaving the Java bytecode, so when a new version comes out it takes longer to adapt to that. If bytecode version changes with every release with a six-monthly release cycle, that will be hard to keep up with. In the past, it has taken around six months to adapt to support new Java SE versions, which isn't ideal. I'm hoping that byte code changes won’t be so frequent though.
InfoQ: What makes Open Liberty unique over other application servers?
Nottingham: There are a few things that make Open Liberty unique -- the first is the simple configuration. We tried very hard to ensure that the configuration was very easy and simple to use, and used a configuration by exception approach. It is also designed to be checked into version control systems, which is really good for dev/ops flows because you can keep the configuration and code in the same place. The other thing that makes it unique is our approach to making the application server have exactly the right function for the application and nothing more.
Open Liberty was designed from the ground up to allow only the function required to be run in the application server, we call the unit of function features. We have fine grained features for all the Java EE and MicroProfile function, so if you only need a small number of features, you can create a very small and fast server runtime.
InfoQ: What’s on the horizon for Open Liberty?
Nottingham: In terms of function, we are working on Java EE 8. If you look at the GitHub repository, we have been working on Servlet 4, JAX-RS 2.1, JPA 2.2, JSON-B and JSON-P. The other features are coming.
We are also very engaged with Eclipse MicroProfile and Open Liberty supported the Eclipse MicroProfile 1.2 release when we created the project. Our development team is also involved in the new Eclipse Enterprise for Java (EE4J) project, so I expect us to provide an implementation of that when it comes out. Oh and Java SE 9 support as well.
Holly Cummins, technical lead of IBM’s Bluemix Garage London and former delivery lead for the WebSphere Liberty Profile, also remarked on her experience with OpenLiberty:
I'm personally proud of the work we did with Liberty, and it's exciting to see it’s available on GitHub. Open Liberty has some great features because it's modular and dynamic. Running locally, as well as application hot reloading, entire parts of the server can be added and removed or reconfigured, without a restart. Running in the cloud, the modularity means no disk or memory footprint is wasted on function that isn't being used. I like the clear and consistent configuration as well.
One of the interesting things about Liberty was that it was the first application server to be run on a Raspberry Pi (and then we got a bit carried away and got it running on our Android phones as well). Paradoxically, the same characteristics that made it suitable for small-scale Raspberry Pi deployments make it an excellent choice for large-scale cloud-native deployments.
