Cerbos

Authorization can be a time-consuming process, but you can never get away from it because it is just as essential to your product and business. What if there is a way to make this easy?

With Cerbos, that is possible. Cerbos is the authorization layer for software applications to be able to quickly and securely implement roles and permissions. In this episode, its CEO and Founder Emre Baran joins us to help us get to know the work they are doing and how they have built and grown it.

He talks about decoupling authorization, making life easy for developers to implement this. He also breaks down the differences between authorization, authentication, and feature flagging as well as the benefits of open source to developing trust. Emre fills us with so many insights about the world of Cerbos and how they are making authorization simpler.

—

I’m interested to talk to Emre Barron, who is the CEO and Co-Founder of Cerbos. Funnily enough, Emre, I was at CubeCon in Amsterdam. I spent quite a lot of time talking with one of your colleagues. My daughter has your little dinosaur on the front of our laptop now. Your marketing is doing well in our house. Great to have you on.

Thank you very much. Great to be here.

That was my first CubeCon. I’ve got a bunch of new stickers and spoke to a bunch of companies. Legitimately, yours was one of the few that was relevant to Flagsmith because we did that classic thing of building it all ourselves. Before we get into that, do you want to give me a little bit of background about yourself and the project?

I’ve been a Cofounder and CTO twice, probably in aggregate about 12-13 years. Similarly, I started my career as a software engineer for about a little bit over five years. I also have been a product manager for over four years at Google. In every single one of these journeys, we had to deal with implementing roles and permissions. Every single time we were doing it, we were always asking ourselves, “Why are we still doing this? Why isn’t there a good enough solution?” Our journey started like that. Our journey started by not wanting to reinvent the wheel and how we can handle authorization. How can we handle the implementation of roles and permissions?

Can you explain a little bit in terms of the integration journey for a typical customer?

Before I go there, I want to a little bit more explain what Cerbos is because it’ll probably make much more sense. Cerbos is the authorization layer for software applications to be able to quickly and securely implement roles and permissions. Cerbos provides a very fast service that you can run in your environment, which is configured with your roles and permissions requirements. In return, it gives you a very simple API that can be accessed from anywhere on your application stack.

Your application can ask a very simple question, “Can this principle do this action on this resource?” Cerbos replies would allow or deny which the developer implements. That way, we enable decoupling of application logic from authorization logic. Very similar to feature flags and Flagsmith. We want to be able to decouple authorization so it can be separately managed without having it so tied to the application.

That was one of the interesting things when I chatted to your team. There are so many parallels between what you guys are doing and what we are doing. Especially around latency and having nice, clean, and simple SDKs and all that sort of stuff. The more we talked, the more we realized that we’re solving almost exactly the same problem, just in different dimensions.

Going back to your previous question in the integration, which is a key area for us to focus on in order to be able to get our adoption right. When you think about authorization, very similarly, feature flagging, the very first thing is your code needs to interact with this. As one of the key interaction point is being able to have SDKs so that developers can very easily implement without having to deal with making service calls and having to deal with interaction with infrastructure. With that, we paid a lot of attention into our SDKs. Making sure in every major language, we have SDKs. Our adoption of having protocol buffers and GRPC made it very simple for us to have uniform integrations and uniform interactions in every single one of these languages.

The second part of our journey has been around, once we have SDKs, how do we make life easy for developers to implement this? That’s where the integrations with many frameworks come into play. We want to make sure that we can provide examples to developers to figure out how or where to put authorization in their stack if they’re using FastAPI, Remix, or SvelteKit. Many of those, we have examples for.

Of course, authorization never lives on its own. Authorization is a natural step right after authentication. For those who are not clear, authorization and authentication usually gets mixed up very much. Authentication is the act of logging in. Knowing the user who they are and verifying who they say they are. Right after you’ve verified the user and figured out where they belong in the organization and what roles they have, authorization comes into play. Authorization is the act of, “Can this user do this action? Are they allowed to do this action?”

Authorization never lives on its own. Authorization is a natural step right after authentication.

