IBM has just announced it is joining the Cloud Foundry project and making it a component of their open cloud architecture. VMware and IBM has jointly announced a series of actions to further engage the community in Cloud Foundry.
A guest blog by Rachel Reinitz, an IBM Distinguished Engineer in IBM Software Services
As one of the IBMers who have been engaging with VMware, I’ve really enjoyed the collaboration and certainly learned a lot. So, I’d like to tell you about the IBM/VMware collaboration around developing an IBM Java and Liberty buildpack.
Buildpacks offer Great Potential
A key part of the Cloud Foundry architecture is the use of buildpacks to specify and compose runtime environments for a class of applications. Cloud Foundry has adopted buildpacks from Heroku. We want to collaborate with VMware, Heroku, and the Cloud Foundry community on adding to the specification of buildpacks to ensure portability of buildpacks across PaaS offerings that support them and add more features.
I like how the buildpack model addresses the complexity of runtime composition for modern applications. There is elegance and simplicity in having the buildpack provider collect and configure the runtime executable as a logical unit for executing a class of applications. I think buildpacks will resonate with enterprises setting up their own PaaS environments as the means of controlling their environments, in addition to the benefits of easy deployment for developers. What is also great about buildpacks is their extensibility, which we discovered first hand. You may think of buildpacks as being language runtimes but they can be used more broadly. For example, we envision buildpacks with specialized frameworks for mobile or business rules. These specialized buildpacks will include the necessary runtimes; for they would be bundled with IBM Java and the IBM WebSphere Application Server Liberty Core (IBM Liberty for short).
New Preview Buildpack for IBM Java and Liberty
We have developed a new buildpack that includes IBM Java and the WebSphere Application Server Liberty Core . From IBM we have had Ben Smith and Michael Fraenkel working with the VMware Java buildpack team, Ben Hale (yes the multiple Bens gets confusing), Glyn Normington, and Ryan Morgan. It has been a terrific, enjoyable collaboration. Ben Smith sat with Ben Hale and tested out the extensibility instructions for the latest, updated Java buildpack. It was a win-win as the recently updated documentation was improved and the initial IBM Java/Liberty buildpack was developed quickly.
A preview of the Liberty buildpack is available for POCs in private deployments of Cloud Foundry. We’re also working to make the preview Liberty buildpack more broadly available for developers as well as enhancing the buildpack, so stay tuned.
One of the environments we have made the Liberty buildpack preview available is in IBM’s implementation of our open cloud architecture (which is built on Cloud Foundry and OpenStack), something we call Project BlueMix. We are starting POCs with clients on Project BlueMix, where they can explore the preview Liberty buildpack and new services based on IBM’s software capabilities.
My role in Project BlueMix is to lead client POCs and drive definition of our new services, buildpacks, and contributions to Cloud Foundry based on those client experiences. I’m also the focal point for the WebSphere team working with VMware and frequently spend time at the very nice VMware SF office. You can learn more and get started with us at http://www.ibm.com/bluemix or email me, [email protected].
Why IBM Java and Liberty?
So why would a developer want to use IBM Java or the WebSphere Liberty container? IBM Java has lots of improvements over other JREs, but the main advantage it has in a Cloud Foundry context, is that it is really, really fast. That may not matter for some apps, but for others you will want the speed.
WebSphere Liberty is built to be a lightweight, modular, dynamic app server, particularly for cloud applications. Liberty has composable features for Java EE Web Profile and OSGi applications along with a simple configuration to provision only those required by the deployed application. We can minimize what is loaded to just those features needed by an application. Liberty has a simple XML configuration model and has rapid start times (well suited for cloud).
Up Next
Beyond making IBM Java/Liberty buildpack more widely available and iteratively add more features based on client POCs, we want to collaborate with the community on expanding support for buildpacks for Java and beyond. Topics we are interested in include ease of extending a buildpack, how to best handle versions and updates, dynamic service bindings, configuring default buildpacks for organization and spaces, improved debugging and logging, and support for commercialization of buildpacks in public cloud environment. I look forward to lively buildpack discussions as one of the topic areas at Platform Cloud Foundry conference, Sept. 8-9.
About the Author
Rachel Reinitz is an IBM Distinguished Engineer in IBM Software Services. She works with clients on adoption of new technologies and is currently focused on applications and services on PaaS and adoption of API Management. Her email is [email protected] and you can follow her @rreinitz.
