Cloud Foundry Blog

About Ramnivas Laddad

Ramnivas Laddad is a well-known expert in enterprise Java, especially in the area of AOP and Spring. He is a Spring Framework and Cloud Foundry committer. Ramnivas is also the author of AspectJ in Action, the best-selling book on AOP and AspectJ that has been lauded by industry experts for its presentation of practical and innovative AOP applications to solve real-world problems. He has spoken at many leading industry events including JavaOne, JavaPolis, No Fluff Just Stuff, and SpringOne. Currently he leads a group at VMware that focuses on enterprise and developer experience for cloud computing. In recent years, Ramnivas has become a Scala fan. You can follow him on twitter.

New Release of Micro Cloud Foundry

We are excited to announce a new version of Micro Cloud Foundry™ with a new set of features. Among those new features is a new process to streamline frequent updates so that we can maintain compatibility between Micro Cloud Foundry and any Cloud Foundry-based clouds, including CloudFoundry.com.

If you don’t have a Cloud Foundry
account yet, sign up here.

Micro Cloud Foundry is a complete version of the Cloud Foundry open PaaS, but it runs in a single virtual machine on a developer’s computer. Micro Cloud Foundry exemplifies how a multi-cloud approach to PaaS can help developers easily develop and test their applications locally and deploy to any Cloud Foundry-based clouds with no code or configuration changes.

Download the new Micro Cloud Foundry here.

In this blog, we will review notable new features and focus on how we will be releasing Micro Cloud Foundry going forward.

What’s New

We have a new Micro Cloud Foundry for you to download. Since the release of the last version (1.2), there have been many new features that have been implemented for Cloud Foundry. Now these features have been made available on Micro Cloud Foundry. Let’s review some of them:

  • Standalone apps support: This feature enables a new class of apps including background apps such as Resque workers, apps with bring-your-own-container, and Spring background tasks.
  • Enhanced Ruby support: While Cloud Foundry always offered auto-reconfiguration for relational databases for Ruby apps, we’ve since extended it to all service types, enabling many more applications to deploy to Cloud Foundry without changing a single line of code. We now also offer improved support for Rails 3.1 and 3.2 apps, Rack as a supported framework, the ability to run JRuby apps, and apps that specify git URLs in their Gemfiles along with numerous small improvements to make a much wider range of applications work well in Cloud Foundry.
  • Enhanced Java support: Java 7 support, which enables applications such as vert.x and containers that need NIO such as Netty.
  • Enhanced Scala support: We now offer explicit support for Play 2.0. You can also deploy apps using a Scala framework such as Unfiltered that requires Jetty and Blue Eyes that additionally requires the NIO support in Java 7.
  • Enhanced Node support: We took a comprehensive look at our Node.js support and made a series of improvements to make Node.js apps shine. We now offer NPM support, bringing it up to par with the Gemfile support for Ruby apps including support for packages specified as git URLs. We also offer auto-reconfiguration of all services for node.js apps.

Download the new Micro Cloud Foundry from the download site. While there, you may notice a few changes, especially the availability of multiple versions and curiously new version names. Let us explain what they mean.

Going Forward

One of the ways developers use Micro Cloud Foundry is to deploy applications during development, where Micro Cloud Foundry is used as proving ground. Rather than installing a web server (Tomcat, etc.), runtimes (Java, Ruby, etc.), and services (Postgres, MongoDB, etc.), you can do a single download of Micro Cloud Foundry, boot it up, and deploy your applications using ‘vmc push’. You can run Java and Node.js apps in debug mode, take advantage of JVM hotswap to obviate the need to restart apps after changes, use a shell to access applications and services in the Micro Cloud Foundry VM, and so on. And you could do all this without even being connected to the network thanks to the offline capability of Micro Cloud Foundry (allowing you to develop apps for the cloud while flying through the clouds!).  Once you have your app working, you can push it to CloudFoundry.com, your own in-house Cloud Foundry cloud, or one of Cloud Foundry’s multi-cloud partners.

