Never Build Permissions Again: OPAL with Or Weis

About this Episode

OPAL is an open-source administration layer for Policy Engines such as Open Policy Agent (OPA). OPAL provides the necessary infrastructure to load policy and data into multiple policy engines, ensuring they have the information they need to make decisions. Today, we’re talking to Or Weis (@OrWeis), co-creator of OPAL and co-founder of Permit, the end-to-end authorization platform that envisions a world where developers never have to build permissions again. 

Contributor is looking for a community manager! If you want to know more, shoot us an email at eric@scalevp.com.

Subscribe to Contributor on Substack for email notifications!

In this episode we discuss:

• History of Permit and OPAL

• The benefits of an open-foundation model rather than open-core

• RBAC vs ABAC vs ReBAC

• Why developers would prefer to not have to deal with authorization

• Or’s own podcast, Command+Shift+Left

Links:

• OPAL

• Permit

• Command+Shift+Left

• Terraform

People mentioned:

• Asaf Cohen (@asafchn)

• Filip Grebowski (@developerfilip)

Other episodes:

• Open Policy Agent with Torin Sandall

• Community Driven IaC: OpenTofu with Kuba Martin
  

Or Weis:
If you build something that is valuable and you communicate that value in a clear way where people are searching for that value, it'll resonate with them and they'll interact with you.

Eric Anderson:
This is Contributor, a podcast telling the stories behind the best open source projects and the communities that make them. I'm Eric Anderson. I am excited to share that we have Or Weis on the show today who is one of the co-founders of Permit and OPAL. Permit being a company and OPAL being an open source project. Or, thanks for coming on the show.

Or Weis:
Thanks for having me, Eric. I'm super excited to be here.

Eric Anderson:
You may or may not know at this point that by the time the show is released, we'll have made an investment in Permit, which I'm very excited about. Known Or for a long time, but this is the first time he's coming on Contributor. We will talk less about Permit and more about OPAL today. What is OPAL?

Or Weis:
OPAL stands for Open Policy Administration Layer and it's our open source project that has become the de facto way to manage policy engines at scale. So policy engines like Open Policy Agent, OPA or CDER from AWS, these are de facto way of managing and running policy as code, but it's not enough to have one engine. You need to run multiple ones as part of your software, and you need to scale them and load them with the right policy and data that they need in the right time. And that's actually a hard problem to solve that by yourself. So instead of solving it, you can use OPAL. And OPAL is inspired by how Netflix solved the problem. So they created a replicator pattern that replicates the policy and data into each of those policy engines. And that's what we've took as inspiration to build into OPAL itself.

Eric Anderson:
So we might be familiar with these policy engines. I think we've had OPA on the show a long time ago, the open policy agent folks. So you bring or OPAL brings other services that surround a policy engine like OPA. If you want a policy engine, you probably want these other services too.

Or Weis:
Yeah. It's just the fundamentals. The policy engine by itself is useless unless it has the policy it needs and the data needs, the world picture of what's going on. So the list of users, the roles assigned to each of them, the quotas, geolocations, all these things you want to be using as part of your policy, you need to load them into the engine. You also need to keep them up to date as the data plan is changing. Like if you are using geolocation for example, your customers might be moving around. So you need to dynamically on-the-fly, update the data, and it can come from various data sources. And OPAL enables you to, through a lightweight Pub Sub channel, have each of your policy engines subscribe to updates for both policy and data. So for example, if you are maintaining a database or service for geolocation, you can track those changes and have them propagate into OPAL and through it into all of the policy engines that need that data.

Eric Anderson:
Super. So you're a policy delivery service for engines. I'm making up taglines that you may or may not espouse as we go here. Or, how did you get into this? What leads one to want to build such a thing? And tell us about yourself along the way.

