|
|
|
|
|
|
by FLT8
829 days ago
|
|
|
My team is using OPA in a re-build of an application that we support. One of the main goals of the rebuild is to ensure we don't end up in a situation where every little rule change (including UAM changes) requires a full rebuild/deploy cycle of the app. OPA replaces a complex hard-coded, and largely inscrutable UAM model with a (still complex), but flexibly defined, independently testable, and easily inspectable single-responsibility model. I like that OPA has built in support for testing rulesets. The partial evaluation feature is amazing, ands makes it easy to apply UAM filters to endpoints that return large sets of data (we have consistent query APIs across the app, so could do this with a relatively simple OPA-aware proxy). It's not all sunshine and roses, and the result might seem overly complex for a lot of use cases, but in our case I think OPA has provided a nice clean abstraction and enabled us to disentangle our UAM from the rest of our code and move more quickly overall. |
|
|
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.