Managing Service Brokers in CF

The existing CloudFoundry architecture includes a layer to support "Service Brokers".

CF Components

As such, CF includes a registry to manage "Service Broker" implementations. You can use this registry to configure the availability of services (including plans within a service) to different organizations. This is among the things that makes CloudFoundry a very powerful platform. I wrote a simple broker that should give you a quick overview of how to use it with CF. This is found here:

https://github.com/albertoaflores/dummy-cf-service-broker

Deploying Ozone on CloudFoundry

The Ozone Widget Framework (OWF) is a set of tools to enable "widgets" in the UI to communicate to each other. I must admit that the framework (or platform) was an early approach to projects such as "Rave" or "Wookie" (Apache), yet I've been asked if CloudFoundry supports it. While my experience using OWF has been somewhat painful, I noticed that an OWF deployment requires a server that is "optimized" for its deployment.  As such, OWF can work on CF using the "buildpack" feature. I suspect you can argue that OWF can be re-written as a web application component to work with the "standalone" java buildpack, however such work is beyond the scope of this post. This post describes what I had to do to create the "ozone-buildpack" to get this working.

Vagrant Script: BOSH CLI environment

I just published a Vagrant file (and configuration) for whoever wants to start picking up some BOSH CLI and/or CF CLI development. I'm experimenting with BOSH, so I figure I'll share my config. This is found here:

https://github.com/albertoaflores/vagrant-dev-base

I hope others find it useful.

Just do a vagrant up and you are good to go.

Personal Notes: Tokens for the CloudFoundry API

In using CloudFoundry, I find myself using the CLI more often than not. This works for me very well because I enjoy using CLIs more often than not, however some things can also be done with scripting.

CloudFoundry introduces a REST API available to your installation. This is found here. One of the things you'll notice quickly is that one of the headers has to have an "authorization" token. This can be obtained by running the command:

cf oauth-token

The results can be added to the curl commands as described in the API docs. So that means that something like:

curl "https://$DOMAIN_URL/v2/apps" -X GET \
     -H "Authorization: $TOKEN"

where $DOMAIN_URL is your CloudFoundry API Endpoint, and $TOKEN is whatever is returned by the cf oauth-token command.

Of course, if you simply prefer to make straight calls to the API, you can use the cf curl command which adds these headers to your HTTP request for free (pending authentication to your given CF instance). So for the example above, you'll have something like this:

cf curl /v2/apps

I'm looking forward to experiment with other CF components shortly such as BOSH.

Spring Boot and CloudFoundry

In this post, I'll discuss my experience with Spring-Boot, how its features are making my "rapid prototyping" abilities shine (making me look good) and combined with a nice PaaS such as CloudFoundry, you can finally see how a true "agile" practice can focus on "innovation".

I added most of a sample code for this in a github repo. Feel free to use it and ping me if you need help or have questions:

https://github.com/albertoaflores/uspto-sample-app