You answer is just about a discussion we had yesterday about the race between 'let build a standard that will allow the LLM to get programmatic decisions' and 'let build something that works'
Most of the standard and implementation is focused in the vision of models and clients that automatically handle the tool overhead, while in reality everything that is related to MCP requires tons of boilerplate/middleware/garbage code.
During our work in the Policy as Code open source project OPAL, we discovered that AdTech is one of the most complex industries to implement fine-grained authorization. In this article, we will be sharing how Reddit developed their own authorization system for Ads using OSS and advanced policy engines.
In the debate between policy as code and policy as graph, Reddit chose a unique approach. They used OPA (code) as a model and a centralized (Zanzibar) service.
Writing JS/TS for browsers and backend applications is an entirely different skill. The only similarities are syntax. From the organization's perspective, the developer's primary expertise is a platform/framework, not a language syntax.
The point of the article is right for the indie developer who wants to stick with one language as a "mother language" and be able to produce any kind of software in no time. For scale, it is not the case.
I'm a big fan of JS/TS, but there are absolutely significantly better choices for many backend applications.
In 2021, when Permit.io launched, we anchored our authorization framework on Policy as Code with a specific focus on OPA/Rego. We believed, and still do, that Policy as Code approach is key to scalable authorization.
While policy engines solve the challenge of decoupling policy and code, the challenge of scaling them and loading them with the right policy and data remains strong - especially for event driven systems.
We reviewed how Netlfix used OPA with a a replication pattern; and decided to create a similar yet more extensible and event-driven solution - and so OPAL (Open Policy Administration Layer) was born - creating a scalable, zero-trust way to manage policy engines and their policy/data at scale.
Fast forward two years, and the landscape has evolved. New policies as code languages and standards have emerged (Cedar, OpenFGA, etc.), and in this evolving market, OPAL has positioned itself as a leading solution for synchronizing policy as code with policy data, particularly for self-hosted environments.
What truly differentiates OPAL from other solutions like Topaz and Permify is its flexibility. OPAL is not limited to a single policy engine; it supports a variety, making it a versatile tool for authorization applications. Using a single Helm chart or Dockerfile, one can deploy a full-fledged authorization system, customized to specific policy models, languages, and engines.
As we look to the future, we're keen to gather insights from the HackerNews community. What features would you like to see in OPAL? How can we make it more robust and efficient for your authorization needs?
We value your feedback and are excited to see how your suggestions can shape OPAL's roadmap.
P.S. As with any open-source project, your support on GitHub, especially stars, helps us a lot. Thanks in advance for your backing!
Can't agree more with your statement. Yet, the way this guy sells his company by playing an unfair game did not convince me and actually do the opposite..
Recent research conducted by Styra¹ (creators of OPA² and the Rego policy language) has revealed that policy as code (PaC) has become a critical component of the cloud-native development landscape. Nowadays, developers are utilizing PaC for every authorization vector, including developers, infrastructure, admissions, services, and applications. Moreover, new policy languages have emerged that are specific to vectors, such as Cedar³ for applications, or to particular use cases, like OpenFGA⁴ for Google Zanzibar style authorization.
OPAL is a tool that enables developers to deploy a comprehensive authorization infrastructure that automatically synchronizes configuration and data. With OPAL, developers can roll out scalable PaC-based architectures in seconds⁵.
As one of the maintainers, I would be grateful for your open-source support (stars, issues, and comments) and am eager to hear your opinions on the state of policy as code.
Well, coding-wise, it's the same skill. There are components, UI logic, business logic, etc. For these practices, I would start with Swift/React native as the easiest overhead on top of standard web development.
The time-consuming tasks for newcomers are the platform-related tasks. Bugs and issues unique to iOS, find the proper IDE (incl. build-tools, etc.), everything related to assets (pictures, video, splash screens, etc.), submit to the store, build the CI/CD that fits native apps, etc.
The most important mindset, IMO, is to remember these facts and never investigate/stuck too much with these new fields, even paying some $$ for automation that could help you with the time it is consuming. Also, managing your time for the balancing between tedious new tasks and new enjoyable learning can help with getting things done.
That was precisely my thoughts before the launch, but I was surprised by the results. It is not a real thing to launch a startup, but super cool as another marketing tool.
> I'm not clear on how you actually do that with OPA
The sharding is managed from the OPAL control plane, when you configure the data sources you also configure the way the sharding works.
> ensure consistency in your application since hydrating the cache is asynchronous.
OPAL use eventual consistency for cache reliability, you can know that data has changed, even before you know what changed.
> And then you start to think about caching, data consistency, and so on
If you are looking at OPA or Cedar as a standalone engine, this is the correct assumption. To avoid this hassle, there is an open-source tool called OPAL[1] that will let you run the policy engines with all the sync work without any investment in custom solutions. OPAL has a ready mechanism for data fetching and synchronization, so you can plug it into your application's data and not worry about the data.
Data filtering implementation has different approaches among the mentioned policy engine. For OPA, custom Rego code could return the allowed data, and the caching mechanism will ensure its consistency and reliability. For Zanzibar, since the policy derived from the data relations, data filtering is using is an internal part of the paper.
I recommend the following article for more information about policy as code and policy as data to understand the context better - https://www.permit.io/blog/zanzibar-vs-opa
Actually, Permit does support OPA. In fact, about 15% of our large customers came from StyraDAS and use Permit as their enterprise OPA solution.
On top of that, we offer OPAL+, which is already adopted by Fortune 100 companies as a production-grade OPA framework.