Or Weis:
Okay, so maybe I'll take a quick step back and start at the beginning. So I'm an engineer and background. I started writing code at the age of five, but my career actually took off in the intelligence core in the IDF where I was an officer, developer, team lead, engineer, reverse engineer, yada yada, yada. Essentially a cliche of an Israeli entrepreneur. After my service, I worked in a startup called Intiguo where we built container technology before it was a thing, but with a truly horrible go-to-market, even worse than Dockers after they ruined the wrong go-to market. And then I co-founded a startup called Reactful that was acquired by Metadata Inc. I was a VP of R&D in a cybersecurity company catering to governments and like-minded agencies. Only did defensive projects and offensive ones. Super proud of it, especially in retrospect. And then between late 2016 and up until three years ago, a little over, I co-founded and ran CEO a company called Rookout, an effort dev tool company in the production debugging space that was later acquired by Dynatrace.
And during my time working on Rookout, I ended up rebuilding the access control to our product five times when the company wasn't even three years old. That basically drove me nuts. Reflecting on it, I realized that I've been building this crap, pardon my French, for thousands of times throughout my career, and at no point did I want to. I got together with a good friend of mine and now my co-founder and CTO, Asaf. He at the time worked at Facebook now Meta and he worked on their internal developer tools and internal authorization and he saw that they have invested a team of 30 people for half a decade to build a level of access control that they have and they're still building on. So we quickly realized this is a huge problem now and it's only going to get worse as technology continues to scale out, become more distributed, more complex, and also have more smart components as part of it.
So we realized we want to solve this problem once and for all, and we want that you and other developers will never have to build permissions again. And that's why we decided to create the company that is now known as Permit. And the first thing that we wanted to do was to adopt the best practices. So we started with adopting OPA open policy agent and we wanted to have it run at scale for our customers. And that's where we ran into the first problem. How do we manage this thing at scale? It doesn't provide anything for it. You just get one engine and if you run it by itself, it's okay, but if you have hundreds, thousands, tens of thousands of instances of it really becomes quite a labor, some task to manage it on your own. And so we looked around and as I mentioned, we saw how Netflix used OPA.
They have a great talk as part of the CNCF on YouTube where they describe how they created an engine that replicates the needed data and policy into each of the OPAL instances. So we decided, okay, this is a good approach to go about this, but Netflix didn't open source their project, so we took it upon ourselves to open source it, then we called it OPAL. So it's basically necessity all the way down. Necessity from building companies, necessity into needing to build access control and necessity into, okay, we want to solve access control at scale and we want to adopt the best practices, but we also want to work in a way that is applicable for everyone.

Eric Anderson:
And you mentioned earlier that part of that was adopting. On your journey, you interacted with OPA and OPAL sounds like OPA and so I see some resemblance there.

Or Weis:
That was intentional though it's important to note that the A in OPA and A in OPAL are not the same one. One is agent, the ones in administration. So today OPA supports multiple policy engines, but at a time it was focused almost exclusively on OPA. And we knew from the start that we'll support multiple engines and that's why we built it to be extensible and dynamic enough. But starting with OPA, we felt like it's a win because it both resonated with the current community. It sounded nice, it described what it is and it sounded like a cool gem that is fun to have.

Eric Anderson:
Yes, it's very desirable gem. And what's maybe impressive though that we haven't acknowledged is that OPAL has done quite well by some standard. Big community, large companies are depending on OPAL. How did that come about or what was it like seeing that happen?

Or Weis:
So yeah, OPAL is now the de facto way to run policy engines at scale. Tens of thousands of companies with names that are front to name-drop like Tesla, Zapier, Accenture, Microsoft, Cisco, Walmart, the NBA, a bunch of banks, a bunch of healthcare institutions, over 10 million docker pools and growing thousands of stars on GitHub and the thousands of engineers in our community, continuing to grow strong. We were very proud of OPAL and the journey that it took us on. We didn't really know or expect that it will grow to be this popular. We definitely hope, but we didn't know. We just felt it was the right way to have this component be open source.
We felt that it's a critical element that is missing as part of the ecosystem. We felt like having policy engines is important, but also being able to manage them is important and that needs to be open source. And we also felt that it is complimentary and not cannibalizing into what permit needs to be. I'm a huge fan of open source in general, but I'm not such a big fan of open core. So being able to go with a different angle here, which I like to call open foundation, where the commercial offering and the open source offering are not providing the same value proposition, but instead are foundations for one another.

Eric Anderson:
So permit and OPAL complement each other. They're different offerings, but the people who want OPAL probably also want Permit. And so building the open source project lends itself to helping you build a community for prospective customers.

