I’m a developer on Cloud Foundry — and yes, Cloud Foundry is indeed a bit nebulous (no pun intended). Hopefully I can help clarify things a bit.
Cloud Foundry is a platform as a service, but it needs an infrastructure as a service underneath it. Cloud Foundry supports vSphere, vCloud, OpenStack, and Amazon AWS as infrastructures through the BOSH tool. Most web application developers don’t care about any of that, but this is really cool for people who have to worry about large IT infrastructure.
Say you’re in charge of IT for AcmeCorp. You’ve got 50,000 employees who all use your internal web service, Fizzbuzz, to help them do their jobs. To support all the employees, you need dozens of instances of the Fizzbuzz application running on several machines with powerful processors and lots of memory, and you need massive amounts of disk space to store information generated by the Foo, Bar, and Baz applications you use internally, too. You’ve moved well beyond what you would care to manage on your own blade servers, so you decide to lease a datacenter.
Unfortunately, AcmeCorp is horribly dysfunctional. The finance department has a huge say in what datacenter you use, and every couple years they make you switch from one datacenter to another. Every couple years, you have several weeks of downtime while your engineers try to fix bugs in Fizzbuzz exposed by switching between vSphere, vCloud, OpenStack, or whatever.
If your engineers had written Fizzbuzz, Foo, Bar, and Baz against Cloud Foundry rather than directly against the underlying infrastructure, your downtime would have been minimized. You wouldn’t have to worry so much about being locked in to a particular datacenter, because that layer of hosting has been abstracted away by Cloud Foundry. Cloud Foundry does support a certain set of services too, including PostgreSQL, MySQL, Mongo, Redis, and RabbitMQ, to name some. If Foo, Bar, and Baz use those services provided by Cloud Foundry, that’s one less thing to worry about when you migrate between infrastructures.
Later on down the road, you realize that you can make a fortune by selling Fizzbuzz as a service to other large businesses. You’re in really good shape for this: because your engineers rearchitected Fizzbuzz to run on Cloud Foundry, you can simply deploy Cloud Foundry to AWS for as long as it’s needed. Customer tried it for six months and decided not to renew the service? No problem, you don’t have any datacenter leases to worry about — just terminate all those EC2 instances and move on. You can easily have one deployment of Cloud Foundry for each instance of Fizzbuzz as a service so that your customers’ data is totally isolated from each other.
The icing on the cake is that Cloud Foundry is open source. If you find that it isn’t quite suited to your needs, you don’t have to just email support and wait around for the Cloud Foundry engineers to implement your dream feature — you’ve got the source too, so you can make any changes you need. And it’s available under the Apache 2.0 license, so pull requests are gladly accepted, though not required.
I hope that paints a picture of the kinds of problems that Cloud Foundry solves. Feel free to ask for more details in a comment, or you can check out the Cloud Foundry mailing list if that makes more sense for future questions.