

Announcing Chef Server 12 Release Candidate - sciurus
http://www.getchef.com/blog/2014/09/07/chef-12-release-candidate/

======
sciurus
A related announcement about their open-source strategy:
[http://www.getchef.com/blog/2014/09/08/there-is-one-chef-
ser...](http://www.getchef.com/blog/2014/09/08/there-is-one-chef-server-and-
it-is-open-source/)

------
polskibus
I would love to hear about Erlang and Postgresql adventures of the Chef team.
Did you find Erlang problematic to work with Postgresql (there are a couple of
not very actively developed drivers that people usually complain about) ?

Did you move more code to Erlang in version 12 compared to v.11 ? Do you
regret moving to Erlang now and are you shopping around for a new platform
(JVM) ?

~~~
mmzyk
I'm an engineer with Chef who for the 12 released has focused on the upgrade
process from the Open Source Chef 11 server, as way of background.

We've had no problems working with Erlang and Postgres. We use epgsql as our
Postgres driver
([https://github.com/epgsql/epgsql](https://github.com/epgsql/epgsql)).

That being said, Chef doesn't tax the db heavily and our Postgres needs are
not complicated. We did write our own db abstraction layer, called sqerl. It's
open source (as all the server is):
[https://github.com/opscode/sqerl](https://github.com/opscode/sqerl)

For version 12 we did move more code into Erlang. While version 11 put most of
the code into Erlang, the multi-tenancy and RBAC system remained in Ruby and
on CouchDB (At the time this was Enterprise only, with 12 this is all open
source). A big push for 12 was moving this into Erlang and Postgres. With this
complete the entire server is now all Erlang and Postgres (except perhaps for
some small periphery tooling).

We don't regret moving to Erlang at all. We have no plans to move off of it
and are very happy with it. By making the change to Erlang the scale of the
server improved tremendously and there's no compelling evidence that switching
technology stacks would offer us anything Erlang doesn't.

That being said, we're not going to use Erlang just to use Erlang. If there is
a compelling reason to use another platform for something, we will, but the
server isn't switching anytime soon.

