Guest author Ben Hale is the Java experience lead at Pivotal’s Cloud Foundry®, working on all aspects of Java applications running on its open-source Platform-as-a-Service. He has 15 years experience working in and with Enterprise Java companies.
More and more, developers want to see their applications running in production immediately after they’re built. Platform-as-a-Service (PaaS) providers have stepped in to take the pain away from configuring apps to run in the cloud. Buildpacks streamline that process from the developer perspective by defining how an application is deployed and making sure that “it just works”.
At Pivotal®, we’ve worked to give developers that same experience for Java apps running on Pivotal Web Services (PWS) with our Java Buildpack, released just over a year ago. PWS is Pivotal’s hosted version of Cloud Foundry®, an open-source PaaS, and we make sure that your favorite third-party services are equally as easy to set up on it. To that end, the Pivotal team designed the Java Buildpack to allow for “zero-touch” configuration and setup for popular add-on services, such as New Relic’s application performance and monitoring tools.
As a result, using New Relic for your Java app on PWS is easier. If you sign up for New Relic and bind it to your Java application on PWS, the buildpack will set up the New Relic agent automatically when the application is staged, and metrics will show up in your dashboard once traffic gets flowing. This way, the buildpack saves you the usual steps of copying and pasting New Relic’s agent and configuration into your deployment. All you need to do is clone, build, and push your application to let New Relic start monitoring! New Relic standard is available free of charge on PWS so it’s easy.
How the Java Buildpack works
At a high level, the Java Buildpack takes a WAR file (or any other JVM deployment artifact) and makes it work in the cloud. First, it sets up a cloud instance by grabbing a Java Runtime Environment (JRE), Tomcat, New Relic’s agent, and the app configuration. Then it starts up the JRE with the correct command line for the options and services the developer has picked. The buildpack is able to configure the JRE based on our in-depth knowledge and experience around running Java apps at scale.
One of the biggest benefits of using the Java Buildpack is that it makes it easier to stay up-to-date and safe with the latest versions of dependencies like the JRE, the New Relic agent, and more.
For a full look at the details and design principles behind the Java Buildpack, you can take a look at the post I wrote when it was first released.
Extending the Java Buildpack
The existence of add-on services like New Relic was a driver in making it easier to extend the buildpack in general. Now, extensibility is one of the Java Buildpack’s main draws, and it works with many of the frameworks you’re already using in the Java ecosystem (Tomcat, Spring Boot, Grails, etc). To give you a sense of just how easy it is to extend, in one recent test adding New Relic to the buildpack took less than four hours and roughly 25 lines of code.
The Java Buildpack also has over 300 forks on Github. These forks change everything from JRE versions and configuration to adding completely new frameworks to the buildpack. You can use your own buildpack with the
--buildpack option of the
cf push command, e.g.
cf push --buildpack https://github.com/cloudfoundry/java-buildpack.git. As mentioned, the Java Buildpack is on Github. We at Pivotal welcome comments and pull requests from users!
Screenshot from Monitoring Cloud Foundry Applications with New Relic.