The home team welcomes Alex Olivier, cofounder and product lead at Cerbos, for a conversation about how to centralize business logic in a microservices environment, the value of stateless applications, and what’s under Cerbos’s hood.
Cerbos is an open-source, scalable authorization-as-a-service that aims to make implementing roles and permissions a cinch. Explore their docs or see how their customers are using Cerbos.
Stateless applications like Cerbos don’t retain data from previous activities, giving devs predictable plug-and-play functionality across cloud, hybrid, on-prem, and edge instances.
Connect with Alex on LinkedIn and Twitter.
Shoutout to Lifeboat badge winner Hoopje for rescuing Print in bold on a terminal from the dustbin of history.
[intro music plays]
Ben Popper Hello, everybody. Welcome back to the Stack Overflow Podcast, a place to talk all things software and technology. I am your host, Ben Popper, joined as I often am by my wonderful colleague and collaborator, Cassidy Williams, the CTO over at Contenda. Hi, Cassidy.
Cassidy Williams Hello! I'm excited for today.
BP Yeah, so we got an email saying, “Would you like to chat with some folks at Cerbos.dev,” and I shared it with the group and you said, “These folks are cool, we should have them on.” So why do you think they're cool and what are we going to be talking about today?
CW Yeah, so Cerbos is a company that makes user permissions and authorization simple to manage and to implement and stuff. And that is hard to do, so any company that makes developer tools that make some aspect of the development process easier I think is awesome. And also they're open core and open source which I also think is even cooler.
BP Yeah, I was watching some of the videos about them over the last couple days to learn a bit, and a couple other things that came up within there was where they fit in to the mesh of monolith, microservices, APIs, containers. Like, how they kind of tie into the different versions of modern infrastructure that startups are doing to try to make it easier to sort of quickly get to scale, and like you said, implement some things where there's no value to the company of writing it yourself. So without further ado, I'd like to welcome Alex from Cerbos to the program. Hi, Alex.
Alex Olivier Hey, Ben. Hi, Cassidy. How’re you doing?
CW Hey!
BP Good, how are you?
AO Very well, thanks. Very pleased to be here. Looking forward to a fun chat.
BP So we always ask folks at the beginning, just give us a quick flyover. How did you get into the world of software and technology and how'd you find yourself in the role you're at today?
AO Yeah, this is a fun one. So as a very young kid, five or six, my dad was in IT and he started teaching me to code and I was doing Basic and stuff in MS-DOS and these sort of things and kind of have always been drawn to tech and computers. And as was about every other 10-year-old in the late-90’s, I was reading Harry Potter books and I was also writing code and I built a little Harry Potter website that kind of blew up and exploded and had millions of visitors a month and kind of got into tech that way, combining everything too. Yeah, it was pretty cool. I got to go to the film premieres and meet all the cast and that sort of stuff.
CW Oh my gosh.
AO The bit of all that whole experience that I liked the most was actually designing and building this system that had to be scalable and handle that sort of traffic back before AWS was a thing, so running bare metal machines and such.
BP Right, couldn't ask CloudFlare to help you out. I think one key thing there is, so many people who come on the show tell us, “I got into this because of my love of x,” games, fandom, Neopets, whatever it may be, so we always love hearing what it was that sort of hooked you in and then led you to start to use the technology and learn about the technology and build with the tools, so that's very cool.
AO Yeah, I just kind of really, really fell down the rabbit hole. I went into computer science at university and these sort of things, and then worked at Microsoft for a bit to see what enterprise is really like and then fell into the world of startups where I met actually the co-founder of Cerbos, actually both co-founders of Cerbos, and worked there as a sort of front end developer, went into sort of tech lead, did some sort of sales engineering, and then ended up in the dark side of product management, you could say. But I always very much focused on the data and infrastructure side of things, so always working out how we can scalably build systems, making sure that they would work at the kind of performance we required, because one of our systems was doing 25 billion events a day through it. So scale, performance, latency, optimizing architectures was very much where I spent a lot of my time, and I went to a few other different startups and different verticals to do the same thing. But there was that one commonality, which is that I always had to keep building authorization and permissions and roles, hence we ended up working on Cerbos to solve a pain I had myself many times over, once and for all.
CW First of all, the fact that you got to do so many cool things from your early days of building stuff is so neat. You had millions and millions of users; I had like five from my middle school, so that's so awesome in general. But yeah, back to Cerbos, it's something that, like you said, it solves a very real need. I'm sure there's so many things that you could dabble in and talk about, but I'd love to ask about it being an open source company and what have been some of the benefits and pitfalls to that.
AO Yeah, so our philosophy is, if you were to go and implement authorization inside of your system today, and kind of just to make sure we're on the same page, when we say ‘authorization’ we are talking particularly about, “Can this user do a particular action?” We're not talking about authentication, but the sort of permissions, authorization, access control side of things. And when we look at what I've done myself or the rest of the company has done themselves and kind of what you would generally do out there, 99% of our ‘competition’ is just someone writing that if statement or that case switch statement themselves to work out whether a user could do something or not. And if you're writing software, that's probably where you'd start off. You have your API request handler and you have a user, you've got some sort of authenticated session and you want to work out whether an action should be allowed or not, you'll write a simple if statement and off you go. And so our view is, firstly, how can we make this easier and more scalable, because you're going to have to keep repeating that code, and ‘don't repeat yourself’ is the mantra of trying to work out who can do what across the code base. So we launched Cerbos as an open source and open core solution because we don't want to have any blockers or any sort of things in the way that would stop someone picking a solution off the shelf rather than having to go and build it themselves and reinventing the wheel over and over and over again. I'm a big believer in ‘buy versus build’– though in this case it's open source– because you as a business or you as a startup or you as developers, your value and your time and your focuses really should be on the value add business layer, the core of what your company does, not worrying about how to implement logins or how to implement permissions or how to implement an email sending system. Those things become just another service these days you plug in, and software composition itself is now just about putting the building blocks together, the Lego blocks of decoupled components into a one system, and then you can spend all your time and all your important focus and money on delivering the actual value of your business.
BP So the thing that I've heard that kind of challenges some of the ideas you're suggesting is that you get to this point of microservices and middleware sprawl where it's difficult for you working at a company to understand when something goes wrong, is this an upstream problem, a downstream problem? What component is causing these issues? And then I need to go out and get a fancy service mesh to tie all this stuff together. So talk to me a little bit about how your company works. We could discuss both, a company with a classic monolithic structure, or a new school where everything is built up infrastructure as code. And then how do you deal with those issues, that kind of sprawl that we see in the world of many microservices?
AO Yeah, so I think one of the big reasons why using something like Cerbos or some other kind of decoupled authorization engine makes sense is because it allows you firstly to take all that sprawl of actually business and authorization logic that's going to be spread across your code base, which, say it is microservices, you might have something in Java, you might have something in Go, you might have something in Node because you're a heterogeneous kind of architecture, and pulling it all out into a standalone service that's running still inside your cluster, still inside of your infrastructure, safe and secure inside the firewall. And it actually centralizes all that business logic into one place. So I personally think it's a much cleaner way of doing things because there's now a single point where some of the most important logic inside your application like, “Can this person actually do this action,” is centralized in one place. And by bringing it out and through the tooling we give you with Cerbos, you can actually now start writing proper tests around authorization logic. So even before you go and implement it into your code base, you can actually define and write proper unit tests around your authorization logic that can run standalone and isolated and testable and everything kind of like that. It also simplifies things on the other end. So inside of your code base in each of those languages, in each of those systems where you do authorization checks, the requirement is going to land as a Jira ticket or a GitHub issue or whatever, from most likely a product person, of which I've been that person in the past. And it's going to be written in prose. It's going to be maybe a grid of tick boxes, “This role should do this action,” et cetera. And then you as a developer have to go and actually implement that as an if statement or as a case switch or whatever across the codebase and you end up with this sprawl. By having it as that standalone piece now inside of your codebase, you'll not have to go and re-implement this logic. It may be in different languages in different handlers in different parts of your codebase. It's now a single callout to a Cerbos instance saying, “I have this principle trying to do this action on this resource,” and now regardless of where that check is coming from– front end, back end, some bash job, it doesn't really matter. You're going to get a consistent answer based on a single set of policies, and there's no risk that in one place it might be implemented one way and in another place it might be implemented another way. So my view and our view is that it actually kind of simplifies things by having it as a central service inside of your stack. Now the flip side of that, as you kind of rightly pointed out, is this sprawl of like a million microservices inside my stack, and how do I know I've got requests flying around everywhere, and what's going here, what's going there, and particularly from a data security point of view, what information am I sending where? Our view on this is that we need to be a good citizen in this world. Our previous experience is very much in the cloud native world. We understand what it really takes to run large-scale production systems in things like Kubernetes and those sorts of things. So from day one in some of the very first commits that went into the Cerbos codebase if you go back in the Git history, we're adding things like good Prometheus metrics, very good observability, so OpenTracing telemetry support. So if you are running a stack and you want to have that full kind of end-to-end visibility of every request that's going through, Cerbos naturally just fits in there. It's just a configuration flag to turn it on and it fits nicely into your monitoring stack. And then the other side of things, and which is kind of a side benefit of having a standalone approach or decoupled approach to authorization, is that you're going to get a clean audit trail as well. So regardless of where every check is coming from, you don't have to go and implement your own audit logging or paper trail of who tried to do what. It's all captured by that Cerbos instance that's running inside of your stack. So you get that clean audit log, “At this time this principle tried to do this action on this resource, and it was either allowed or denied.” There’s policy and you kind of get that for free so you can get that traceability.
[music plays]
BP All right, everybody. Today's episode has a very special sponsor: yours truly, Stack Overflow. Now we all know the frustration of searching for answers on internal wikis that have gone stale, or trying to find that one email or chat thread from months ago with the information you need to get unblocked now. Well, there is a better way. Stack Overflow for Teams is a knowledge base that has all the features you already know from stackoverflow.com, but reimagined for your organization so that you and your teammates can collaborate, quickly find solutions, and be more productive. It's like a private Stack Overflow for your organization's internal knowledge and documentation and it's used by companies of all sizes like Microsoft, Expensify, Bloomberg, Dropbox, many more. You can always try it out for free at s.tk/teamspod. Go over there, let them know the podcast sent you, s.tk/teamspod. If 50 teammates won't cut it or you need more advanced knowledge management capabilities, head on over to s.tk/teamsplan and use the promo code ‘teamswin’. You'll get a 30% discount on the basic or business plan for your first year, courtesy of the Stack Overflow Podcast. All right, spiel over. Let's get on with the show.
[music plays]
BP Cassidy, you've worked at a bunch of big tech companies and at startups. What's been your most pleasant experience and are there things about Cerbos you kind of wish you had? I mean, when you hear Alex explaining it, what calls out to you as a working developer?
CW Oh man, it's hard to pick around stuff. I think the thing that I could see Cerbos the most useful for is access to internal tools. When I'm using Okta or Auth0 or Clerk or whatever tools that we might be using internally, we often have to log in and then there's some software and sometimes they don't work perfectly well with the authentication side of things. Or not authentication– authorization. Gosh, these two words.
AO They're far too similar aren’t they? Especially when you start authn, authz. It’s like, “Which one is it?”
CW Yeah, and when you just say ‘auth’ then you're like, “Which one is that?” But seeing that where sometimes we would use softwares where we would say, “It would be really, really useful if this software actually did integrate with FusionAuth or Okta,” or whatever tool that we're using and we would have to wait for a really long time for that company to be able to implement it. And so I could see something like this being so much easier to implement than some company having to write their own logic from scratch, just because auth is not easy and it's unfortunately something that everybody has to build.
BP Alex, this is a selfish question because I'm working on a piece related to this, but I'm just curious. As you look out at what's happening in the industry as you're meeting clients of different sizes, what are you seeing in terms of adoption of the cloud? Is it still mostly big public cloud and people are choosing all the things they can use from that big menu of options? Is it increasingly sort of more like a private cloud or a hybrid cloud that folks are doing? Or in some cases are people even bringing things on-prem? And when you have those three different approaches, how does that impact how you might use a service like Cerbos or go about doing auth? Your kind of auth, not the other auth.
AO Yeah, great question. I would say of the thousand companies we spoke to over the last year or so, the majority are obviously going to be on public cloud. Lots of AWS, a fair amount of Google and Azure as well. But what we're seeing is kind of a willingness to do the extra bit of work to have some level of decoupling from the cloud infrastructure themselves. So using Kubernetes is an obvious one so you're not necessarily tied to a native container service and it gives you some portability. There's some things you just need to use the cloud provider for, low balancers, that sort of thing.
BP Right, but Kubernetes to avoid lock-in, definitely.
AO Exactly. And for some of our users, we have big heavy regulated industries, finance, insurance, those kinds of industries that use Cerbos today, there is some notion of on-prem or controlled deployment. In fact, one of our users actually ships physical hardware around the world and they run Cerbos on it which is a fun challenge when you start to do updates and these sorts of things. But yeah, having that kind of abstraction layer on top of the cloud, generally Kubernetes is in there and that's where we think Cerbos plays very nicely with that. Because at the end of the day, Cerbos runs just as a container or a binary inside of your stack. It can run anywhere. It's not coupled to anything. There's no external dependencies because Cerbos itself is completely stateless. So there's no external service, you don't need to provide a database, you do anything like that. You can run Cerbos in a serverless function if you wanted to if that's your architecture. So again, that was one of our very early principles– how can we play nice when we're going through this world that's kind of evolving in terms of how applications are architected and deployed to make sure it can be as plug and play as possible regardless of whether you're on-prem, in a cloud, on edge. It needs to kind of work everywhere and I think that's generally the trend that's happening, this kind of decoupling of core components of systems. You might plug in a cloud provider offering for one thing. You might run a sidecar for another thing. You might push data out to some API for some third thing, but you're not necessarily deeply tied to one particular platform. And if we look at the world right now where we have all these data protection laws and data locality laws coming in, you need to be able to spin up and control services in different parts of the world and be certain of how those things are and do that very quickly and not take a two-year project to move.
BP Right, right. That makes a lot of sense.
CW I love the stateless decoupled approach to everything, and I think more things should be. It's like the functional programming paradigms and directions of putting things together. And I was actually curious about the stack in which Cerbos is built, because y'all have SDKs for all of the languages like Go and Rust and Python and JavaScript and Java and .NET and Ruby, all of these different things. How is it actually built under the hood?
AO Yeah, so the core of Cerbos, what we call the policy decision point– PDP, is in Go, and that was a decision obviously from our experience, but also it has the nice kind of performance characteristics and memory kind of overhead. And the ability to run and compile anywhere is kind of a big win for us. And the way Cerbos works is you run the Cerbos container and that container pulls in policy definitions. So rather than writing in your native application code language your authorization logic, you define it in Cerbos policies which are in YAML. If you're familiar with Kubernetes manifest, they look extremely similar to that. Good developers copy, great developers paste–
BP Appreciate that plug, appreciate that.
AO –to make something that's very familiar and that's very procedural and you can test and write around it. And then that Cerbos instance, when it starts up it pulls down those policies and then you start using the SDKs or directly with the API, calling it from your application code. So the Cerbos instance itself exposes a GRPC interface. There's an HTTP REST one on top as well. But again, these are all decisions we made for performance because unlike authentication, which you can authenticate, you can get a token that’s valid for 30 minutes so you don't need to go and hit an API again, with authorization it's in the critical path of every request. Every single API call you want to check whether someone can do something or not. Every single request you want to check whether a permission is allowed or not. So all the decisions and everything down to the language we're using, the fact that it's GRPC rather than anything else as native interface, the fact that it's YAML that gets compiled to an in-memory representation which is much faster, these are all those performance decisions. So we have those SDKs which make it much nicer to integrate with the Cerbos GRPC interface. There's also the issue to API if you want to use that as well. And that's kind of how it's architected. We're big fans of Go and we've got some future plans with a managed control plane on top of it that plugs in nicely for that interface as well. Things like protobuffers or defining for absolutely everything inside of the stack going forward so we have a very clean definition of everything that's occurring and you can very easily go and extend it if you want, because at the end of the day it is open source Apache 2.0 licensed.
BP Very cool.
CW That's awesome.
BP I know you had something you wanted to share with us, an announcement you've made recently. What's coming online and what should developers be excited about because of it?
AO Yeah, so we've been completely blown away with the adoption of Cerbos in its form, which really is a developer tool. You have to be happy writing YAML, deploying things, setting up log ingestions, CI pipelines or testing policies, et cetera. And where we're going is we're launching a next offering that sits on top of that which is a managed Cerbos cloud, which is an environment for you to actually define, test, iterate on cyber policies in much more of a developer kind of workflow, but then also unlocks the ability to start bringing other parts of your team and organization on board to use it. Because we know the people that actually hold the requirements of authorization is not a developer; it's generally a product manager or maybe a security team who aren't maybe happy to go and write YAML files and these sort of things, which is fair enough. So we're going to be releasing very soon the Cerbos cloud offering, which is that management control plane and interface for getting more of your team on board. It's a managed CI pipeline. We do a lot of optimizations within it to coordinate rollouts of policy changes across your cluster of resources, things like log audit, log ingestion and these kinds of areas. So there's a lot to come. We'll be announcing more soon. But cerbos.dev/next is the page you can go to and find out more and sign up for updates.
BP Excellent. As the resident marketer on the call, I appreciate what you're doing for all of us, letting us have a little bit more control, even if we don't know how to work on a YAML file. It's very sweet of you.
[music plays]
BP All right, everybody. It is that time of the show. Let's shout out a member of the Stack Overflow community who came on and helped save a little knowledge from the dustbin of history. Awarded December 28th to Hoopje, “How to print in bold on a terminal.” If you're struggling with this, Hoopje has an answer for you and has helped over 115,000 people figure this out. So congrats, Hoopje, on the Lifeboat Badge. I am Ben Popper. I'm the Director of Content here at Stack Overflow. You can always find me on Twitter @BenPopper. Email us with questions or suggestions, podcast@stackoverflow.com. And if you like the show, leave us a rating and a review because it really helps.
CW I'm Cassidy Williams. I'm CTO over at Contenda. You can find me @Cassidoo on most things.
AO And I'm Alex Olivier. I'm a Product Lead at Cerbos. You can find me on Twitter @AlexOlivier. And you can find out more about Cerbos at cerbos.dev.
BP All right, everybody. Thanks for listening and we will talk to you soon.
[outro music plays]