Blog Post

Cloud Foundry lets apps span cloud providers

Stay on Top of Enterprise Technology Trends

Get updates impacting your industry from our GigaOm Research Community
Join the Community!

Developers concerned about confining their apps to a single Infrastructure-as-a-Service platform, such as Amazon Web Services (s amzn), need worry no more. If they’re willing to utilize Cloud Foundry, the open-source Platform-as-a-Service project launched by VMware in April 2011, developers can now run apps that move seamlessly between any infrastructure already running a Cloud Foundry-based service.

As it stands right now, most PaaS offerings sit atop a public cloud — mostly AWS — and are tuned to utilize that cloud’s API and various features. Developers write apps to the PaaS they want to use, which means they’re inherently locked into the underlying IaaS cloud, as well. With Cloud Foundry’s new Multi-Cloud capability, however, developers can write apps that can actually span IaaS clouds that are offering up Cloud Foundry instances.

That might not sound like much, but less than a year into its existence, Cloud Foundry already underpins numerous efforts. On the public side, there’s VMware’s (s vmw) eponymously named Cloud Foundry service, as well as AppFog and Iron Foundry. Within the private cloud space, ActiveState is offering its Stackato product. Because it’s just open source code that needs infrastructure to run on, however, Cloud Foundry can theoretically run anywhere — on AWS, OpenStack clouds, Eucalyptus clouds, or even your own laptop.

The Cloud Foundry team explains how this is accomplished in the blog post announcing the new capability. Essentially, it’s a matter of providing applications with an infrastructure-agnostic execution method, standardizing the method of exposing services such as databases, and standardizing service credentials across runtimes. The result is that applications don’t have to worry about infrastructure-specific requirements, because the intermediary Cloud Foundry platform takes care of them.

As Cloud Foundry continues to expand its ecosystem, of course, this capability will become even more appealing. CEOs of other PaaS providers have told me in the past they were looking at ways to expand their platforms beyond AWS — something CloudBees has done by making its code downloadable — so maybe now is the time to get busy on making that happen.

3 Responses to “Cloud Foundry lets apps span cloud providers”

  1. Scott McDonald

    I’m curious – what are the advantages to using Cloud Foundry versus running Ubuntu LTS on my laptop, in vmware, in aws, linode, rackspace, etc… Ubuntu LTS is solid, free, great trusted packages. Basically I’m doing everything I’m reading here already but using a common linux distribution that’s free. I can easily set those stacks up to be fully replicated across multiple cloud vendors with automated traffic failover via Why should company’s consider Cloud Foundry instead of hiring dime a dozen unix engineers to build out cloud infrastructures using systems they already familiar with? Not trying to bash – really want to know what/where the advantages are for Cloud Foundry…

    Scott McDonad

  2. Diane Mueller

    There’s nothing “theoretical” about running anywhere, ActieState’s Stackato which is based on Cloud Foundry — has already extended it’s Private PaaS support to vSphere, XenServer, KVM, or OpenStack whether you host it on Amazon, RackSpace, HP Cloud Services or on your own private cloud.

    Cloud Foundry open source project what’s really enabling Werner Vogel’s “1000 platforms to bloom”.

    Major kudos to the excellent Cloud Foundry engineering team and the extensive Cloud Foundry Open Source community for accomplishing so much in such a short time – proving once again that Open Source collaboration benefits everyone.

  3. Chris Tacy

    Fantastic piece as always Derrick. Love it. In addition to the values you note, however, I think it’s important to also think of the value to developers in companies in being able to provide multi-infrastructure redundancy and fail-over. After all, none of us have forgotten the EC2pocalypse, right?