A key part of our integration was showing developers how this flow works. How do you take an identity from an authentication for a flow and marry it with authorization in order to be able to make that decision? As we were building our developer experience and examples of how to integrate a key area for us was how to integrate authorization with authentication. We have multiple examples that we provide including a very generic JWT Token integration example.

One of the questions that I was curious to know was, how clear were the boundaries in terms of what Cerbos was going to cover? There’s a huge space here. You could buy off an enormous chunk of work if you wanted to. Were those boundaries clear to you when you sat down and were putting your napkin drawing of the business, or has that been something that’s been a process that’s occurred over time?

It’s been a process. It’s been a boundary that’s been getting clearly clear and smaller in terms of what we want to cover. What we’re trying to address is a classic problem with software development. When building an MVP, nobody pays too much attention to a username and password login, roles and permissions, and the separation of all those things.

When we look into this much deeper and how these evolve as companies grow, become enterprise-ready and more advanced, what we found is there are three distinct areas in an application security layer. One is authentication. It’s like checking a username and password, and verifying who the user is. The second one is a directory. Once you know who they are, you verify them. Who are they? Where do they belong? What departments do they belong to? What roles do they have? What roles can they assume in any given situation? The third one is the authorization itself. Once you know who’s acting and what the specific action they’re doing, are they allowed to do that?

That boundary became very clear to us over time as we were building our product. In the very beginning, we had about 150 to 200 interviews with different companies trying to figure out. We get to see how early-stage companies who don’t use any of these decoupled services tend to mush them all into one. As they hit these different pain points, it suddenly takes a very long time to refactor and extract them one by one and they have to compartmentalize these things.

To us, that became clear. Very early on in our journey, we asked ourselves, “What is our API? What’s a very simple API that we can provide that’s going to scale infinitely? That’s going to scale and it’s going to stand the test of time. Similar companies out there, we were drawn by this because when you look at Twilio or Stripe, that’s what they very successfully have done. It’s like, “Here’s the boundary. Here’s the simple API call. Let’s abstract all of the complexity behind this API.”

To us, that was the very first and most used API, which is to check API. Being able to ask the question, “Can this principal do this action on this resource?” Being able to reply to that yes or no. Having to do that in milliseconds or nanoseconds so that an application request doesn’t get blocked in and gets minimal block so that it can continue with a request.

It’s interesting to think about one of the actual standard differences between feature flagging and what Cerbos is doing is I guess it’s quite common for folk and we’re in this camp to roll their own RBAC stuff. They’re staring down the barrel of a multi-month refactor to unpick all this stuff, which has to work perfectly because that’s absolutely critical code paths. Is it more common for people bringing on your tool to be doing it as part of that refactor? Are they sensible people who sit down and realize that this sort of thing’s best abstracted away from day one?

We get to see three different times throughout a software application’s lifetime that authorization gets reconsidered. Phase one is when you’re building MVP. A lot of the experienced founders and technical teams try to bring this on as early as possible because they’ve seen this. They’ve had the experience of having to spend 2 to 3 months of software engineer teams’ time in order to refactor this and rebuild it. Experienced founders and experienced technical teams try to do this very early on, but inexperienced ones don’t even think about this problem. They’ve never experienced it before. They just get on with very simple thing with simple solutions. That simple solution tends to be very simple if-then-else block. I’m sure you’re very familiar with it in the feature flag.

The second and third times are the realization of you haven’t done it right in the first time. Whether it wasn’t a requirement, perhaps it became apparent that you needed this later on. This company’s usual usually in startup terms, those that are going series A level companies think they’re going enterprise. They need to take this code base from their MVP PoC state into a much more stable thing. They reconsider this infrastructure change and trying to get that robust. They also tend to see when they have to go enterprise, which is the time when they have a customer with 10,000 users in there. Those are the three main times that we see all of this factoring going on.

Something you mentioned in your question is very similar to feature flagging, but there’s a very core difference between feature flagging and authorization. With feature flagging, your context doesn’t change that much for a given customer or user. You can actually take a decision and cash it. Whereas in authorization, every request is unique. That’s one of the biggest challenges because you cannot cash that. There are infinite possibilities when you take the context into play. We want to make sure that Cerbos provides a very fast response in all of these situations.

