Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

At Pivotal we use BOSH[0] almost exclusively for deploying distributed systems. The motivating usecase was Cloud Foundry[1], but it can be used for pretty much anything. Our founding role in both of these is why BOSH is our first choice for such occasions.

It has a plugin model (CPIs) for hosting substrates, so right now it can deploy and upgrade systems on AWS, GCP, Azure, vSphere, OpenStack and there are others I forget right now.

It's proved itself in large production systems for years. Every week or two we entirely upgrade our public Cloud Foundry, PWS, and nobody ever notices.

OK, that's a lie. You get an email from CloudOps: "We're going to deploy v251". Then a few hours later: "v251 is deployed". Or occasionally: "Canaries failed, v251 was rolled back".

There's nice integration with Concourse[2,3]. You simply "put" your deployment and it just gets deployed for you. Our CloudOps team do this now, which makes their lives that much easier.

Versioning is trivial, especially if you're working in a commit-deploy model via Concourse.

The downside is that BOSH is BOSH.

We're doing lots of work to make it friendlier and more approachable, but right now it's powerful and very opinionated. It does not have a smooth onramp, because the basis of its power and reliability is that it insists on certain minimum conditions first.

It's really meant for operators, not developers, but at Pivotal the main consumers by volume are developers. Usually to deploy Cloud Foundry and Concourse; though my current assignment is actually going to be shipped purely as a BOSH release.

Disclosure: I work for Pivotal on Cloud Foundry.

[0] http://bosh.io/

[1] https://docs.cloudfoundry.org/deploying/common/deploy.html

[2] http://concourse.ci/

[3] https://github.com/concourse/bosh-deployment-resource



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: