Curious if you have any lessons learned worth sharing. Our journey was like

1: Yeah, we can use OPA to get rid of all this legacy spaghetti code!

2: Wow this PoC really proves out the idea!

3: Whoa we have three use cases now running in production!

4: Wait, these remaining 20 use cases are way more complex. To our surprise, all this legacy spaghetti code _exists for a reason_.

5: We now have 5 use cases in production but the Rego is now quite convoluted and our application logic has actually increased in complexity.

6: Red button: okay this is going horribly wrong. Back out this whole thing.

7: Recognition: the reason this has gone horribly wrong is because the spaghetti code combines pure logic and side effects in a way that did not map well with OPA.

8: Regroup: first step is to refactor all the legacy code and separate policy logic from side effects in a meaningful way.

9: Refactor: implement the above redesign. The policy classes all now map naturally to Rego for all 23 use cases! Let's do it!

10: Reality: we don't want to. Our codebase is well-structured now and we like it. Adding OPA now feels like an unnecessary layer, an additional potential for network timeouts etc to creep in, an extra thing to maintain, an extra special case to handle in our safe deployment pipeline, an extra language to train developers on. Now _maybe_ if we ever wanted other teams to write up and maintain their own Rego policies, then _maybe_ we'd consider going with it in the future, but for now the reality is our team would end up doing that work for them anyway, and it doesn't seem worth the tradeoff.

Anyway, lesson learned: don't expect it to magically clean up all the garbage in your existing code. You'll do it wrong and things will be worse than when you started. Clean that up first, and _then_ decide whether and how you want to adopt OPA for your remaining needs.

user:	funkyuser
created:	March 13, 2024
karma:	10