How does that work in terms of architecturally? Is that evaluation code running within the SDK and within my runtime? Is it running on the Cerbos platform?

Let me take a step back and explain how Cerbos is deployed first about what we recommend. Cerbos is a binary. When you look at it, it’s a service that runs in your environment. We provide Cerbos in a binary but equally in a container. Our customers and users can run Cerbos in a container as a sidecar. They can run it in community service. They can deploy it on a VM. We even have customers running Cerbos in AWS Lambda environments. The key thing about Cerbos is it’s stateless. It doesn’t depend on any other data provider and having to deal with data, collecting data, and storing it, making decisions on that. Everything that Cerbos needs is in its policy and in the request.

When a Cerbos instance launches, it loads its policies which are in very simple human-readable YAML form that can define your roles and actions in that YAML language specification. We’ve also included Google’s common expression language for anything more advanced that you might need for conditions. A Cerbos instance reads its configuration, loads it in the memory, and optimizes it. From that moment on, it’s ready to answer any incoming request. All of the requests are evaluated on the spot with the incoming request and the policy, and it returns an answer. If, at any given stage, there’s a change to a policy or there’s an update to a policy, Cerbos instances automatically detect that and update their policies to respond with the new policy in might.

What protocol is that? In my code, when I’m saying like, “Can Emre perform this action on this project?” What’s happening to that request?

That request first hits our SDKs in many languages. You make a function call and that SDK in that language converts that and makes a GRPC call to Cerbos. Cerbos evaluates that and returns the GRPC call to the SDK. That’s the very base and very fast layer, but on top of it for applications that want to interact with it, with HTTP, we also have a REST API that sits on top of that GRPC call.

It’s interesting. The similarities just keep going on and on. One of the things that we did was, originally, we just had a REST API. We did a bunch of work in 2022 to bring our rules engine into all of the languages which we support, so now we can have it for service-side environments. Anyway, we can have Flag evaluations happening within the SDK runtime, which gives you a bunch of benefits. In terms of the genesis of the open-source project, how did that come about? Was it a thing that you were hacking on by yourself in some spare time? Did you go, “There’s a gaping hole in the market for a project like this and I’m going to assemble a team and start building it?”

For the genesis of it, I need to go back to Circa 2015 and 2016 in our previous company, where we had to go and be that third phase of being real enterprise-ready. We had world-class customers who had 30,000 users themselves. Our application only had three roles where our customers were telling us like, “We can’t have a manager role in have it assigned to 20,000 people or 10,000 people in our organization. We have different countries. We have different departments. Every country and department behaves differently.”

Similarly, at the time, there was also an effort around having agencies as our partners. We needed to figure out how can we layer an agency as an agent in between and give them some privileges, but not everything a customer can do. Being able to somebody edit and prepare, let’s say, a campaign and somebody else publish it and everything else.

That was a time similarly we were spending close to $2 million on Google Cloud and AWS. The way we went to them was like, “You guys have this in your environment. You have your own internal IAMs. We don’t need the I. We just need the AM from you. Can we get this as an API from your environment and define our own resources?” Just because we were spending that much money with them, we had access to their developers and product managers. For a while, our request was on the list of features to be done. Eventually, we saw that drop out and in the meantime, we had built our own. That experience scarred me.

At the time, I built a mini prototype just like AWS’ language, how can we have our own? Of course, as a CTO, none of my code ran in production by then. I was about six years in. Pretty much all of my code that was written was retired, thankfully. Our engineering team looked at it and they went like, “That’s a cute demo, but we’re not going to maintain this. This is too much for us. We’re going to do another simple implementation of it.” Since then, this was an idea that was sitting in the back of my mind.

Once I left Qubit, I was looking into what are the areas that I have good experience in and what are the big pain points in the industry that need to be solved? One day I was driving and there was a podcast about Okta and how they had a similar journey. At that point, all the stars aligned. I’m like, “This is something that we need to build.” I rebuilt a prototype and shared it with my cofounder. Of course, he took it and said, “That’s not how you do it. This is how you do it.” He has rebuilt it.

