This is very much a trait of BOSH. When BOSH manages a machine, it owns that machine. It deploys the stuff that's specified in the manifest, but that has to come out of one or more 'releases', ie precisely structured tarballs of stuff, and there's no way to manage a file here or a setting there. You could push out a file by packing into a release, uploading that, and adding it to the manifest, but that's quite a ritual for one file. You are essentially expected to treat the machine as a black box.
As a result, BOSH-based systems tend to be managed via APIs exposed by the software running on them, which often come with a command-line tool. BOSH itself is like this, and so is Cloud Foundry.
This is a very different approach to tools like Puppet or Ansible, which are much more about openness and empowering the operator to directly manage machines. Although it is fairly similar to Docker etc, where you fire up images without any sensible way to fiddle with them, and rely on talking to the software.
So, if you are comfortable with the Puppet/Ansible type tools, then you won't like BOSH. This is 30% because BOSH isn't as good as them, but 70% just because it's different.
As a result, BOSH-based systems tend to be managed via APIs exposed by the software running on them, which often come with a command-line tool. BOSH itself is like this, and so is Cloud Foundry.
This is a very different approach to tools like Puppet or Ansible, which are much more about openness and empowering the operator to directly manage machines. Although it is fairly similar to Docker etc, where you fire up images without any sensible way to fiddle with them, and rely on talking to the software.
So, if you are comfortable with the Puppet/Ansible type tools, then you won't like BOSH. This is 30% because BOSH isn't as good as them, but 70% just because it's different.