Why Cloud Foundry matters to Hackers

Unless you live under a rock, you have heard of Cloud Foundry. However there is still a lot of skepticism out there about PaaS in general and Cloud Foundry in particular.

I’ve been an open source hacker for over a decade. Compiling linux kernels, hacking MySQL, and generally getting my hands into every system that I could. I have also authored over a dozen open source libraries, some being used widely.

When I saw PaaS in the early days, with EngineYard and Heroku, I thought it was really cool and inspiring. Like many hackers though, it is hard to trust something or fully enjoy it when you can not get under the hood.

Why does Cloud Foundry matter?

EDIT — It is a great PaaS. As the first commentator noted, none of this matters if the technology sucks. Cloud Foundry is a great, easy to use technology that works reliably, simply, and smartly. It supports many languages and many services. To a hacker and tinkerer, it is a haven for fun.

It is well designed. Example: A message bus acts as a nerve center to various components via pub/sub. For example, when a new app server comes online, it subscribes to listen for new app deploy requests. When one comes in, all app servers publish a response on the mbus, but the mbus only lets the first request get through to the controller, reducing the noisiness of the system overall. One of the cool things this naturally does is a darwinian sort to deploy the app to the best app server available. If the app server is under load, it responds slower. If an app server has network latency, it responds slower.

It is open source. You can modify it. I did, here is the pull request. So have many others. This is how Cloud Foundry supports Erlang, Python, Perl and many other languages. One of the biggest problems I have heard hackers have with PaaS is they have no control over it, it is a black box and they have no say over how it is run. With Cloud Foundry, you finally have a say. You can modify the code and a Cloud Foundry provider like AppFog can have your code running within days.

No vendor lock-in. Lock-in is more than data lock-in. With IaaS and PaaS, it is system lock-in. If you build against any other PaaS, you start using dependencies on their systems. Moving to any other system becomes burdensome and hard, sometimes impossible without a complete rewrite. With Cloud Foundry, you can move your entire system to any other Cloud Foundry. You can run Cloud Foundry yourself (see cloudfoundry.org and Cloud Foundry Micro), you can find another Cloud Foundry provider (like AppFog, cloudfoundry.com or paas.io)

AppFog uses Cloud Foundry

Want to try Cloud Foundry in 30 seconds? https://console.appfog.com/signup

With AppFog, we became experts at Cloud Foundry and got it running at scale in various datacenters around the world.

Today you can deploy today to Singapore, Ireland and US East. Later this week you will have Tokyo, Brazil and US West. Soon after you will have Las Vegas with HP and Rackspace and Joyent. This is the power of a system without lock-in, you can run it anywhere.

The best part? We don’t charge you any differently no matter what infrastructure you pick! Even in the free model that you see in public beta you will never have to pay for any infrastructure you choose. We will be announcing pricing in June, but everything you get for free today, you will keep getting for free in the future.

Share this post

Try AppFog: The new PaaS Hackers love