That’s been the genesis of the whole. Of course, after we had the mini prototype, we looked at all the solutions that were available in the markets. We looked at all the libraries and what’s missing from that great developer experience? How can we implement that? We looked at a couple of other solutions that had very complex programming languages. We looked into how do we simplify the whole Rego or Polar programming languages into a very simple YAML. To make it accessible to 99% of developers who are not willing to learn a whole new programming language.

We’ve done about 200 or so interviews with different companies and we refined it. The genesis of open-source came from there. Throughout those interviews, one of the key things that we realized for developers to be able to trust a solution that will run in the heart of their network. It had to be open-source, it had to be transparent, and it had to have the security and peace of mind mindset at the core of it. Having the project open-source checked all these boxes for us.

For developers to trust a solution that will run in the heart of their network, it has to be open-source, transparent, and have the security and peace of mind set at the core of it.

Those really hard requirements align perfectly with an open-source project. Apart from access to the data in your business, making sure that this stuff is right is probably the next most important thing on a CTO. That’s the thing that would keep them up at night.

The key thing was this is security. It needs to run right. It needs to run all the time. This aligned very much so with the major principles we had in mind when we were building this product. It had to be reliable, it had to be scalable, it had to be very fast while providing a good developer experience, and being scalable and extensible.

How did you go about building the project and the business, then? Did you think, “I need to go and raise some money for this because it’s too much of a thing to snap off and try to build by myself or in some spare time?” The other thing that’s interesting is you could over-engineer this massively. I imagine you could go down some rabbit holes that would probably be quite fun to go down, I guess. In terms of technical wizardry or not respecting the boundaries you’ve set for yourself. Was it clear to you at this point where it’s like, “This is going to be ten folks developing this for a year before we’re going to be able to get something?” How murky was that?

It took us a month or two before I realized what we needed. First of all, your first point around over-engineering, you’re absolutely correct. We can dive into any of these areas and overcook it, but one of the key things that always kept us to our core was what was going to be the developer experience. We wanted to make sure that this is a developer-first product.

When you look at our environment, we’re dealing with three different personas. 1) Developers. 2) Product managers. 3) Security teams or CISOs, Chief Security Officers, Chief Information Officers. Going back to the beginning of the conversation, if you left the world to developers, there would be only two roles in any given software application. It would be a super user, read-only, and all those people who can’t log in.

That’s what most IAM setups look like at the start. Everyone’s got admin access.

Indeed, and that’s normal because everybody building a software application wants to focus on building value with the business domain and the business process they’re trying to improve. When you look at security and all of these requirements, they’re just table stake requirements or they are an absolute requirement to have that doesn’t differentiate any two applications apart.

Everybody who’s building a software application wants to focus on building value with the business domain and the business process they’re trying to improve.

We wanted to make sure that we knew we had to focus on developers. Although all of the requirements that come in are coming from product managers or CISOs, 100% of the time, developers take those requirements and they need to implement it. When it comes to software security and within the code, it’s very rare that a CTO, product manager or CISO has any say on how something is implemented.

We wanted to make sure we needed to satisfy developers’ requirements, developers’ experience and making developers’ life very easy with us. We used that as the driver, our very initial fundraise back in March and April 2021. That’s when we started having conversations with a lot of investors. Of course, this was a COVID time, so we benefited from having conversations with about 90 VCs. Everybody wanted to have a conversation with us.

When you look at security, it’s a true horizontal. It applies to every software that’s being built. Security, especially roles and access or roles and permissions, are present in every B2B application. It’s because you have multiple users in multiple roles working on a workflow, trying to satisfy and complete a workflow.

When you look at many B2C applications, although you don’t see permissions in their front-end application, let’s take Uber, for example. In the phone app, you don’t get to see roles and permissions. However, many of those B2C operations also have a back office where they have multiple users in multiple roles that they need to satisfy the requirements of roles and permissions. Usually, they have customer service folks who can onboard drivers, abuse, compliance, and various other things.

