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.

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

Real PaaS: CloudFoundry

During the last few years in Software Development, I have found myself doing very repetitive tasks regarding deployment of applications. Among them, these are:

• Provisioning of Hardware (or VM)
• Install Application Runtime (Java, Rails, Node, etc)
• Deploying of Binaries (War file, Processes, etc)
• Load Balancer Configuration
• Security Configuration (SSL, Documents, etc)
• Ensure Service Connectivity to external systems (databases, enterprise logs, auditing, etc)
• Update Firewall policies and documentation.

I have scripted most of these in many ways (particularly using Bash,  Puppet, Monit, etc). Most of these are not only done by me, but also prevent me from doing actual real work (developing solutions). If you find yourself in this situation, I'd like to introduce you to CloudFoundry, a PaaS project I have been following for some time. I'll plan on adding more entries on these concepts soon so that I can try to document my learning about this great platform.