Guest blog post by: Jose Carrasco, My GSoC 2016

My GSoC 2016

Guest blog post by: Jose Carrasco

This year, I applied for the Google Summer of Code (GSoC) 2016 program with a project called Adding PaaS support to Brooklyn. I had the pleasure to work with Apache Brooklyn Community during the summer. Through these posts, I will introduce my project and the obtained results.

Apache Brooklyn is a top-level project of the Apache Software Foundation. Brooklyn is a framework for modeling, monitoring, and managing applications through autonomic blueprints. It is able to manage provisioning and application deployment, monitor an application’s health and metrics, understand the dependencies between components and apply complex policies to manage the application. The tool provides a REST API and a GUI, and allows the autonomic blueprints to be treated as an integral part of the application.

The objective of  my GSoC project is to add  to Brooklyn the required capabilities to enable the management of Platform as a Service (PaaS) offerings such as  CloudFoundry, Openshift, Google App Engine, AWS services, Heroku.

Once GSoC application was accepted I started to work closely with my mentor, Andrea Turli, to who I am specially grateful, while we received full support of the rest of the community.

Cloud Foundry

After an initial study  figuring out about different PaaS approaches, I identified CloudFoundry as the first candidate to integrate PaaS in Brooklyn for the following reasons:

  • It is a open source project.

  • It provides a most of capabilities expected by a PaaS.

  • It provides a clear API and a set of clients to manage them.

  • Several providers have built their platforms on Cloud Foundry project, Pivotal WS, IBM BlueMix, etc.

  • Brooklyn Community was already working with the Cloud Foundry project.

CloudFoundry Location

Although different from the other locations supported by Brooklyn, Cloud Foundry Service can be modelled as a Brooklyn location.

Based on PaasLocation interface, which allows a Platform-as-a-Service to be specified, we have built CloudFoundryPaasLocation to represent Cloud Foundry Platform, see Figure


Usually a CloudFoundry user can interact with the platform by using the CF cli. Similarly by using CloudFoundryPaasLocation that consumes cf-java-client, a Java binding for the  Cloud Foundry RESTful APIs

The following snippet of YAML represents a  generic declaration of a CloudFoundryPaasLocation:

    provider: <provider name>
    identity: <user's account>
    credential: <user's password>
    org: <an user's organization>
    space: <an organization's space>
    endpoint: <provider api endpoint>

Each configuration corresponds to a Cloud Foundry login parameter, as you can see in the official documentation.

provider: represents the name of the provider, such as pivotal or bluemix
identity:  the user name
credential: the user’s password
org: the organization where you want to deploy your apps
space: the space in the org where applications will be deployed
endpoint: this is your API endpoint, the URL of the Cloud Controller in your Cloud Foundry instance.
So, each Cloud Foundry platform provides its own endpoint.

Here is a CloudFoundryPaasLocation example that references Pivotal Web Services:

    provider: pivotal-ws
    identity: <pivotal-user-name>
    credential: <user's password>
    org: <an  pivotal organization>
    space: <an organization's space>

and another example to point to IBM BlueMix:

    provider: bluemix
    identity: <bluemix-user-name>
    credential: <user's password>
    org: <an user's bluemix organization>
    space: <an organization's space>


Note that the endpoint is fixed for each provider, representing the Cloud Controller of each platform, Pivotal offers its controller in and bluemix by means of


Once location was ready, we thought about how to represent the applications in Cloud Foundry using Apache Brooklyn. Once again, we decided to go step by step, and I developed a first generic entity to represent a Cloud Foundry application, VanillaCloudFoundryApplication similar to VanillaSoftwareProcess, which provides a generic and configurable entity for representing software process. This entity allows an simple application to be described using a couple of parameters, application name, buildpack and application artifact and it requires a CloudFoundryPaasLocation to specify the target Cloud Foundry platform where the application will be deployed. Below, you can find a yaml blueprint which contains a VanillaCloudFoundryApplication sample that represents a java application that will be deployed on Pivotal Web Services.

name: Cloud Foundry Application
    provider: pivotal
    credential: password
    org: gsoc
    space: development
- type: org.apache.brooklyn.cloudfoundry.entity.VanillaCloudFoundryApplication
  id: vanilla-cf

This entity allows an application to be deployed, started, restarted, and removed, offering a total management of its lifecycle.

Live Demo

Conclusions and Next

I think the proposal opens up some interesting questions about the platform’s services integration, user's account management, the add-ons support, etc. Furthermore, the acquired knowledge would allow different technologies to be dealt with, such as Kubernetes or similar.

In the next post we are going to look at the fully Cloud Foundry manifest support for VanillaCloudFoundryApplication. Moreover, we will offer more details about the entity development, explaining used patterns and the ongoing work.


I would like to thank to GSoC organization, Apache Software Foundation and Apache Brooklyn community the opportunity and for the trust placed in me as student. Specially,I  would also use this opportunity to sincerely thank to Andrea Turli his effort and help during this period.