That was a story we took to our investors and we said, “We are going to be a small team. We’re going to evangelize decoupled authorization, which I still think is a very technical term, but it perfectly captures what we’re doing. We’re going to decouple and evangelize that because when you look at the security ecosystem, authentication got decoupled by the likes of Auth0, FusionAuth, and Okta. Directory got decoupled very early on in the 1980s with LDAP and then later on with everything else. Let’s skip authorization for a second, but logs in the accounting, the audits got decoupled by all sorts of odds, logs, processors, and SCIM providers, etc. Authorization is still one of those ones that are still being done in code by developers.

Why do you think that is?

We believe it’s because there’s a very fine line between business logic and authorization logic that developers don’t have time to think about, therefore, it’s modelled together. That’s exactly the fine line we’re drawing with our API. As long as you can ask this question and you can model that into our policy and role, that’s authorization logic. Everything else is business logic.

It’s kind of interesting, though. I’m able to say this because we did exactly this thing. It’s not great engineering. If you think about the problem, you’re going to be thinking like, “I’ve got one role now, but in three years, I’ll probably have user-configurable ones, I’ll have groups and all this sort of stuff.” For some reason, when we were building out, our role-based access, we never sat down and were like, “This is a perfect candidate of something that we should encapsulate and break off.”

I didn’t go and look for Google or search on GitHub for a role-based access library or something like that. Our API’s built in Django and there are RBAC modules for Django. We looked at a couple of those, but they didn’t satisfy what we were doing, so we went ahead and built it ourselves. It is like a classic engineering trap that people seem to fall into constantly.

It is because it’s one of those things that started very simple. It starts with a very simple, if-then-else statement. Anyone who has studied computer software engineering is like, “That problem, I can do it with an if-else statement. It’s a very simple look up to the database and making a decision.” Often when we first start that, it starts with that very simple, from zero roles, you go to one role, and it’s a simple implementation.

It’s one of those things that collect technical debt over time as things get more complex. Often companies find themselves having to rewrite that layer, realizing, “The requirements for these never stop coming. They’re going to keep coming. How do we generalize this now? Let’s put a crack team together on top of this, and let’s build a solution that’s going to take us into the future.”

Often what they don’t realize is that solution is now they’re starting to over-engineer because they’re starting to over-engineer for the future. The reason they do that is, in many software companies, there is no infrastructure software engineering team that’s purely focusing on security. It’s a very waterfall approach. “Let’s just build this. Let’s see how long it takes us, and then we’re going to go back.” Usually, that team you build together, once they build everything else, disband and go back to their day jobs very much so focusing on features that are revenue-driving features rather than infrastructure and tech debt.

Moving on in terms of the development of the project and turning into a business, was it obvious to you where the commercial and open-source lines lay? Is that something that you guys are still thinking about?

One thing that was clear to us from day one, unlike many open-source projects, which start as a hobby and then turn into our business, we started Cerbos as a business. We knew the potential of this. We knew where it fits. A lot of our early thinking and design has been very much so focused on that business thinking. The lines between commercial and open-source are, the jury’s out. We’re still building our open-source product. We are releasing our commercial product on top of it.

One of the key things that we always wanted to make sure is, any developer that is tempted to say, “I can do this. I can write this” isn’t tempted to write it. We wanted to make sure that open-source and free product is always available to developers who are willing to put some time in to do the integration or to get it up and running.

We draw a lot of our commercial product in commercial thinking because if a developer can take our open-source product, implement it, and run it themselves, they should always be able to. When their requirements and role starts going out of a developer and start boarding into DevOps where they have to now build CI/CD pipelines to be able to deploy Cerbos or to deploy new policies and updates. We’re providing tools for that for premium. Similarly, on our roadmap, we have features for product managers to be able to do things on their own without having to rely on developers, chief security officers, or security teams being able to empower them and make sure that they don’t have to depend on a developer to get their job done.

Basically, what we’re saying is if I, as the developer, am maintaining and committing that YAML file into the rest of my code, then that’s going to be open for the duration.

All of that is free and open-source if you are willing to write your own YAML file, take a Cerbos instance and hook it up to wherever you’re storing your YAML files and configuration files and use our unit testing framework to evaluate your policies before you deploy them. Also, if you are willing to take all the logs out and stream wherever you like and your security team’s request, willing to write your analysis code or run some sort of query on top of it. As a developer, if you’d like to offload a lot of that work to your colleagues who are not technically capable but should be able to do it, then that borders into our premium offering.