Or Weis:
Exactly. Though, depending on where you're on the stack, there's a fork in the road. So first of all, with authorization, you need it across the stack. You need physical layer authorization like locks on your doors and on your windows. And then you need network level authorization. So firewalls, zero trust networks, VPNs, then you move into infrastructure level authorization. So service to service access control and admission control and Kubernetes. And this is where OPA originally grew to fame as part of the CNCF and mainly gatekeeper and admission control to Kubernetes. And then you graduate in application level access control, which is basically everything else which I like to summarize is which users can interact with which other users through which features.
And so if you're doing application level access control, you'll discover a lot of our customers find us this way. So they discover policy as code, they discover either Cedar or OPA, they discover OPAL and then they discover Permit and they often say, "Oh, this actually reps everything I want in a nice bow. I can go into that." But we also have a lot of people in the community doing infrastructure level access control for example. And for them, Permit is while somewhat irrelevant solution, it's less of a relevant solution. So they might just end up working with OPA and OPAL vanilla without the additional sprinkles from Permit.

Eric Anderson:
And maybe going back to this idea that you managed to get a bunch of awesome companies using OPAL, is there a trick to that adoption? A lot of us want to believe you just put it on GitHub and the people come.

Or Weis:
No, it's not that simple, but there's a truth in the essence of it. If you build something that is valuable and you communicate that value in a clear way where people are searching for that value, it'll resonate with them and they'll interact with you. But it's not enough just to build it. You need to build it with the right supporting materials. It requires documentation, requires messaging, it requires marketing, it requires getting up on stage yourself and spreading the word. It requires interacting with the right people and it requires being embracing and open.
So when these people come in and they want to learn about the product, you need to have the patience to sit down with them and explain to them how this open source component works. And while Permit is very mature and has all the bells and whistles, OPAL being an open source project isn't as polished naturally. So having the community, having the passion, attention and willingness to help people take this a step forward and starting that feedback loop that will get more people to then help each other is a step that you have to take. It doesn't just materialize day one, you first of all need to be the community before the community emerges as a whole.

Eric Anderson:
You build something that has a lot of value, but then you have to communicate this value that seemed to be an important point that you were outlining. And you described various ways that you communicate value in a slack conversation or on stage or through content. Are there taglines? Are there messages that really resonate with people about authorization?

Or Weis:
I think the best one that we have people jive with is never build permissions again. In the end of the day, I think it's important to know that I think most of the players in the space don't necessarily get it end to end. Authorization is not something that developers want. It's not something sexy. It's not, "Oh, I'm excited to build this authorization layer." No, it's a nuisance. It's something that is keeping you from building the core features of your product.
And while yes, developers like building technology and using advanced tools and extrapolating on that and building amazing things, they want to build the amazing things that they care about. And this is not something that is unique to any company or any product. So I think we've never built permissions again, we say something very simple that speaks to the heart like, "Yeah, we know you don't want to do this. And we ourselves as engineers, we don't want to do this either, but we want to do this once right for everyone so you can focus on the things you actually care about."

Eric Anderson:
Or, take me into the product or the architecture some. So most people I think are familiar with very basic permissions. I have a user's table, maybe I already use some third party service in order to authenticate my users and maybe I have one or two roles, they're a user or maybe they can have an admin and perhaps that's just another, in my user's table, that's just another attribute. Are they an admin or not? And I feel like this is the very basic permissions that people start with. How do you build it in a way that you never build it again and how do you build it differently?

