2 ms·
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 pr
by mmzyk 12y ago
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.