few small comments on the thread...
FWIW, we've managed BOSHes with many deployments, some of which consist
of ~1000 VMs, and not seen any direct performance issues of the BOSH
director. Just lengthy deploys due to having so many VMs to iterate through.
exactly what i was thinking.
Scalability, Fault-tolerance, True no downtime updates.
that's all easy when there is no shared state to manage. director carries a
lot of state (as it has to) and that state has to be migrated over time for
backwards compatibility etc.
you can technically deploy as many directors as you want today
(horizontally scalable) but they all in the end have to connect to some
shared state (database).
I know that people like IBM will love to update BOSH with true / zero
downtime
downtime-less deployments of the director will be achievable soon enough
when we expand agent's connectivity options to allow for connecting to
multiple directors. this will make rolling directors just a standard
procedure (like rolling cloud controllers in cf for example).
Perfomance wins, giving the nature of elixir/erlang/OTP is easy to guess
that a single bosh instance will gonna be able to manage more deployments
and bigger deployments than it does now.
if you take a look where majority of the time is spent, it's not in the
director itself but in all the other components director orchestrates (cpi,
installing jobs, startup, etc.). optimizing director would be focusing on
5% and most likely language choice isnt going to yield any noticeable
change.
Plus all the simplification in the Director logic that can come from
using the proper tool for the right job
not sure which parts you think can be simplified. director is a pretty
vanilla application that uses a db, etc.
On Thu, Apr 27, 2017 at 11:26 AM, Voelz, Marco <marco.voelz(a)sap.com> wrote:
Dear Leandro,
I'd love to see your experiment grow – keep in mind that the Director is
around for quite a while and has some pretty complicated corner cases. Just
like any rewrite: It is pretty simple to get 80% right, but then you'll
spend much time on getting the remaining 20%.
A word on the license: If your target audience is really companies like
IBM, don't go with GPL. I now that for example GPL is a no-go for us at
SAP. I would assume a similar policy is in place in pretty much every big
enterprise.
Warm regards
Marco
*From: *Leandro David Cacciagioni <leandro.21.2008(a)gmail.com>
*Reply-To: *"Discussions about the Cloud Foundry BOSH project." <
cf-bosh(a)lists.cloudfoundry.org>
*Date: *Thursday, 27. April 2017 at 19:57
*To: *"Discussions about the Cloud Foundry BOSH project." <
cf-bosh(a)lists.cloudfoundry.org>
*Subject: *[cf-bosh] Re: Re: Elixir for bosh director?
OK what you quote is certainly amazing, anyway that only tackle the
Scalability in part (I know for sure that elixir/erlang can hold the same
a lot better) but it didn't solve the Fault Tolerance part or the true no
downtime deployments (I know that people like IBM will love to update BOSH
with true / zero downtime). Plus all the simplification in the Director
logic that can come from using the proper tool for the right job. Anyway I
think I'll start a POC as under GPL license to make a compatible "BOSH
director" using elixir. Anyone who will like to help more than welcomed.
2017-04-27 17:59 GMT+02:00 Geoff Franks <geoff(a)starkandwayne.com>:
FWIW, we've managed BOSHes with many deployments, some of which consist of
~1000 VMs, and not seen any direct performance issues of the BOSH director.
Just lengthy deploys due to having so many VMs to iterate through.
I've also seen a significant uptick in responsiveness from the bosh cli
when using the v2 cli, since ruby isn't parsing for tons of gemfiles every
time I start the CLI up.
On Apr 27, 2017, at 9:01 AM, Leandro David Cacciagioni <
leandro.21.2008(a)gmail.com> wrote:
After more than 6 months working with elixir in prod, it crossed my mind
that maybe it deserves some time of experiment and think on the possibility
of a *TOTAL REWRITE OF BOSH DIRECTOR USING ELIXIR*.
Some of the pros that I can list out of the box (without digging to much
in the technical side) are:
· Ruby like syntax (I know I know... This means a lot for people
that don't like erlang syntax) (I'm used to both so far)
· Easiness of development thanks to OTP & FP.
o Scalability (ex: http://www.phoenixframework.org/blog/the-road-to-2-
million-websocket-connections)
o Fault-tolerance
o True no downtime updates.
· Simplification:
o nats can be deprecated.
o All the other jobs (Director, Registry, Blobstore, HM & CPI) can to
be OTP/Apps (Mix powered) under the same umbrella project.
o Clustering out of the box
· Perfomance wins, giving the nature of elixir/erlang/OTP is easy
to guess that a single bosh instance will gonna be able to manage more
deployments and bigger deployments than it does now.
This is a suggestion and I would like to know if you agree or don't and
why.
Thanks,
Leandro.-