Or Weis:
So it's about adopting right best practices. And what we try to do with permit is bake those best practices in. So you won't have to think about it, but still let's unpack them. Think one of the most important best practices is decoupling policy and code. The most common mistake people do is assume that the data models and code models that they have for their core application will be the same for the authorization layer, but they aren't, these are two very different tasks that will require different code flows and different data. And if you just merge them together, it's just part of the application code, you're going to have a bad time because as the requirements for both change, you'll have to change both constantly. So you're constantly generating more work and more friction for yourself, and every little change becomes instead of a quick update, becomes a multiple months project.
So I think decoupling policy and coder is the most important thing. Once you've decoupled your policy from your code, the question is now how do you manage it? What is the best way to manage policy and have it run in a good way, a performant way as part of your application? The best answer humanity is come with is policy as code. So in general, through infrastructure as code and other patterns like that, we recognize that complex things that we want to communicate and work on as a team. The best way to represent it and maintain it and work on it is as code. So we want to have a language or format that is dedicated to run as a policy. We want to manage it for the best practices of code, meaning you are able to run tests on it, you are able to do benchmarks, you're able to replicate scenarios and you're able to do code reviews, et cetera, et cetera.
So now we decoupled our policy from our code. We have code that represents our policy. We maintain Git we have versions and tests. Now we want to run it. So ideally in modern infrastructure, we want to run it as a microservice. So you want to have a microservice for authorization that lives alongside your software and is performant and has low latency. So you don't want to have it remote from your software because for every little query you have to go to that remote site and that will add a lot of latency. That's just the rules of physics. So you want to be able to run that microservice next to your software. That's where, by the way, where OPAL comes in. So now we have this microservice, and so how do I make sure that this microservice remains up to date? Because it needs to be independent in the field. It needs to be able to answer those queries as they come in and can't be part of a huge separate database.
So how do I load into it at the edge? How do I load the policy and data? And so that's where OPAL comes in with the second-best practice. Be event driven, which is a common best practice for cloud native applications and microservice applications specifically. So now we're event driven. We have decoupled policy from code and we have a dedicated microservice for authorization. Lastly, we need the right interfaces. We need to recognize that this is not just for developers. If you're building policies, if you're maintaining a product, at the end of the day, access control is really about connecting people and systems to what you've built. And so our organization building a product or a system, everyone's involved. So it's the developers, obviously it's DevOps obviously, but it's also the product managers, security, compliance, sales, professional services, support, everyone.
So if for every little change you want to make, you have to go back to the developers that will write code and go through a software development lifecycle. Everyone's having a bad time, especially the developers which you force into becoming a bottleneck for this annoying thing that they don't want to do. So it's about creating the right interfaces. We need to enable everyone around the table to be able to participate in the policy authoring and maintaining process. Each of them needs the right interface for that.
So if you're building this on your own, you can think, "Okay, what do my product managers will need here? Maybe they just need a way to assign roles. Maybe they just need a way to set attributes. Maybe they need a way to maybe affect the policy a little more." What we've done with Permit is we provide you with a policy editor that I like to say a monkey can use or even a product manager if they're smart enough. By the way, ironically product managers are the ones that love that joke the most. And what it does, it generates policies code for you. So a product manager can work with it and generate the policy and sales and professional services can come in and generate the policy and it'll all get distilled into that Git repository that we described before. And the developers can still load code directly so everyone gets the right interface that is suitable for them.

Eric Anderson:
It sounds like and I'll try and use my analogy from earlier. If in my application I might be tempted to say something like, "If the user is an admin or if the user is not an admin, display this list with this information," and instead I just say, "Display this list for all those who have permission." And I outsource the permission system to tell me what information to display. And then the policy can be applied independent of the code, the code's not saying the logic on who gets to see what, the permissioning system is.

Or Weis:
Yeah. So thank you. You also, you want to do that filtering across different services and you want to have a unified policy that affects all of them. So once you have those policy engines and you can load each of them with the right policy and data, you can keep everything in sync without having to constantly run about managing it. And it's important to note that with policy engines, it's not just about binary decisions. It's not like show this or don't show this. It's also give me, filter out a subset of the data or even do something called partial evaluation. Partial evaluation, you ask the policy engine to spit out a abstract syntax stream, basically a set of conditions that you can then compile into SQL or another query that you can pass to your underlying database. So you can filter at the database level itself, but still it'll be driven by the primary policy that you've defined together as a team of stakeholders.

Eric Anderson:
Maybe moving away from the project for a bit, or you mentioned earlier you have opinions around open core versus what you called open foundation. You could tell us more about that or any other thoughts about what developers want to experience in an open source project or a software vendor selling to them.

