Is <https://github.com/PrefectHQ/prefect-operator...
# ask-community
c
Is https://github.com/PrefectHQ/prefect-operator/ stable? I'm wondering what it's worth to move away from provisioning infra with declarative manifests (Kustomize, FluxCD) to the operator. Certainly Helm out of the factor means less complexity, but besides CRDs, what's in the tradeoff?
m
Hey Teo, thanks for reaching out. We’re currently using the prefect-operator to test out some alternative deployment options internally, but open sourced it because it was effectively a direct alternative to our open source charts. It’s been quite reliable internally so far but it doesn’t yet have the same level of feedback and tuning from public use. I’d say if you’re interested and familiar with operators, give it a go in a pre prod and environment and see how it goes for you. If you have any feedback we’ll definitely check it out and work on (or review) PRs to address it. To your question directly on trade offs, you’ll get all the benefits of operators in general, such as more resilient auto healing, helpful logs, and rollout improvements like waiting for migrations to complete before deploying Prefect Server. As for downsides, like you said, access requirements for CRDs along with the fact that it’s generally a younger offering on our side so may have comparatively larger and more frequent changes
🙌 1
c
Awesome explanation, nailed it - appreciate you! One thing I'm hesistant stepping into are operators and it's only due to never having worked with Go. Not the right time to make that time-investment, so it makes sense that i should stay away especially without the confidence of being capable to touch the source code. Again, thanks for saving me time 😄
m
Sure thing! And makes sense - if you ever end up trying it definitely let us know and feel free to open issues, even if you don’t have capacity to submit PRs, feedback always helps!
c
If you had to share your experience, and could compare the effort to that of perhaps building with cmake / ninja, how does the complexity of working with Go and its toolchain compare? Half the effort somewhat? I'm planning my way in hehe
Maybe it's a good first use case for that Cursor IDE
m
oh man, I used to manage the GitLab helm charts and it was painful since it’s 2-3 syntaxes in one file and none of them are actual programming languages. Working with Go has been a dream, and it’s so much more powerful because of that - let alone that Operators are long running processes in the cluster with so much greater control. To me, helm only makes sense now for smaller applications that don’t have much configuration or rollout logic. And Cursor is indeed very handy for working with Go in general!