I’m trying to think how many people I’ve talked to for this show who have sat down and said, “I want to build a business around this idea and this open-source project from day one, almost from the first commit of code.” In terms of building community and open-source adoption around it, how have you gone about doing that?

That is very much so focused on interacting with developers and people who are in charge of technical architecture and have to deal with this. That is the community that we’re interacting with or people who are tasked with this and they don’t want to touch it. That has always been our community. We have had a lot of conversations as a lot of our outreach and developer evangelism is a route. Making sure that we are hitting the right people at the right time. The right time is very hard to identify from the outside. We don’t know when somebody’s technical debt is accruing and they have to now reconsider it.

That’s an area that we’re still in search for trying to identify what are the black box marker of this from outside when to approach a company. In the meantime, we are very much so focusing on the evangelization of decoupled authorization. Going back to what I was saying earlier, when you look at a company’s lifecycle, in about 10 years, they consider this 3 times throughout the company’s lifecycle.

We need to make sure that the day they consider it, we are either very accessible on the internet and we provide a very good SEO, SEM, and great examples as they lend showing as a simple solution. Also, get to them at some point, have a couple of touchpoints, and educate them, “This is something else that’s been decoupled. It’s much better than the ways of taking a library and trying to forge it into your environment, trying to supplement it with all your additional services.”

In terms of the commercial side of the business, what have you got coming up around that?

We are currently in a private beta of Cerbos Cloud, which is the solution that currently makes developers’ lives easier in order to be able to manage their running instances and deploy our policies where we get to do the CI/CD and real-time distribution of their policies to their running instances. Throughout 2023, we’ll be releasing additional features in that premium solution where we empower the product managers and CISOs. Middle of June 2023, we’ll be opening it up to public beta where not only our existing users or companies that we have relationships with use it but anyone who can sign up and start experimenting with Cerbos.

In terms of the integrations that you are working on, I could imagine there are hundreds of different platforms and services that you could potentially integrate with. How are you dealing with that problem and how do you prioritize what to build? I’m thinking of more, you could build an integration with Terraform, Pulumi, or Amazon. That’s almost freaking me out.

It is a very big footprint, but the way that we are narrowing that surface down is by very much so focusing on the application layer first. If it is something that helps people build their applications, then that’s within our realm. By now, we’ve done SDK, so that’s a very basic building block that anybody can take and interact with. They don’t have to be on a specific platform or framework.

When it comes to frameworks, we started looking at what are the most common frameworks that applications get written in. Whether it’s Express.js, ExtJS, Remix, SvelteKit has a big uptake, FastAPI, or GraphQL, which is a very common one. We very much so take a look at A) The market share of these different environments and B) Into the requests in our Slack community where the requests come from. Our users ask, “How do I build Cerbos into X? What layer do we interact with?” We try to prioritize always those.

As you mentioned, it’s unlimited. There are so many of them. We know that we’re not going to be able to do all, but that’s also an area where we rely on our community. Our community started contributing to our code base. They started providing examples and we’re very happy to take contributions from them. Another area that might be worth mentioning here is the application-building frameworks and data access layers that are very important to Cerbos such as Prisma and SQLAlchemy.

Cerbos not only can always answer the question, “Can this user do this action on this resource?” which is a classic, very simple API call. Sometimes the API call is about rendering a homepage, being able to tell, and being able to display all the records a user can edit or has permission to edit. For that, Cerbos is a secondary API, which we call the query plan API.

It is an authorization where data fetching returns an abstract syntax tree that you can implement in your data fetching layer’s criteria, where it close very simple SQL in filters for MongoDB, etc. It allows you to do authorization-aware data fetching. The very first two examples we’ve built are Prisma and SQLAlchemy. It’s the two most popular ones, but then we have a backlog of additional ORMs to integrate with and show how Cerbos can be used again.

