Cloud Foundry on VirtualBox

There are a lot of ways to build and try Cloud Foundry, but the easiest (and most cost-effective) I found so far is to use the Nise Installer.

The installation process:

1. Install VirtualBox 
2. Download Ubuntu Server 10.04 LTS 64 bit
3. Create a VM with at least 10GB disk and 4GB memory
4. Leave the first network adapter NAT-ed (for internet access)
5. Make a second adapter that is Host-only (for host OS access)
6. Install Ubuntu Server
7. Install curl
8. Launch the bootstrap.sh script (as documented on the Nise Installer page)
9. Restart the VM to get the new kernel in place 

If you are lazy go get the already created VM image from my Google Drive. 


To start the Cloud Foundry instance:

1. Go to cf_nise_installer directory
2. Launch CF with ./scripts/start.sh 

You may need to relaunch the script or stop/start again in case some of the components failed.


To access the Cloud Foundry instance:

1. Get the IP of the VirtualBox Host-Only Ethernet Adapter with ipconfig /all or ifconfig -a
2. Add a route from 10.0.2.15 to the IP of the VirtualBox Host-Only Ethernet Adapter. 
   
   For example in Windows that would be:  
route add 10.0.2.15 192.168.56.101  
   
   , where 192.168.56.101 is the IP of the Host-Only adapter.
   
   
3. Install CF CLI on your client machine
4. Login to the CF instance using the login command provided at the end of the start via
   the ./scripts/start.sh script

To create organization and space you can use:

cf create-org me
cf target -o me
cf create-space development
cf target -s development

You are ready to push an app and have fun.

SAP HANA Cloud: OpenSocial widgets auto-discovery and operation

Recently we added functionality that enables deployment of OpenSocial widgets and their auto-discovery in SAP HANA Cloud Portal. 

As Wikipedia states:

OpenSocial is a public specification that defines a component hosting environment (container) and a set of common application programming interfaces (APIs) for web-based applications. Initially it was designed for social network applications

You can check the developer guide for OpenSocial widgets in the Portal for more information how to create such widget. 

There is also a short topic on how to package the widget which notes that your spec.xml needs to be:

• publicly accessible resource
• named so that it ends with the .spec.xml suffix
• with name, description and thumbnail that will be shown in Portal Content Catalog

Deploying & running your widget as SAP HANA Cloud application allows you to use the Portal auto-discovery. This means that when your application is started successfully on the HANA Cloud, it will be visible in the Portal Content Catalog, so you can build a site with such widgets.

Soon you should also be able to deploy Cloud Portal sites with the widgets layout you created. Of course we will also be able to do auto-discovery for them as well.

The widgets has to be running and accessible no matter if hosted or not in SAP HANA Cloud. This is needed so the Portal can fetch the spec.xml from the publicly accessible URL of the widget application.

Since widgets and sites are relatively small, they will make small application packages (WAR files). To run several widgets you may need several compute units and you may need to pay for all of them.

However there is a way to combine several small WAR files and run them on a single compute unit as a single application. 

Just copy all WAR files in one directory and use the Command Line deploy command to deploy the whole directory. As the documentation of deploy command states you can use the --source parameter to provide:

a comma-separated list of file locations, pointing to WAR files, or folders containing them

The result will be a single application from SAP HANA Cloud point of view (lifecycle, monitoring, billing), having multiple WAR files running inside.

Please have in mind that all these applications (no matter if widgets or plain Java apps) are running on  the same compute unit and they share the memory, CPU and storage resources of the unit.  

So if you have resource hungry applications, perhaps it is not very wise to save money by increasing the response time (or latency) of your customers.

You can however use this multiple-wars-in-a-single-application approach for development or testing environments, modelled for staged development. 

So use this for testing, but beware the performance impact for productive scenarios.