Many organizations have or are evaluating a configuration management tool
to configure and deploy at least parts of the infrastructure.
When bringing CF into the picture, it likely needs to integrate with that
for some support functions; be it the CCDB (that may be provisioned on an
existing PostgreSQL cluster), backup, monitoring and so on.
The argument here is twofold, technical and organizational.
From an organizational point of view, if they are already running Chef (or
Puppet for that matter), BOSH is an extra piece that they will only use for
CF; and that increases the "total cost of ownership" (hardware, software,
And even if they are not yet, most of our customers would rather introduce
something that they can reuse.
From a technical point of view, Chef allows us to "mix and match" a CF
cluster with existing infrastructure in a loosely-coupled, dynamic way.
E.g. you can configure an external, shared LB to point to only the CF
routers that you are alive at this time, based on "labels" (roles, in Chef
parlance) that you attach to nodes. And again, maybe that's side by side
with other non-CF sites.
Note this is based mostly on our conversations with relatively small teams
in non-mission-critical environments; startups of course, but also software
development and QA teams in banks and smaller telcos and service providers.
I realize my arguments may be moot for e.g. larger telcos where they care
more about the "turnkey", more predictable, more controlled environment of
That's kind of similar to a "CF vs AppDirector" argument--there's place for