I’ve mentioned Cloud Foundry v2 a few times before (here, here, and here), but I wanted to really get my hands dirty with the new bits and pieces before I wrote about it. Andy Piper wrote about CFv2 a bit on his blog, in which he outlines the major features to users of CF. I wanted to dig a bit deeper into the major changes in some of the components that make up CFv2.

I’ll admit, there was another reason I got excited about nise_bosh. Not only did it give me the oppertunity to set up Cloud Foundry v2 with ease, a first for me without access to a full BOSH environment that didn’t involve me paying out of pocket, but I also saw it as my oppertunity to get back into developing BOSH releases. This meant I needed a quick way to iterate on BOSH releases and test them.

I mentioned nise_bosh in my previous post, albeit in passing. This is a topic, however, that deserves it’s own blog post.

nise-bosh is the product of NTT, the world’s leading telecom headquartered in Tokyo, Japan. From the nise-bosh GitHub repo…

Nise BOSH is a lightweight BOSH emulator. You can easily install multiple BOSH packages on your servers by Nise BOSH commands. ‘Nise’ means ‘Pseudo’ in Japanese.

In short, it aims to take standard BOSH releases, and allow users to install and run jobs without any instance of BOSH.

NOTE: The referenced tweet has since been deleted

The above tweet summarizes a very productive and exciting lunch I had today, in which after getting CF v2 working last night thanks to nise_bosh, I started reading about buildpacks.

To summarize buildpacks, taken straight from the Cloud Foundry documentation…

Buildpacks are a convenient way of packaging framework and/or runtime support for your application. For example, Cloud Foundry doesn’t support Django or Python by default. Using a buildpack for Python and Django would allow you to add support for these at the deployment stage.