Cloud Foundry Now Supports Play!

by May 31, 2012

Cloud Foundry now supports Play 2.0 as a first-class framework. Play is a lightweight, stateless, web-friendly framework for Java and Scala. Developers can leverage this event-driven non-blocking IO architecture to build highly scalable applications. Play 1.0 applications were previously deployable to Cloud Foundry as WAR files. Play 2.0, which doesn’t have built-in support for WAR files, can now be deployed to CloudFoundry.com and take advantage of being a fully supported framework that includes auto-reconfiguration, simplified service connections, and automatic database management. Play developers, welcome to Cloud Foundry!
Getting Started with Play 2.

Cloud Foundry Supports Node.js Modules with NPM

by May 24, 2012

Update: Recent Changes in Node.js Modules Support
We are pleased to announce support for npm (Node Package Manager) which manages Node.js application module dependencies on CloudFoundry.com. The popularity of Node.js can be partially attributed to its strong ecosystem that has created modules for practically any programming task–from database access to payment processing. At present, there are over 10,000 node modules listed on search.nodejs.org. Any cloud that aspires to provide good support for Node.js needs to simplify the task of using node modules. With the addition of npm support, Cloud Foundry now makes it easier for you to manage modules for node applications. The normal process of creating a Node.

Building a Real Time Activity Stream on Cloud Foundry with Node.js, Redis and MongoDB – Part I

by May 17, 2012

Cloud Foundry provides developers with several choices of frameworks, application infrastructure services and deployment clouds. This approach to providing a platform as a service enables the fast creation of useful cloud applications that take advantage of polyglot programming and multiple data services. As an example of how this enables us to be more productive, I was able to use Node.js, Redis, and MongoDB to create an Activity Streams application in a short time, despite the fact that I mainly develop Web Applications in Ruby. Based on the developer interest after a demo of this application at NodeSummit 2012 and MongoSF 2012,  I was inspired to do a 3 part blog series that fully details the creation, deployment, and scaling of this application on CloudFoundry.com.

Refactoring the VCAP Repo

In my previous post, I talked briefly about the vcap repo refactoring effort. This week, I want to walk you through the process in a little more detail.
If you look closely at the vcap repo, you can see that it’s a collection of major system components (dea, cloud controller, health manager, etc.). This structure is not a scalable structure for the long haul on a number of fronts.
For instance, when building releases we often find ourselves wanting different components at different stages of completion. Within the cf-release repo, we currently have a single sub-module pointer to vcap (src/core). Given the component diversity under vcap, we often find ourselves wanting to be able to manage one launch schedule for each component (e.g.

Refactoring the VCAP Repo

In my previous post, I talked briefly about the vcap repo refactoring effort. This week, I want to walk you through the process in a little more detail.
If you look closely at the vcap repo, you can see that it’s a collection of major system components (dea, cloud controller, health manager, etc.). This structure is not a scalable structure for the long haul on a number of fronts.
For instance, when building releases we often find ourselves wanting different components at different stages of completion. Within the cf-release repo, we currently have a single sub-module pointer to vcap (src/core). Given the component diversity under vcap, we often find ourselves wanting to be able to manage one launch schedule for each component (e.g.

Running Standalone Web Applications on Cloud Foundry

by May 11, 2012

In this final post of the four-part series on deploying standalone apps to Cloud Foundry, we will explore how to build and deploy JVM-based web applications that aren’t packaged as traditional WAR files. This includes applications that are built on top of an NIO Framework like Grizzly or Netty (notable frameworks include Blue Eyes and vert.x) and applications that ship their own container, such as an embedded Jetty server.

Also in this series:

Cloud Foundry Improves Support For Background Processing

Running Resque Workers on Cloud Foundry

Running Workers on Cloud Foundry with Spring

Deploying a Spray Application to Cloud Foundry
Spray is a suite of lightweight Scala libraries for building and consuming RESTful web services on top of Akka.

Running Workers on Cloud Foundry with Spring

by May 9, 2012

In the two previous posts in this series, we discussed using Cloud Foundry’s new support for standalone apps to deploy worker processes. We looked at an example using Resque for Ruby apps. In this third installment, we explore using Spring to create workers in Java apps.

Also in this series:

Cloud Foundry Improves Support For Background Processing

Running Resque Workers on Cloud Foundry

Running Standalone Web Applications on Cloud Foundry

Let’s walk through an example.
Deploying the Cloud Foundry Twitter Search Sample
Cloud Foundry Twitter Search includes two applications: a standalone Java application that periodically polls Twitter for tweets containing the word “cloud” and a Node.

Running Resque Workers on Cloud Foundry

by May 3, 2012

Also in this series:

Cloud Foundry Improves Support For Background Processing

Running Workers on Cloud Foundry with Spring

Running Standalone Web Applications on Cloud Foundry

We introduced Cloud Foundry’s new “standalone” applications feature in the first post in this four-part series. In this second installment, we will look at the most common use of a standalone application–the worker process. Workers can be used for all kinds of asynchronous background jobs, such as updating search indexes, emailing all users with a password reset approaching, performing a database backup to persistent storage, or uploading new customer data from external storage.

Cloud Foundry Improves Support For Background Processing

by May 1, 2012

Cloud Foundry has significantly enhanced support for worker applications that perform background processing by allowing applications to run on CloudFoundry.com without the application container. Cloud Foundry applications are no longer limited to Web applications that respond to HTTP requests. Instead, they can be run as executable or “standalone” applications. A standalone application is one that does not require a provided framework or container.
Many developers create distributed applications that have workers to perform specific functions and communicate via a data or messaging system, such as those developed with Spring Batch, Spring Integration, Resque, or Delayed Job.