Services, Manifests, Multi-Tenancy & PaaS vs. Kubernetes

The Service Marketplace & Open Service Broker API

A service (a managed database, message queue, cache) is provisioned through a standardized service broker interface and bound to an application, rather than a developer manually setting up that infrastructure. The Open Service Broker API standardizes this so any provider can expose their offering consistently to Cloud Foundry (and other platforms like Kubernetes), avoiding custom per-service integration code.

Manifests & Routes

applications:
  - name: my-app
    memory: 512M
    instances: 3
    buildpack: nodejs_buildpack
    routes:
      - route: my-app.example.com

manifest.yml declaratively captures deployment configuration so cf push runs repeatably with consistent settings, instead of passing many flags manually. A route maps a URL to an application, and Cloud Foundry's router load-balances traffic across that app's running instances.

Orgs, Spaces & BOSH

Orgs and spaces provide hierarchical multi-tenancy — an org can contain multiple spaces (dev, staging, production), each holding separate applications/services with scoped access. BOSH operates one layer below application deployment: it's the tool operators use to deploy, monitor, and heal the VMs/infrastructure that make up the Cloud Foundry platform itself.

Cloud Foundry vs. Kubernetes

Cloud Foundry's higher-level abstraction (buildpacks, cf push, service marketplace) reduces the operational complexity developers need to understand compared to configuring Kubernetes manifests and container images directly — trading some lower-level flexibility for simplicity. Kubernetes has since become the dominant, more broadly adopted orchestration standard with a much larger ecosystem and hiring pool, a real practical factor organizations weigh even where Cloud Foundry's developer experience would otherwise fit well.