Hello folks, another question for y'all. We're eva...
# spicedb
Hello folks, another question for y'all. We're evaluating SpiceDB and I see the docs explicitly recommend the K8s operator for deployment. Is there a reason why the operator is recommended over deploying an instance of SpiceDB using normal Kubernetes deployment methods?
(Apologies if this is a redundant question.)
My team has experience deploying K8s manifests and usually sticks to pinned versions of image manifests, controlled migrations, etc. We also have run a distributed cache on K8s before ("groupcache"). I think the operator helps configure both, but maybe there's something else I'm missing
You can (and people do) run on k8s without the operator. But we use it to run our production spicedb instances, and it makes it a lot harder to get some things wrong that folks often have issues with: setting up the distributed cache correctly, stepping through phased migrations correctly, etc. automatic updates are optional, you can pin to a specific version if you'd like
No doubt, it makes it look super seamless. I think generally our K8s folks don't love the idea of deploying custom operators. It's great that is an option though!