Or Weis:
Yeah, I think at this point, first of all, it's important to note that our entire world is open source, cute anecdote. So as part of the investment round we just did, we were requested to list all of our open source components, just the direct dependencies, that's tens of thousands. And if you extend it to subsequent dependencies, that's I think almost in the hundreds of thousands, unless you dive into it, we're not aware of how much we're immersed in open source. Like every little thing we interact with has open source into it. So I think first of all, it's clear open source as one. If someone was still debating this it as one and it's part of our present and definitely a key part of our future, and it's only going to become more and more dramatic. Now the question becomes on how we manage open source and how we align it with our business.
So open core used to be the default answer here. You create an open source project and then you upsell it, you provide the enterprise value as a commercial offering, you provide the support or professional services. This has grown amazing companies like Red Hat, MongoDB and others, but that happened in a few decades back. And as we are running towards the singularity, things are speeding up and the speed of things today as far higher than the ones that happened before. So now when you're building an open source project, by the time it matures and you can commercialize it, other companies will commercialize it before you. So for example, look at Elastic. So Elastic built an entire ecosystem with Elastic search and Kibana, et cetera. And by the time Elastic matured with the open source project and created the category of our companies, AWS, CoraLogix, Logs.io stepped in and basically commercialized a SaaS version of it faster than Elastic themselves.
And then they started fighting over licensing, and then that infuriated the entire ecosystem and pushed Elastic to the side while they were the crown owners of this thing. And that forced them to basically pivot into a security company. You can see also a similar example with Docker. So Docker exploded as an open source project. It grew and grew and grew, and it pushed aside commercializing it. And when they had no more choice, they had to commercialize it, they ended up making the mistake of trying to take something back. Once you put it out, you can never put the genie back into the bottle. That's it. It's not yours anymore. But that was also apparently for Elastic. So once Elastic tried to change the license, AWS just forked it and created their own open source project for Elastic again.

Eric Anderson:
I think I'll just jump in here to point out that I think Terraform is an interesting situation because prior to them, the people that were changing licenses, Elastic and others cited the cloud providers as the competitive set. Terraform I think was explicit that we're worried about other startups commercializing this, and it was those other startups who forked. We had OpenTofu on the show recently, Spacelift and others. And so I think you're right. You're not just worried about some other incumbent eventually commercializing you, but peer startup companies will latch onto your project and commercialize it as well.

Or Weis:
It doesn't matter who or what. It's the ecosystem itself. The ecosystem itself is evolving faster than you were able to react as a single company. And ironically, the open source project is becoming an encumbering effect to you because you're wasting, well, you're investing energy in growing the open source project. You can't invest the energy in moving fast with it through the market. It's an irony but it's the fact. And yes, HashiCorp with Terraform is a terrific recent example. They realize that they are unable to commercialize it in the way that it is because of the changes in the ecosystem. And also there's a worry that they will lose control of it altogether. So a lot of people would come against this and say, "So wait a minute, why are you saying so, we can't do open source anymore, so there isn't a way to commercialize this?"
And I'm like, "No, hold your horses." You need to just think about it in advance. You need to realize that this motions are going to happen. So if you are going to be in a situation where you're cannibalizing your own market with your open source projects or you're enabling other players to eat on your own market through that, you're going to have a bad time. But if you create enough separation and you plan on symbiosis between your commercial offering and your open source offering, they can grow together and you'll never run into this problem. And one model I suggest for this is open foundations and symbiosis is one is based on top of the other. There are probably other symbiotic models that we can think of, but this one is the one that I found the most easy and natural to approach. And yes, it requires more thinking, it requires more design, but it's not that big of a deal. And I think if we start to apply more of this logic into open source projects we'll get better open source projects and we'll get better companies at the same time.

Eric Anderson:
Fantastic. Or, this is also an exciting time for the company, not just new funding, but you've got a bunch of things you just launched. Maybe you can tell us what's new around it Permit.

