My 2 cents, I have few solrcloud productions installations, I would share
some thoughts of what I learned in the latest 4/5 years (fwiw) just as they
come out of my mind.

- to configure a SolrCloud *production* Cluster you have to be a zookeeper
expert even if you only need Solr.
- the Zookeeper ensemble (3 or 5 zookeeper nodes) is recommended to run on
separate machines but for many customers this is too expensive. And for the
rest it is expensive just to have the instances (i.e. dockers). It is
expensive even to have people that know Zookeeper or even only train them.
- given the high availability function of a zookeeper cluster you have
to monitor it and promptly backup and restore. But it is hard to monitor
(and configure the monitoring) and it is even harder to backup and restore
(when it is running).
- You can't add or remove nodes in zookeeper when it is up. Only the latest
version should finally give the possibility to add/remove nodes when it is
running, but afak this is not still supported by SolrCloud (out of the box).
- many people fail when they try to run a SolrCloud cluster because it is
hard to set up, for example: SolrCloud zkcli runs poorly on windows.
- it is hard to admin the zookeeper remotely, basically there are no
utilities that let you easily list/read/write/delete files on a zookeeper
filesystem.
- it was really hard to create a zookeeper ensemble in kubernetes, only
recently appeared few solutions. This was so counter-productive for the
Solr project because now the world is moving to Kubernetes, and there is
basically no support.
- well, after all these troubles, when the solrcloud clusters are
configured correctly then, well, they are solid (rock?). And even if few
Solr nodes/replicas went down the entire cluster can restore itself almost
automatically, but how much work.

Believe me, I like Solr, but at the end of this long journey, sometimes I
would really use only paas/saas instead of having to deal with all these
troubles.

Reply via email to