Cloud Foundry - a Ruby and node.js developer's perspective
This week VMware announced Cloud Foundry, their open source PaaS offering. Here's my take.
Open Source PaaS
VMware this week announced Cloud Foundry, an open source PaaS. You can use VMware's cloud (which is where they'll monetise this investment) or you can host your own. I believe you can even have a hybrid of both. Cloud Foundry joins other players in the market like Heroku, Joyent, Engine Yard and Nodester.
Developers don't want to be Sys Admins. Especially in small businesses developers take on a lot - some or all of business analysis / requirements gathering, server admin, development, testing, design, client management. The list goes on. So the emergence of services like Heroku for Ruby and Nodester for node.js is very attractive. Developers can remove one thing from the list of things that they need to be responsible for. It is an easy sell to the management layer too - it is cheaper in terms of man hours, with (almost) no maintenance.
The providers doing well in the market are the ones that realise that developers have the keys to the choices that get made. Heroku has built a kick-ass platform with a super slick API. Frankly it is a joy to use. Nodester emerged from nowhere as an open-source weekend project and for me is beating players like Joyent in their node.js offering.
One Paas to rule them all?
VMware have put considerable effort into building a PaaS to accommodate three technologies - Java, Ruby and node.js. They must be applauded for open-sourcing the project and making it available on GitHub. There are a considerable amount of man hours there and a significant investment from VMware. Thank you.
Taking it for a spin
So I took it for a spin firing up a VirtualBox Ubuntu 10.04.2 LTS VM. Installation was simple enough following the README. I created the SSH tunnel as advised and within about half an hour had built a private cloud capable of running Java, Ruby and node.js apps, with support for MySQL, Redis and MongoDB. Impressive.
The VMware team have thought hard about the API. If you are a RubyGems user you can check it out by installing the vmc rubygem and then running help
gem install vmc --no-ri --no-rdoc vmc --help
Once you have setup a user on your private cloud deploying an app is super simple. Here's the process of deploying an app
vmc push [yourappname]
Err.. that's it. Amazing!
Testing deployment on my cloud
Then I set about deploying a node.js app. It was a simple express based node.js application with express, jade and stylus as dependencies. So let's give it a go
vmc push myapp Would you like to deploy from the current directory? [Yn]: y Application Deployed URL: 'myapp.vcap.me'? Detected a Node.js Application, is this correct? [Yn]: y Memory Reservation [Default:64M] (64M, 128M, 256M, 512M, 1G or 2G) Creating Application: OK Would you like to bind any services to 'myapp'? [yN]: n Uploading Application: Checking for available resources: OK Processing resources: OK Packing application: OK Uploading (613K): OK Push Status: OK Staging Application: OK Starting Application: ..........................Error 306: Error retrieving file 'logs/startup.log'
It failed. I used the log commands but there wasn't any useful output - I guess this is early days. But I did find this article which required changing a couple of things in the app file. After that it was as easy as
vmc update myapp Uploading Application: Checking for available resources: OK Processing resources: OK Packing application: OK Uploading (15K): OK Push Status: OK Stopping Application: OK Staging Application: OK Starting Application: OK
Lovely! The API follows exactly the same process for deploying a Sinatra / Rails which is really attractive.
At pebble.code where I work I'm responsible for managing servers and setting up development sites for the team. This can be a time-consuming chore and I've been working towards a Puppet setup to allow me to automate much of this. A private cloud where developers can spin up apps with three words is massively better.
What's good about Cloud Foundry
I love the fact that VMware understand that PaaS is about being open and not being tied to one platform. Being open makes me more likely to use a platform than one that makes it hard for me to get my data in and out. I can easily move my apps in and out at any time. I can create my own cloud and move my apps onto that. I'm free and I like that.
I love the fact that Cloud Foundry is open source and created using Ruby. The Ruby community is full of talented and smart developers and it is a wise move by VMware to engage that community. I anticipate the product will be enhanced by open source contributions.
What could be improved
It is a real shame that VMware didn't go with git based deployment. Both the Ruby/Rails and node.js communities use git heavily and are used to git based PaaS services. I'm not sure why this design decision was made - perhaps the old skool Java heads at VMware won out. It would be great to see git deployment added to the platform. Currently there is no versioning on the platform - it would be a quick feature win to leverage the power of git to add this.
That said with the project being open source the developer community can easily fork it and enhance the platform. The fact that the project is open source is massive.
Will I use it?
Maybe. Currently I'm happy with the PaaS providers I'm using - Heroku and Nodester. I feel both are doing a great job. Heroku is closed source, whilst Nodester is open-source. I have the option to host a Nodester private cloud somewhere but Cloud Foundry is the only solution to offer both Ruby and node.js. I like that. Currently I mostly use PaaS providers for quickly prototyping an idea and getting it out there. I could see a Cloud Foundry private cloud working well for this.
The API is a big thing for me and I think VMware has done a great job here. Where Heroku has led others have followed and that's great news for developers.
But.. for many of our production apps they have more complex technical architectures involving Resque, Redis, Sphinx, cron jobs and background processes. In short we need to have full control over the server. Cloud Foundry goes a long way to solving this by offering MongoDB and Redis but currently unless I'm mistaken I'd be unable to host apps with complex requirements. This is an issue with PaaS in general. Heroku's add-ons solve most of this issue but there are times when simply you need root access.
So overall thank you VMware! I also need to say thank you for your support of Redis!
What are you waiting for? Give it a go, or fork it.