One of your colleagues demoed that to me when I was chatting at CubeCon. If you’re tuning into this, you should definitely check that out because it’s really cool. As someone who’s built a lot of multi-tenant SaaS, that’s a really cool thing to be able to lean on. I thought that was a great idea. In terms of competition from folk, is this something that you are worried about? Does this feel like one of those areas where a large cloud provider could maybe take liberty in terms of white labeling or shrink wrap in that service and giving it a three-letter acronym in their application library? How have you gone about defending from that?

We had that conversation very early on in terms of how we license it. Do we use an elastic license or do we use something else? That was an area that we potentially approached a bit naively saying, “Let’s first have that problem. Let’s have a problem where this framework is very popular that Amazon, what they’ve done with Elastic potentially will want to do that.

For the time being, we are in Apache 2.0 license. We are open with that vulnerability. I would say it’s open. However, the way that we look at what we are doing, our vision, and our mission is very much so on the forefront of decoupling authorization. For that solution to take off, the decoupling of authorization needs to become very common use. That would be a great problem to have.

Looking at the other competition and very much so, a couple of other companies and open-source projects do decoupled authorization. They all have very similar approaches, but then they all do technically different things. We believe Cerbos is the only stateless one that is a limitless scale. Looking at the response times, it’s pretty much the fastest one, which to us, are two of our pillars in building the solution.

I guess you could also easily get an n+1 thing where you’re querying that API many times to render a page or provide an adjacent response or something like that. That’s one of the differences with Flagsmith, but quite often, it’s once per session, but we have the same problem where we can’t hash anything because most people request flags to a user context or something of that nature.

Finally, Emre, we’re hoping to get this episode out before you launch this new project. Is that the cloud service that you were talking about earlier?

It is. It’s Cerbos Cloud, which is a cloud-hosted control plane. What Cerbos Cloud isn’t is a Serbos Cloud-hosted Cerbos where you have to make a request to a cloud. Going back multiple times, we spoke about the importance of speed. No matter how many milliseconds you reduce it to, then you are constrained by your network speed. Authorization is in the blocking part of every request. Anytime you add in a cloud request will show in the response times of your API.

That’s why we always choose to have Cerbos hosted in a client’s environment. Cerbos Cloud is the very first version that’s coming out. It is that managed CI/CD pipeline that makes life easier for developers in managing all the instances they’re running and real-time evaluation and deployment of updates into those instances.

In terms of deploying the infrastructure to larger organizations on-premise, I guess that’s something that is on your roadmap, is that fair to say?

It is fair to say, however, we are first focusing on getting Cerbos Cloud right, but the way that we’re engineering Cerbos Cloud, we’re aware that there are multiple users of Cerbos currently running Cerbos in air-gapped environments. Whether it’s government agencies that require that for security or some of our users run Cerbos in physical ATMs or physical machines that are air-gapped, the communication is minimal.

On our long-term roadmap, we have a self-hosted instance of the control plane so it can work within an air-gapped environment. However, for the time being, we are very much so focusing on a cloud-hosted one where we get to do all of our learning, we can optimize everything, and then eventually, we’ll look into how we can have itself hosted.

Emre, thank you so much for your time. It’s frustrating because that backlog, like most projects, keeps getting bigger and bigger. Refactor our self-built RBAC is definitely something that’s been in the back of our minds for a while. That’s definitely a few extra stars for your project from the team here at Flagsmith.

Thank you. I would highly encourage you to go check out our onboarding tutorial because getting a Cerbos instance app takes literally a couple of seconds. The majority of the work, which is not that much, is looking at your requirements and building a policy for resources. You don’t have to rip and replace everything in your environment.

You can just choose one corner of your application, build a policy, and then look at where those if-then-else statements are happening in your code base and make those requests. One of our largest users is a major utility company in the UK and that’s exactly the journey they started with. With just three resources they built policies for and then went up to hundreds of policies. Now, they completely ripped and replaced their authorization layer with Cerbos.

Emre, thanks very much for your time. Good luck on the launch.

Thank you very much.

Great stuff.

Important Links

• Cerbos
• Flagsmith
• Cerbos Cloud
• Express.js
• Prisma
• SQLAlchemy