For all of this flow to really work, it is imperative that Micro Cloud Foundry has the same functionality as CloudFoundry.com. This means we must continually update Micro Cloud Foundry to keep up with all the new improvements in the core code. Our manual process of building and testing the Micro Cloud Foundry VM simply wouldn’t be up to the task. So we took a hard look at how to make this a better process, starting with this release.

This is how we will proceed:

  • Frequent releases: We will now release Micro Cloud Foundry whenever a change is pushed to CloudFoundry.com (subject to passing automated testing). If you track the cf-release repository, you will see it tagged with a release version such as v116, v114, and so on. Micro Cloud Foundry versions will match the same tags (along with a timestamp) so you can tell if you need to update Micro Cloud Foundry in order to catch up with changes in CloudFoundry.com. Since the launch over a year ago, we have been updating CloudFoundry.com about twice a week so you can expect a new Micro Cloud Foundry release at the same frequency. Later, we will consider releasing even more frequently for those who want to stay on the bleeding edge.
  • Automated building and testing: In the earlier releases, while we had scripts that would build Micro Cloud Foundry, there was some manual process involved. We also had a QA team testing Micro Cloud Foundry. This was in part necessitated by the requirement to run on multiple platforms (Fusion or Workstation for Mac, Windows, and Linux). Given our desire to update Micro Cloud Foundry bits at the same frequency as CloudFoundry.com, automated building and testing becomes an obvious requirement. We have already automated building Micro Cloud Foundry and doing a basic verification. Over the coming months, we will automate most, if not all, aspects of building, testing, and distributing Micro Cloud Foundry. Of course, Micro Cloud Foundry like the rest of Cloud Foundry, is an open source project, so you can definitely pitch in.
  • Improved user interface: Automated testing requires that the tests be able to configure Micro Cloud Foundry. When we decided to automate building and testing, we realized that while there is a way to do this through the command interface (by directing terminal input and output), it is difficult to make this work in a robust manner. Independent of this, we have been pondering a web interface that will provide an experience similar to a home network router. In a few weeks, we will provide a REST interface to Micro Cloud Foundry along with a web interface replacing the terminal interaction.

We hope you will like what Micro Cloud Foundry has in store. You can follow our frequent releases on the Micro Cloud Foundry site.

-Ramnivas Laddad and Matt Boedicker
The Cloud Foundry Team

Facebook Twitter Linkedin Digg Delicious Reddit Stumbleupon Email

Cloud Foundry Java App Errors – Root Cause Analysis

On the night of March 29, 2012, we upgraded our Tomcat from version 6 to version 7 as part of our normal production upgrade schedule.

Early in the morning of March 30th, we discovered that Java apps that were created or re-pushed were receiving an error.

At 9am PT that morning we identified the specific issue causing the error.  The script catalina.sh was modified in Tomcat 7 to start Tomcat using eval exec instead of exec.  We were setting the CATALINA_OPTS environment variable to include values for -Dhttp.nonProxyHosts that contained a pipe character, which was interpreted by eval as Unix pipe. This affected the application start command, leading to a failure to start the application.  This change did not affect our QA environment, as there was no proxy configured (or required), and thus the problem escaped our testing.  Once we understood the issue, our first priority was to minimize the impact on our users.  The best course of action was deemed to be reverting back to the last known good version (Tomcat 6).

The version rollback and validations completed at 1:20pm PT.

This problem impacted about 60 people who were performing pushes or creating apps during the time Tomcat 7 was in place.

We are learning from our mistake.  We will start by adding tests based on this incident, and will continue investigating other mechanisms to prevent similar issues from occurring in the future.

We would like to apologize to all of you who suffered from this problem.

- Ramnivas Laddad
Cloud Foundry Frameworks Engineering

Facebook Twitter Linkedin Digg Delicious Reddit Stumbleupon Email