Or Weis:
Yeah, so we recently launched both new offerings for Permit elements and for more policy models. So maybe a few words on policy models. Everyone's familiar with RBAC role-based access control. It's the bread and butter of the ecosystem, but people are not as familiar with ABAC and ReBAC attribute based access control and relationship-based access control. But as applications are becoming more complex and having more advanced patterns, RBAC isn't enough anymore. And so more and more companies fighting themselves needing these more advanced models. And what we try to do if Permit is that you don't have to understand these models. You don't have to actually get into all the academia and knowledge and modeling scenarios. You can just work with simplified tools that will enable you to quickly shift from RBAC to ABAC and ReBAC and back and forth. We realize that software needs to be very malleable today.
It's about abstracting this and allow you to move quickly. And one of the recent models, so we had RBAC and ABAC from way back then very early on, and now we added ReBAC. So the ability to build basically a graph of hierarchies that connect everything, but unlike other vendors that tell you to literally draw the entire graph and model all the different edges and nodes, and you need to be a computer scientist on how you're going to be navigating on this graph, with Permit, again, we want a monkey to be able to work with this. So with Permit, we just guide you on to connecting dots. So we [inaudible 00:27:17] proof for concept called rolled derivation or we apply the concept called world derivation. So for example, let's say we have a customer that wants to manage farms. So they have an operation with a set of farms and then they have fields for each farm.
So with Permit, you can just create those dots and connect them. So you say, "I have farms, I have operations, and I have fields." And you say, "A field goes in a farm and a farm goes in an operation." And now you can assign roles for each. So you can be, for example, an owner of an operation, an owner of a farm, an owner of a field, just stick on those labels. And then you can say you can apply role derivation. You can say, if a field is a part of a farm and you are the farm owner, you automatically get an owner of each of the fields and you can say, if you are an operation owner, you automatically become an owner of the farm. It fits part of that operation. And these cascades, so you are now from the operation, can own all the fields.
You're putting basic labels, connecting dots, and the graph emerges for you without you having to think about it all day one. And you can do all of it with a very simplified UI. We feel that is our responsibility is Permit to take all of these complex ideas for the performance challenges, with all the modeling challenges, with all the intricate elements of how you connect scalable data and scalable policies and just make it as easy for you so you don't have to think about it. And this is what we launched now with ReBAC support. So our ReBAC support is as simple as our ABAC support and then it's our RBAC support. So this is one thing we're very excited about.
And the other one is Permit elements. So we provide interfaces not just for yourself as a stakeholder, managing the policy, but also for your end customers. So think about being a customer, being a user using an app. You're constantly doing access control, you are inviting upper users, you are assigning roles to them, you're giving them time-based access. You are impersonating them and viewing the system as if you're them and trying to view their perspective. You are accessing the system with additional privileges in emergency cases. And this list just goes on and on and on. All of these are UI interactions that you already expect to see in products, but why are we constantly rebuilding them from scratch?
So we decided with Permit elements to put an end to that. So when we say never build permissions, again, it's the entire package. So you get a user management scheme, get audit logs, you get approval flows, you get all of these ready to be embedded into your software, again, so you can focus on what's unique to your product. And now with approval flows for Permit elements that again, I think we are very excited about. We've constantly got customers asking us, "Oh, I need to have this flow in my product. And it's very complex to build. There's also cryptography on the tokens that need to be sent, can you handle this for me, it's a nuisance," and we're excited to take it off everyone's table and make sure it runs right.

Eric Anderson:
As you spoke there Or, I wanted to revisit the permissions space a little bit more. When I talk to developers of SaaS products. Some of them are like you in your Rookout experience and they're like, "Man, I hate permissions. This was a big pain." And others are like, "Oh, we added a couple roles and haven't really thought about it again." Certainly most developers listening to a show like this has experienced AWS IAM. They can imagine a very complex application having a very complex permissioning system. And they're like, "Definitely, I'm sure you have customers who feeling a ton of permission pain," but I also wonder that there was a time before Auth0 when everybody built their own authentication system and didn't think they needed one from a vendor. Is there a world in which everybody decides it's just normal to pull in an outsourced third party permissioning system on day one of a new app? And what's going to change in people's minds? What will they realize in order for that real world to exist?

