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.
In this guest post, Jake Farrell, CTO for Static.com, explains how the major shift in the hosting industry towards platforms for high developer productivity and data-centric applications led them to build their Platform as a Service using Cloud Foundry with Hadoop support.
Test Static.com for Cloud Foundry Core Compatibility here.
The hosting industry is undergoing a dramatic transformation due to increasing demand for self-service cloud based capabilities. To greet this shift, Static.com, a subsidiary of Catalog.com, is leveraging 19 years of hosting experience, and adopting Cloud Foundry as the foundation for its Platform as a Service (PaaS).
Cloud Foundry is an Open Platform-as-a-Service, and an Open Source project. It has attracted phenomenal interest from the community – including partners, companies using the code internally, and those individual developers with a passion for getting involved. You can find the source code on Github. Community contributions are what help to make the platform so extensible. We are always happy when we receive a Github pull request to offer new functionality or fixes! We also appreciate bug reports submitted through Github Issues.
Looking at the Cloud Foundry project as a whole though… where should you start?
As you might imagine, there are a lot of moving parts in a PaaS.
For Comic Relief – a UK based charity, fifty minutes of downtime during peak fundraising hours could result in half their annual online donations income being lost. This blog describes how Cloud Foundry was used to provide an Enterprise grade donations platform that helped Comic Relief raise a record £75million (about US $115 million) in funds for their humanitarian projects.
Guest Blog by Colin Humphreys, CloudCredo, Inc.
Comic Relief is a well known charity based in the UK which strives to create a just world free from poverty. They raise millions of pounds through two big fundraising campaigns – Red Nose Day and Sport Relief. The money raised is spent in the best possible way to tackle the root causes of poverty and social injustice.