With the recent addition of the cf create-buildpack and cf update-buildpack commands, we’ve been looking into changes to how the Java Buildpack is deployed on Cloud Foundry. There is a move afoot to remove the buildpacks from the DEAs in favor of using those commands (with an automated initial install to preserve user-experience) and an outcome of this was the need to more easily create ‘packaged’ buildpacks. In the process of delivering these packages we also realized that we could also deliver “offline” buildpacks. To understand why “offline” buildpacks are interesting, it helps to understand why the buildpack is designed to look for dependencies on the Internet in the first place.
The Church of Jesus Christ of Latter-day Saints (LDS Church) is a really large organization with even larger reach – probably much more than most of us realize. Sure, you probably know about the massive genealogy library and databases that they have, but it’s so much more. In my cursory research I found that they have numerous humanitarian programs, benefitting people around the globe with health services, drilling wells for safe water, disaster relief, educational services and more.
Why am I telling you all this? Because, just like in virtually every other industry Software is Eating the World; the mission of the LDS Church is greatly enabled and supported through technological innovation and application.
The quintessential story for platform as a service is that the developer needn’t perform a bunch of administrative functions just to start working on their code. Have a look at the installation instructions for the developer-targeted Spring Trader reference implementation for a pre-PaaS deployment experience. In a PaaS, this lengthy guide is replaced with one command each to provision a database and a messaging service, and then another command that deploys each part of the application with bindings to these services.
Service brokers are what make this provisioning and binding happen with ease, and today we are delighted to report that Cloud Foundry partner, SAP, has open sourced a new Cloud Foundry service broker for their SAP HANA database.
This last weekend I had the tremendous pleasure of spending it with the incredibly bright, creative and inventive students of Georgia Tech. The occasion was a “hack for good,” an intense 24 hour code-cutting marathon where the participants were challenged to use their talents to conceive, design, build and demonstrate applications that would be used to help combat the growing epidemic of childhood obesity we are facing in this country. This was a part of the Intel “code for good” program and because I had met Professor Matthew Wolf when I participated in the hackathon that was a part of the IDF, he had invited Pivotal to play a part, allowing us to provide the PaaS that the student projects would be hosted on.
When I speak with customer prospects about Cloud Foundry, I don’t start with networks, servers, VMs and build my way up a stack of abstractions, instead I ask them how they will change to compete in an industrial era increasingly defined by software. Refactoring their entire mindset away from IT management to becoming a high performance software factory is job-one of any briefing I give.
Enterprise PaaS delivers a next generation platform to answer this challenge. Leaving the legacy of custom VM, middleware and server orchestration behind can sometimes be uncomfortable for traditional IT buyers, but it is captivating to business oriented leaders looking to transform their organizations.
First a little background, and then a story. As Matt described here, Cloud Foundry BOSH has a great capability to perform rolling updates automatically to an entire set of servers in a cluster, and there is a defensive aspect to this feature called a “canary” that is at the center of this tale. When a whole lot of servers are going to be upgraded, BOSH will first try to upgrade a small number of them (usually 1), the “canary”, and only if that is successful will the remaining servers in the cluster be upgraded. If the canary upgrade succeeds, then BOSH will parallelize up to a “max in flight” number of remaining server upgrades until all are completed.
And now the story.
For the last few weeks I’ve been pairing on the Cloud Foundry development team here at Pivotal.
A couple of weeks ago, Ben Hale blogged about the new Cloud Foundry Java Buildpack, highlighting some great new features and our design principles – the “it just works” experience.
The new buildpack provides the opportunity for a new level of configuration and setup for popular add-on services, such as application performance and monitoring tools. The Java buildpack now includes automated configuration for the New Relic application monitoring agent. If you create a New Relic service and bind it to an application, the buildpack will set up the New Relic agent automatically when the application is staged.
Buildpacks are at the core of the Cloud Foundry architecture and we’ve recently made significant improvements to the Cloud Foundry Java Buildpack. As the lead developer of the buildpack, I’d like to give you some insight into the design principles behind it, how to use, configure, and extend it, and what the future holds.
The primary objective of the Java buildpack is to be the easiest way to run a Java application.1 The word easiest can mean a lot of things, but to me it means that a developer can push an application and have an “it just works™” experience. An application developer shouldn’t have to mess about with details like memory settings or configuring the container to work with a bound service.
In early March we introduced our vision for the Cloud Foundry Open Platform-as-a-Service project at Pivotal, and laid out a strategy of furthering our broad ecosystem with deep engineering partnerships with external organizations.
“Adding full-time external committers has always been a goal of the team, and we are engaged with several organizations around putting dedicated resources on the extended engineering team”
As of today’s major collaboration announcement with IBM, we can now be explicit about one of the organizations we were already working with in March. Working with IBM and other external organizations over the last several months we have learned more about what it will take to scale our thriving community.
IBM has just announced it is joining the Cloud Foundry project and making it a component of their open cloud architecture. Pivotal 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 Pivotal, I’ve really enjoyed the collaboration and certainly learned a lot. So, I’d like to tell you about the IBM/Pivotal 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.