Or Weis:
First of all, I'd start with saying that it's okay not to do so. If you just have a basic application now and you feel this is not a priority for you, that is great. You should focus on your priorities and what's right for you at the moment in time. But you do need to realize that as your application evolves, it's a matter of time until you face more complex authorization requirements. It's on a matter of if it's a question of when. And this question also meets companies earlier and earlier because what we expect from software today, that bar is also constantly rising. The compliance and privacy requirements that you have are constantly being pushed upwards. Just look at both the European Union's new cyber requirements and the Biden administration's requirements. Look at how more and more companies are trying to be SOC to and GDPR-compliant at day one.
And all these compliance requirements are 80 to 90% access controlled mechanics that you need to make it. So either manage them manually or you bake them in into what you're building. And also the patterns in the applications themselves. The way we interact with other people, the way our features interact with data, they're constantly becoming more complex. So the bar for basic access control is constantly rising as well. So if 10 years ago you could have just done not even roles, you could have just done two roles. You have the developers or admin and everyone else is just a user, you just maybe have some access control list. That word is gone. Almost every application today will end up in RBAC within months and in a year from now, most applications will run into RBAC and ABAC and maybe even ReBAC within months and this period of time continue to become shorter and shorter and shorter, especially as AI systems proliferate the space. Just think about the speed and complexity that they interact with other software.
So it's really a question of time, both in terms of the growth of your software and the growth of the entire complexity of the software market. And I think I don't need to convince people in general with Permit, all of our customers, our exception, are all inbound. When I talk to customers, I rarely pitch the product. They come to me after they say they want the product, they already played with it, and they come within specific questions. So I never tell people, "Oh, you have to use this at day one." Use this on the day that is right for you and just plan ahead. Think about the best practices and maybe design your software as you're building it. If you're implementing on your own, design it in a way that you don't have to reshuffle the entire deck to upgrade to the new features, and it's not that hard to do.
And when you do come to us and you want to use Permit, one of the key things that we try to do is make the migration or the adoption easy enough, and we combine two key requirements into the design. Both have it gradual. So you can apply Permit on a single function, single route, single middleware, single microservice, single reverse proxy, single API gateway. And you can choose how wide of a blanket you want to start with. And the other part is be able to do this fast. So we have SDKs for every language. We have plugins for most reverse proxies and API gateways.
So you can move in quickly and apply it on the subsidy that you want with speed. As long as you don't hard fuse your policy too much into your code that you'll have to clean it out later. You can have a good time. And what I recommend a lot of people do is even if you're microservice for authorization, it's just a function that returns true, just take it out and have it as a separate service and it'll make your life a lot easier later. And the cost is basically negligible. So small steps now, big payouts later, and we don't need to go crazy about it. But yes, this is coming for everyone, but we can take it in our own pace.

Eric Anderson:
Or anything we didn't cover today that you'd want to cover.

Or Weis:
Another item that comes to mind is a podcast that I run with our dev advocate Philip, also known as Developer Philip on YouTube, we have a podcast called Command+Shift+Left which is one of the most fun things I get to do as part of this job. It's a developer-focused podcast and with a unique format. So it's not like your interview format, but instead you have four developer leaders coming in with developer-oriented fact. And then we just laugh and debate and foreign additional facts. And it's very lighthearted, it's very fun. And we constantly find ourselves getting into, are we living in a simulation or not? Some way it's all of our episodes derail into that. But I really enjoy having that, doing that podcast because as I said, very lighthearted, very fun. And I bring in a lot of funny people. And for me it's just hanging out with friends. And I get the sense that people also enjoy listening to the podcast and just hanging out with us as well.

Eric Anderson:
So that's Command+Shift+Left.

Or Weis:
Command+Shift+Left and you find it on most social networks with the tag JustShiftLeft and you'll find it on command-shift-left.com with CMD-Shift-Left. And it's on Spotify, Google Podcasts, apple Podcast, et cetera.

Eric Anderson:
Or thank you for coming on today. And also thank you for OPAL, you and your team. This was a gift to humanity. Maybe that's not what you plan to give to humanity when your day is done, but at least you've given that.

Or Weis:
I think it's a good start and it opens up my appetite to do even more and to find good alignment points for good open source.

Eric Anderson:
You can subscribe to the podcast and check out our community slack and newsletter at contributor.fyi. If you like the show, please leave a rating and review on Apple Podcasts, Spotify, or wherever you get your podcasts. Until next time, I'm Eric Anderson, and this has been Contributor.