OPA vs. Enterprise OPA: Why You Need Enterprise OPA

We recently released Enterprise OPA, the drop-in enterprise edition of Open Policy Agent (OPA). With Enterprise OPA, we aim to solve several challenges large organizations encounter when using OPA. These include performance and memory usage when using large datasets, keeping authorization data up to date and performing policy updates in a safe way. These are all technical challenges that start to manifest when the size of the data, the number of policies and the number of OPAs running become too large.

It’s important to note that Enterprise OPA is a drop-in replacement for OPA. Every OPA command or Rego language element works exactly the same. The design goal for this enterprise edition of OPA was to add functionality and improve performance.

The main feature of Enterprise OPA is that it uses a much more efficient memory model than OPA. This leads to dramatic improvements in memory and CPU usage when working with large data sets (>100 MB).

Let’s take a look at a common source of large datasets for enterprises: user role definitions and mappings.  As an example, let’s see how much memory will a 379.5 MB JSON data file with a list of role definitions and role-to-user mappings take up in both OPA and Enterprise OPA. This is how the data is structured:

{
 "roles": {
   "role0": [
     {
       "action": "action869707",
       "resource": "resource279303"
     },
     {
       "action": "action183523",
       "resource": "resource258803"
     },
...
"users": {
   "user0": [
     "role179457",
     "role428475",
    ],
   "user1": [
     "role448324"
   ],
   "user10": [
     "role471797",
     "role138838",
     "role395575",
     "role371411",
     "role470193"
   ],
...

Let’s start OPA and see how much memory it will use when loading a bundle with this data. First, start OPA then run the curl command from another console.

$ opa run -s https://dl.styra.com/load/bundle-opa-400.tar.gz
$ curl 'http://localhost:8181/metrics/alloc_bytes?pretty=true'
3.0GB

As we can see, OPA is using 3.0 GB of memory to load our data – almost 8 times the size of the original JSON file. Let’s see how Load with handle the same:

$ load run -s https://dl.styra.com/load/bundle-opa-400.tar.gz
$ curl 'http://localhost:8181/metrics/alloc_bytes?pretty=true'
276.6MB

Load is using 276.6 MB which is actually less than the JSON representation on disk and is a 10x improvement over OPA.

This difference in memory consumption becomes all the more important in production scenarios when the same policy is executed by many OPA instances. The charts below illustrate our measurements for memory footprint and CPU usage:

The second chart shows that Enterprise OPA outperforms OPA not only in memory footprint but also in CPU throughput. These savings translate into serious savings in cloud costs. Running 10 OPAs, this data set would cost about 275$ per month on AWS. Using Enterprise OPA can reduce this cost to about 43$ per month by allowing you to use much cheaper EC2 instances.

Enterprise OPA has feature parity with OPA as it is an extension of it, making it easy to level up when you need an OPA alternative that is more robust. Besides the performance improvements, Enterprise OPA adds some features that are important in enterprise environments:

Replay previous decisions from the decision log against a new bundle before deploying it to see how much impact does the new bundle have on real-world decisions. Let’s say Enterprise OPA running with bundle version 1 would make an allowed decision for a certain input. Impact Analysis would rerun that same input but against bundle version 2 and compare the outputs to see if they match. If we do this for a large number of inputs we can determine how large an impact upgrading to bundle version 2 would have on our live system. Additionally, LIA reports changes in performance characteristics which can help catch any mistakes in your Rego that would lead to reduced performance during policy evaluation.

You can connect Enterprise OPA to a Kafka topic to receive live data updates without the need for polling. This is the most efficient way to get up-to-date data to Enterprise OPA. Not only is the data in OPA always up to date, it also minimizes bandwidth usage by only transferring changes when they occur.

Enterprise OPA provides a number of data sources that it can automatically pull for data updates. This removes the need to package the data into the policy bundle but doesn’t come with all the disadvantages of “http.send”. A data source will not pause policy evaluation while the data is in transit, and it will not stop evaluation from working when it encounters a transient network error. The policy will just use the latest version of the data. 

If any of the above conditions apply to you consider adopting Enterprise OPA to gain all the advantages of OPA with the additional enterprise feature set. Enterprise OPA will solve many of the thorniest challenges of OPA authorization without forcing a difficult upgrade process.

Request a demo and and see the Enterprise OPA difference yourself.