Styra Authorization Platform

We migrated towards a resource-based architecture, and one of the microservices covering initially parts of validation depended on Styra's product and Rego, but that evolved pretty quickly into a small monster that also handles some business logic.

Regarding Styra's policy authoring tools, we have built-in mechanisms we use, specifically the common libraries we refer to. We have not built custom implementations based on Rego or Styra's Rego, and we also don't use the pre-built policy libraries that Styra offers.

Overall, I can't say I've seen any benefit from using Styra. At some point, I even built a proof of concept with just JSON processing using other tools. I don't see any benefit in using Styra's Rego. It just adds to the cognitive load of shifting paradigms in any other project we touch.

I'm not a big fan of Styra. I'm actually one of the advocates in my department which launched a campaign against Styra's Rego. One of the benefits would be the speed at which it works. I call an endpoint and the response from that endpoint is pretty fast. That would be the strongest benefit—it's quite fast.

I appreciate that there's a push for using the Regal Linter, the official linter for Rego, which basically forced us to change the codebase to be a bit more readable. I personally appreciate their documentation and how it's structured and how much it covers. The documentation is one of the biggest advantages because it's well written and covers everything, including examples.

I don't like the whole paradigm change at all. We are seasoned object-oriented programming developers, and Styra's Rego paradigm is close to SQL declarative language, so it's been a very hard adaptation. One of the biggest issues we have is that if you don't currently code in it and take a break for two or three weeks or a sprint where you do object-oriented programming in Java, when you go back to Rego it's a learning curve all over again.

We don't have very good tooling for testing our code. Styra provides us with a playground where we can copy-paste code snippets and test bits of the code. The problem is that we rely on internal common libraries that we built ourselves, and we have no way to drag and drop a file and import the whole library. If I want to touch a piece of code that has something to do with our common libraries, which is 80% of the time, there's no clean way to test it in the Rego playground. We basically have to do coding gymnastics for each piece of code we test.

Styrå's Rego is a tool best used for authorization and authentication purposes—quick checks like whether someone is an admin, a user, or has special requirements. What we're using it for evolved into business-oriented code where data is parsed through Rego and checked alongside the authorization and authentication purposes. It became very big, very fast, and very hard to maintain.

Although this is not necessarily Styra's problem because it was our company's choice to use it for business purposes, it evolved very badly. We still have ongoing discussions with the architects about two to two and a half years after we started doing that, and we're still debating if it's the best place to do things. We're still promoting searching for other technologies to replace it, but after two years, it's become a monster. Many teams have onboarded and it's basically impossible to change it now. We're just waiting for the architects to find the next technology and migrate towards that.

Regarding the pre-built policy libraries, we are using Rego's built-in mechanisms such as YAML validation, and that's one of many problems we have. Our business solution in our department covers API documents, specifically Swaggers and OpenAPI specifications, so we need to do parsing and processing on JSON files and YAML files, and the support is quite bad. We have an outstanding bug with the library that OPA is publishing—a basic interaction bug. We use the YAML is valid function built-in, which for our use case gives us false positives and clashes with the other validations done inside our organization. For the past two years, there's been no change on that. We even opened issues to their tracking system. We don't have any support for that, and we don't have enough time to make a contribution ourselves to the model.

I've been an employee for four and a half years, so at least four years. We migrated some code into a new architecture somewhere around three or four years ago. I'm not specifically certain about the exact timeline, but I'm 100% sure about three years, and maybe half sure about going towards four years.

Regarding the stability aspect, I would give it a rating of ten. It's been pretty fast and stable for the past three years, and I don't see any problems in performance in any direction.

Regarding the scalability aspect, I believe it's used in a Kubernetes cluster, but I don't have access to confirm if it ever scaled up more than one pod. I know that quite a number of teams are using it, so I'd say it's at least decently scalable until now. We have onboarded approximately twenty teams using it for various resources. I don't find it scalable in the way that we're not using it only for authentication and authorization. Using it for custom business logic, it's definitely not scalable.

On a scale of one to ten, I would rate the technical support at five, maybe at the most.

Prior to adopting Styra, we did not use any different product or solution of the same kind. We only used the Rego bundle.

Given the fact that there's a dedicated platform team that built mechanisms around OPA, OPA playground, and Styra's Rego, I'd say the onboarding was simple and straightforward. We had some example projects, so we got to experiment with it before using it, but it evolved again into something bad and hard to maintain pretty fast.

I think that when we started using Styra OPA, it was an open-source project, so it was free. I think that was one of the selling points of the architects.

I'm a developer, and the solution came from management and architects who pushed this technology. I remember that in the beginning, quite a handful of developers opposed this technology. We identified pretty fast how big of a monster the code would become and how hard it would be to maintain, but the decision was made by the management team and they pushed forward.

My advice to other organizations considering Styra would be to steer away from it or put in place internal strict policies regarding the usage. Don't ever use it for business logic—just keep it for authorization and authentication.

We are using a private cloud deployment model, specifically an internal private cloud.