IBM is contributing the IBM WebSphere Liberty Buildpack today as further proof of its commitment to make the Cloud Foundry open source project and community even stronger.
A guest blog by Rachel Reinitz, an IBM Distinguished Engineer in IBM Software Services
In late July, I wrote a guest blog here about our development of a preview IBM WebSphere Liberty buildpack. I’m delighted to announce we have contributed the WebSphere Liberty Buildpack to the Cloud Foundry community. It now has its own Cloud Foundry GitHub repo, ibm-webphere-liberty-buildpack.
Importance of Buildpacks
Buildpacks can provide a complete runtime environment for a specific class of applications. They are key to providing portability across clouds and contributing to an open cloud architecture. We want to see the community and capabilities of buildpacks expand. The WebSphere Liberty Buildpack is our first contribution to the community … more will be coming.
We are working with Pivotal on enhancements to Cloud Foundry for buildpack management. Some of the features we are excited about are: easily adding a buildpack onto an existing Cloud Foundry install, insertion of binaries directly into the buildpack cache, visibility and sequencing of buildpacks, and support for commercial buildpacks. Michael Fraenkel, lead developer on the Liberty buildpack has submitted a related pull request.
So What’s in the Liberty Buildpack?
Ben Hale recently wrote a terrific blog on the Java buildpack. We followed the same design principles, starting from a fork of the Java buildpack code. The Liberty buildpack provides IBM’s WebSphere Liberty container for web and OSGi applications with Java EE Web Profile capabilities, supports popular frameworks like Spring and includes IBM’s JRE. WebSphere Liberty enables rapid application development well suited to the cloud.
The Liberty buildpack supports multiple applications deployed into a single Liberty server. As part of the Liberty buildpack integration into Cloud Foundry, the buildpack ensures environment variables for binding services are exposed as configuration variables in the Liberty server.1
Why WebSphere Liberty is a Great Java Container for Cloud
Back in 2011, we took the power of WebSphere Application Server, redesigned the server to be small, lightweight, composable, with simple configuration, and included the WebSphere Liberty Profile as part of our WebSphere Application Server V8.5 product. Our primary use cases were providing a simplified development environment and targeting cloud deployments.
The philosophy and design of Cloud Foundry is basically the same as WebSphere Liberty’s – simplify developers’ lives by requiring minimal configuration and only loading into the server what is needed for a running application. A modest web app running in the Liberty server starts in 2 seconds.
WebSphere Liberty provides runtime capabilities through individually configurable features for Java EE and OSGi technologies like servlet, JSF, JPA, local EJBs, JAX-RS, OSGi web bundles and more. You configure only those features you need in the Liberty server.xml file.2
The Cloud Foundry buildpack architecture allows WebSphere Liberty applications (new or existing) to be run on any Cloud Foundry V2 based public, private, or even hybrid cloud.
You can learn more about WebSphere Liberty, such as this article on how WebSphere Liberty compares with Tomcat, at our community site, WASdev.
Options for Using the Buildpack
The Liberty buildpack is Apache 2.0 licensed as part of Cloud Foundry. The buildpack uses IBM WebSphere Liberty for its runtime, which has IBM commercial licenses for development or production use.
We want to make it very easy to install and use the Liberty buildpack, but we face two challenges. Because of the licensing, no public URLs for the Liberty and IBM JRE binaries exist that we can put into the buildpack. Also, Cloud Foundry today doesn’t make it easy to add a commercial buildpack, but I’m confident buildpack installation will improve rapidly. See the Liberty buildpack documentation/video for details on setup.
So there are currently 3 options for using the buildpack:
- Using
cf push --buildpack. - Add the Liberty buildpack as a default buildpack into your Cloud Foundry instance.
- Look for (and ask for) Liberty buildpack to be provided as a default buildpack by the public Cloud Foundry you use. It currently isn’t available on any public hosted instances today, but that will change, stay tuned.
Support for the buildpack is available via the WASDev forum or vcap-dev mailing list. Our buildpack developers are standing by to answer your questions. Contact me if you would like direct support.
Next Steps
One focus area for us is to work with clients on use of the Liberty buildpack for not only new, but also existing applications. A key design point for WebSphere Liberty is to ease migration of WAS applications to cloud environments. Liberty supports the most widely used subset of Java EE features, but not all, so ease of migration will vary. Many stateless web applications will be able to run unmodified in the cloud. Applications that use features such as session state and that access local files may need to be modified so that they can be scaled horizontally by Cloud Foundry.
We are developing services which ease migration. Our first is an elastic cache service based on WebSphere eXtreme Scale that provides session management for Liberty applications without requiring application changes. We have been busy migrating some of our own applications and services to use the WebSphere Liberty buildpack in our BlueMix environment, and we will certainly share our experiences in a future blog post.
We have a set of features we are investigating to enhance the buildpack to further simplify Java developers’ lives, particularly what developers need to do to connect to and consume services. We welcome the community’s input as to which of these features are most important to you.
- Simplifying the setup of buildpacks – short and long term options.
- Improving the auto-configuration of Liberty when pushing web applications.
- Auto-reconfiguration of Java EE references to cloud resources.3
- Minimizing the size of the droplet by packaging only the subset of Liberty features used by each individual application.
- Add capability in the Liberty Eclipse tools for remote development and testing of applications pushed to Cloud Foundry without having to leave the toolset.
- Support IBM’s WebSphere Liberty Log Analysis Service (not yet available but being demoed at Platform) to automatically redirect access logs, application logs, and Liberty messages to the Log Analysis Service.
- Support in the buildpack for additional IBM, 3rd party, and open source services and frameworks leveraging the existing Liberty community assets
We are very excited to be contributing our first IBM project to Cloud Foundry. We are working with Pivotal and the community to make Cloud Foundry even stronger. I want to emphasize that we welcome pull requests on the buildpack. We will also be making our tracker project public soon.
Giving Credit Where It Is Due
Confession time, now that you have read this far – I am not a Liberty specialist. My role in IBM is to get clients started using IBM BlueMix, powered by Cloud Foundry, and drive product direction based on client feedback. Clients have been asking Pivotal and us for WebSphere Liberty Support, so I led a team to make it happen. Now our Cloud Foundry community and Liberty development teams will be taking over and I’ll be focusing on the next framework, buildpack, or service our clients need.
So I’m the scribe. Ben Smith, Michael Fraenkel, and Matt Sykes developed the buildpack. Getting the buildpack contributed and keeping me honest on the technical details in this blog was done by them and Ravi Gopalakrishan, Adam Gunther, Brian De Pradine and Ian Robinson. And providing critical support was Chris Ferris, IBM’s Cloud Foundry community leader and Jerry Cuomo, WebSphere CTO, who makes work like this happen. Also thanks to Ben Hale, Ryan Morgan, James Bayer, and James Watters at Pivotal for terrific collaboration.
Look for information coming out of Platform this week and come to the next one!
- The buildpack will convert VCAP_SERVICES and VCAP_APPLICATION into configuration variables for the Liberty server. The variables end up in runtime-vars.xml, and are therefore referenceable from a pushed server.xml, for example ${vcap_app_port}: The port where the app server is listening (usually the same as ${port}). ↩
- An example of dynamic composability is if you write a servlet and JSP web app, deploy it and later wish to update the app to start using another JEE library, say JAX-RS. Now you just add JAX-RS as one line in the server.xml file and the JAX-RS libraries in the Liberty binary are loaded into memory. ↩
- Unless the user opts-out, we’ll perform the acquisition and configuration of drivers needed to access services that have been bound to the application. For example, if an application is bound to a database supported by the buildpack, we will ensure that a DataSource for the service will be bound into JNDI ↩
