For example things like document indexer which is used in 99.99% of cases to search for "some.attribute == 'hardcoded value'". Most of the other cases are prefix searches. This can be done in a normal database. Document storage where what chef really needs is ~5 extracted fields and a json blob that only client deals with. (Again - database is better) Message queue to the indexer which only exists to get broken and be a limiting factor. (extracting even 100 fields from json is not a huge work - just insert them as database rows and prevent the indexing delay) They go after new technologies, where a very conservative stack would be more than enough.

The server API is public, so I started working on a replacement using only python/flask/postgres. I got maybe 80% implemented (ignoring the enterprise namespaces). Then got discouraged because I discovered some API flaws which I thought were just too big - for example the API call to update and create a new node is exactly the same, which can make terrible mess by accident. (seen in real deployment) In the end I just started using salt which I think is a better solution overall.

If you use chef and would like to continue, I'm happy to send you the repo. (email in my profile) If you don't - I can only recommend migrating to something better (salt, ansible, etc. - your choice).