The Cloud Gambit

Founder Stories and Building Context-Aware Access Control with Emre Baran

William Collins Episode 27

Send us a text

Emre Baran is the CEO and Co-Founder of Cerbos: an authorization management solution helping software companies implement and scale fine-grained access controls. Emre is an entrepreneur and a software expert with over twenty years of experience building and scaling B2B and B2C products. In this discussion, we start with Emre's experience Co-Founding and operating Yonja, Turkey's largest social network in the mid 2000s and work our way to the present, as we dig into how Cerbos gives developers a scalable experience for access control that just works.

Where to find Emre
LinkedIn: https://www.linkedin.com/in/emrebaran/
Twitter: https://x.com/emre

Show Links
Cerbos raises $7.5 million: https://techcrunch.com/2023/04/12/cerbos-takes-its-open-source-access-control-software-to-the-cloud/
Cerbos Hub goes GA: https://www.cerbos.dev/news/cerbos-hub-is-now-generally-available

Follow, Like, and Subscribe!
Podcast: https://www.thecloudgambit.com/
YouTube: https://www.youtube.com/@TheCloudGambit
LinkedIn: https://www.linkedin.com/company/thecloudgambit
Twitter: https://twitter.com/TheCloudGambit
TikTok: https://www.tiktok.com/@thecloudgambit

Intro:

Emre Baran is the CEO and co-founder of Serbos, an authorization management solution helping software companies implement and scale fine-grained access controls. In this discussion, we start with Emre's experience co-founding and operating Turkey's largest social network in the mid-2000s and work our way to the present as we dig into how Serbos gives developers a scalable experience for access control that just works.

William:

Emery. Welcome to the show. How are things going today?

Emre:

It's going really well. Thank you very much. Thank you for asking. How are you?

William:

I'm doing well, uh, as we just uh sort of talked about. I woke up this morning and my, my eight-year-old was making pancakes, so I got to sit down to a nice hearty breakfast, um on a on a tuesday.

Emre:

So yeah, good going good um, I hope it wasn't too much of a cleanup afterwards. Making is the easy part, cleaning up Just like code Writing the first piece of code is the easy, making it clean is the hard part.

William:

Yeah, exactly Operationalizing things. The day two is always the challenge, it seems, with everything. Servos is based in the UK, but you don't live in the UK, do you?

Emre:

I recently moved away from the UK, but we are a completely remote company. We have employees from New Zealand all the way to Seattle, around the world, the long way around the globe, I guess not through the Pacific. So we are fully remote and fully asynchronous.

William:

Awesome, good deal. Yeah, I love to hear that. I'm in a similar situation where we have a headquarters in San Jose but the rest of the company happens to be remote. So, yeah, it's awesome, I love it remote. So, yeah, it's awesome, I love it.

Emre:

Um, so you, um, I think, as far as your start with your tech journey, um, you know how did that kind of start, how did you get into technology and you know sort of land in this space of really building some awesome startups yeah, yeah, I was classically, I guess, initially trained in economics and I found myself doing a summer internship, two summers in a row, in an investment bank, and I found myself actually automating my job by writing Excel macros, learning how to write Excel macros, how to do a couple of things in Excel macros, learning how to write Excel macros, how to do a couple of things in Excel record, take a look at the VBA code, figure out what it was doing and then reverse engineer from there to whatever else I needed to do. Back then, internet was very limited in terms of code and availability of things, availability of things. So, and then, after my second year at school, I decided to also study computer science and ever since I've been working in software and throughout my career in so many different companies and so many different environments, I actually found myself writing the authorization code, authorization logic in the code, and it's always just enough authorization to get by by the requirements, but never good enough to be future proof and scalable. And after we conclude with my last company, you know I was looking for challenges to address and this is actually one of those things that stood out. Where you know, in one of the companies we had to rewrite our authorization logic and authorization layer three times just by the pure virtue of the requirements at the time and us not having to spend too much time on software infrastructure and very much so focusing on customer features. And that moment, you know when I was looking for all those challenges, you know, authorization stuck out.

Emre:

This is one piece of code that you can spend months or years writing and perfecting, but it's never the core thing for your software core, you know, value driver. Yet it's a very important one and where, no, you know, no software developer wants to spend too much time on it, but everybody wants to have a very scalable and extensible version of it. So we decided with my co-founders, we decided to very much so focus on providing that as a software infrastructure so that no software developer in the future has to go through that pain of having to build their authorization layer.

William:

Yeah, and it's definitely painful Everything to do with identity and access management and really keeping things secure. You know it's not an easy task. It's not an easy task. You actually have a pretty awesome pedigree of building, you know, sort of a track record of successful startups and not just launching successful startups. But I think getting the timing right, which is sometimes, is equally important. It's the right thing at the right time, and I don't know if I ever will talk to anyone ever again that has successfully launched both a social network and an awesome authorization software platform. But can you talk about your experience originally with launching Yanja? Was it Correct? Correct?

Emre:

So it's. Of course there's a little bit of a luck involved in this and you know having to come across something and recognizing its potential. But you know that's one thing, recognizing the potential, and then it's another thing, the world also seeing the way that you see everything. So Yonja was back in 2003, and these were the early days of Friendster and MySpace, where not many people knew.

Emre:

But, to all full credit to my brother, he actually saw its exponential growth, exponential growth potential, and said this is going to be huge. The world probably needs more than one of these. And let go build a friendster for Europe and I was living in the US at the time. He was living in the US we actually built and launched it with our bunch of our friends in Turkey as our initial group of people, and little did we know at the time it was about. You know, social networks actually grow around the initial group of people you launch them with. But the timing was right, in a sense, that the internet was becoming more and more popular. Everybody was doing emails and online presence, etc. What was also becoming popular at the time was uploading photos to the internet, uploading being able to take photos with your digital camera and uploading them, which had an immense um, immense effect on social networks growth, because at the time when we were looking at the volume of traffic, about 48 or 46 percent of all of our traffic was people going and browsing their friends', friends' photos, right, so that kind of led the growth of Yonja. That turned into people finding their old, lost friends, high school friends or finding people who they kind of knew, but they didn't, and one of the things that we provided at the time was being able to show you the graph. How are you related to this person? Who do you know in common? You know the six degrees of kevin bacon, in effect, and how. And then that turned into a great driver for people dating as well, because nobody wanted to date a complete stranger and everything else. And then we built a business model on top of whatever crossed the line from social network into dating, made those features into premium, and that ultimately led to the success of Yonja, which became the most trafficked website in Turkey. It captured about 30-40% of youth in Turkey and then eventually, we exited that to the leading ISP within Turkey.

Emre:

So then, you know, I went to Google. I worked at Google for a while, and one other trend that we saw at Google was two things we saw at Google. One was the growth of e-commerce, adwords and analytics and people wanting to be able to understand their traffic and then be able to actually deliver personalization to that, because one of the trends that we've seen in AdWords was people were spending more and more money for clicks bringing traffic onto their site, bringing traffic onto their site. But eventually all of that plateaued and suddenly the conversion rate started plateauing because all the landing pages, all the e-commerce pages, were pretty generic that people came. There was zero application of who you are and why you're there or how many times you've been there before, and then, based on that, giving you a personalized experience.

Emre:

I always looked at this as a similar thing as, like a good, smart website should be like a very good shopkeeper, right, and who knows how many times you've been there before. Which aisles did you look at? What are you on the brink of buying? What have you purchased before? What are you most likely to buy based on all that experience? And we were trying to digitize that. And that basically coincided with the big data explosion and at the time hadoop was made open source, basically on top of the google's map reduce white paper. Hadoop made a lot of these calculations easier. Javascript was actually also on the up, so we were able to actually build a business at Qubit where we were collecting clickstream data and we were able to store and process all of that data to make sense out of it. And that was again a good timing with the market, where available technology was possible to adapt to a commercial product that people were wanting, and very similarly with Servos.

Emre:

You know, authorization or externalized authorization is not a new concept. Back in 2004 or so, oracle had a product like this, but it was Oracle. It required you arm and a leg and you're first born to sign off, to be able to get a contract or to be able to try their product. It was slow, relatively slow, it was all Java, et cetera. And then one thing that we see is, you know, when we look at software's history, there's always been decoupling of core components out to vendors or to additional things where, you know, people building software don't have to build that entire infrastructure. They can take it off the shelf, implement it and, very much so, focus on their business layer. We've seen this with databases. We've seen this in security. We've seen this with communication protocols and communication messaging tools. We've seen this with payment tools. Each one of those core things have been decoupled. But when we looked at authorization, that decoupling hasn't been that well. There are two reasons One was performance of this and the second one was it's very hard to find a nice line between authorization and business logic, and at Cerbos we did that well.

Emre:

We basically decided we started with. What would the authorization API look like If we were to just purely implement authorization by the API? What is that? And we came up with our check API which says can this principal do this action to this resource? And the answer is allow or deny If a developer actually implements that API. Which says can this principal do this action to this resource? And the answer is allow or deny. If a developer actually implements that API, then all of the rule sets can be offloaded to those people who drive the business requirements. And that coincided with Kubernetes uptake, so that actually enabled us to be able to very efficiently build this engine and be able to actually deliver in customers' own environment.

Emre:

So Servos, contrary to common popular choices right now, servos is not a software as a service that runs on the cloud that you can actually access. Software is a binary that we can deliver in so many different ways to run in your own environment, but it runs very efficiently. It runs in your environment, it's very fast and it's very secure and scalable, in a sense that as your traffic goes up, it automatically scales up and down. And that basically became. You know we're riding the wave of what authentication was able to do because prior to authentication nobody was thinking about how can you know doing the identity verification on the internet? Authentication thanks to JWT tokens, et cetera, popularized that. So we are now taking a bite at the next step of the security chain, after authentication, being able to do authorization and as an external entity to your software application. Sorry for the long-winded thing, but it's ultimately three careers that actually linked to each other.

William:

Yeah, that's really interesting. So yeah, I mean I remember back to the social media thing. Like I remember that was definitely the right timing. So I remember when I first started doing anything on the internet, it was kind of like blogging at first, and then this whole thing happened like you were talking about oh, you can update a picture or upload a picture, and then you can have friends. And I remember like in my mind at the time I was like, wow, this is the greatest thing ever, this is amazing. So, going past that, so you went to Google straight from yonja yes, is that right?

Emre:

yes, okay, I went to business school in between while I was working on yonja. But, yes, okay.

William:

And then qubit, which, so the way that you described it is kind of like a kind of like understanding, influencing and driving customer demand sort of product in a sense for e-commerce, yes, for customer service.

Emre:

So it's ultimately personalized experience on your e-commerce site, right, understanding who's there and why. And working with the merchandisers, working with the marketing teams, delivering them either, whatever agenda, what the retailer is trying to push, or the best customer service a user can have, based on their prior interactions or based on their current demands current needs Understood and then from there.

William:

So Qubit exited the market right. Yes, got acquired, and then from there, you went on and founded, or co-founded Surboss in 2020?

Emre:

2021, march 2021. In the middle of COVID, which kind of led us to be fully remote and asynchronous, because we had no other choice. We couldn't have an office at the time.

William:

Yeah, and I want to key in on something you were sort of talking about with sort of the developer experience, if you will, but the, I guess the point being like you can go out and have a team build a thing, build all these different things, or you can strategically make the decision to buy certain products for developers so they can focus more on building the differentiated product features that drive the value that make the organization money. Is that sort of correct as it pertains to Servos?

Emre:

Exactly. I mean we see Servos as part of the software infrastructure that you need to have in place in order to be able to write your first line of code that actually differentiates your product, that actually makes your product your product. So you know, authentication doesn't make your product any different how you have people log in, unless you invent a whole new novel way of authenticating your database. You know potential, unless you're into very high volume trading or very specialized AI or data retrieval databases, a database messaging frameworks, payment processing. These are all necessities that you need to have in place to get things done. But the software we're all building or software you're building or any SaaS application is building is about solving a business problem, and part of that is that that's mainly the business logic of how do you handle that business problem and everything else is just an auxiliary thing to enable those things Understood and so kind of not to get too off topic, I guess, but some really awesome projects out there are.

William:

Open source, obviously, and I think Servos is licensed under Apache 2.0. You know, but I guess open source at its core is open source. But then building a business on top of it, you know, and having sort of a paid service, you know, atop the open source, you know that makes things even easier. Why is this such a successful strategy in your opinion?

Emre:

It's.

Emre:

I believe it's very it's you know, part of the PLG strategy, right, product-led growth, plg strategy, right, product-led growth. And what is really product-led growth is? Product-led growth is enabling people to be able to use a product or a free version of the product to just get a sense of what it actually achieves, what it actually can help with. And once the user gets a sense of it and what it can do, then everything else becomes an upsell. And open source has many other benefits. Let's not just focus on the PLG thing.

Emre:

Open source gives, number one, a sense of two different senses of security to people who are adopting it. First sense of security it gives is this product is yours to own. If the company behind it goes away, if you find any bugs that nobody else is fixing it, you're kind of in control of being able to fix that. And then the second part is a little bit more specific to CERBOS' case, where security is paramount. And nowadays CERBOS is part of your security infrastructure. The infrastructure and by architecture, servos is probably running at the heart of your network. Way past all the fireworks, way past all the validation things, you want to make sure whatever binary or black box you're running in there, it's not actually a black box and it's actually not doing anything that it shouldn't be doing. So open source also gives people an ability to be able to inspect that and have a peace of mind.

William:

Awesome.

Emre:

So that drives the open source portion of the business and then usually businesses have built additional features on top of this. When you cross the chasm from a developer need or from a simple company need into enterprise need, there are a bunch of other use cases start coming into it. It's like all the corporate requirements start coming into play and many businesses who build on commercial open source solutions usually tend to build all of those features as a premium solution and many organizations are happy to pay for it because it actually solves their you know, corporate or enterprise complexity.

William:

Awesome, yeah, great. So that's an awesome, awesome sort of response. And you know, that sort of brings me to do you, I guess I mean you probably hear tons of feedback from you know, technologists that have adopted servos, you know, and that I know that, at least when you know the startup I work for, like whenever I hear good feedback, it like motivates me, it like fills that gas tank up and I'm just like plowing ahead with new ideas and new things. But do you, um, ever hear anything in particular from your, your customer base, you, as far as like positive feedback that motivates you and helps encourage and you know adapt and you know mature the product?

Emre:

So there are two camps of feedback. One of them is very positive and it's great to hear very motivational positive and it's great to hear very motivational. Unfortunately, it doesn't help us much with further product development and that feedback is hey, we don't have to look at it anymore, we don't have to touch it, it just works great. We essentially focus somewhere else. I mean, it is the best thing to hear when people give me like nothing to say it works, it's supposed it does whatever it's supposed to do. It scales up, it's like it does everything that's on the tin and thank you. So that's obviously a very good. As you put it, the fills the gas tank up and gives us motivation to keep doing. And you know we only wish more people can actually hear that.

Emre:

But I guess the downside of that feedback is it's it's not um, it's not so explicit in terms of how it does it and what it does. And then we also hear a lot of uh, you know specific feedback on how it actually helped businesses save time, how the you know they have actually, whether they've done, they've tried to do, something like servos in their prior uh businesses or in the current one, and how long it took them and how you know servos is freeing up that time so the developers can actually focus on other things. Recently we published a case study with a bank where they had their own internal layer of authorization that they've replaced with Servos and Servos runs so efficiently. Compared to that, they're saving about a quarter of a million dollars per year in just computing costs. So these are all great pieces of feedback that we hear and we're always looking to spread the word on awesome.

William:

So I mean the way that it you know, one of the, I think, with the outcropping of newer startups, especially even the startup that I work for today sort of gives you a single way for an area of technology, a single way to do that across maybe the clouds, across on-premises, across all the the important areas to to the corporation that's buying the product. Um, and I would say that, like you know, while we do have like direct competitors, like in the space, like I think our biggest competitor at this point is like cloud native and the idea that you can just build it yourself, do you see sort of cloud native as a big competitor for CERBOS?

Emre:

Yes and no. So number one. Let's just go back to CERBOS and its premise, right? Cerbos provides you an authorization service and in order to run the authorization service as fast and as efficient as possible, it needs to run as close to your code as possible, with zero network time, because our true competitor is a developer writing a library or a function to actually do these checks. So we try to make servos as competitive as possible to that in terms of processing times, in terms of simplicity and its SDKs. But we also reckon so, at the end of the day, cerbos is a developer tool and developers choose where their software is going to run. So we, and as a developer tool, we need to be omnipresent, no matter where their code is.

Emre:

So we've actually architected CERBOS in a way that it can run as a binary in a bare metal machine, as a library, as a Kubernetes service sorry, as a binary Kubernetes service as a sidecar in Kubernetes we made Servos. Servos' architecture has some opinionated design where Servos is actually stateless. So we actually have a lot of customers running Servos on AWS Lambdas where they can actually spin up an instance in and out. So in our vocabulary, cloud native is number one, being able to deploy in any of these environments, no matter where they run, whether they run on a cloud provider or whether it's running on an on-premise. But the version of CERBOS, that's not cloud native, it's not cloud as software, as a service, right? It's not running as a service in cloud where you can actually access that from anywhere, from anywhere in the world where CERBOS is running. And that is by design, because authorization, unlike authentication, needs to be super fast.

Emre:

When you're authenticating with a piece of software, when you are logging in, whether logging in takes 100 milliseconds or 500 milliseconds, nobody really notices that thing spinning a couple of more times, because once you're logged in, you're logged in. That token is cached, and once that token is cached, you can validate it anywhere and your identity is never changing. You are who you are and very rarely your roles might be changing if somebody is updating in real time. However, with authorization, every request is pretty much unique. There's a very high cardinality and there's almost zero room for caching things, right? So we want to make sure. We wanted to make sure that, because every request is unique, serbos doesn't hold any cache and and Servos needs to be actually giving you an answer immediately Every API call you have every interaction with your product, every click, every data rendering, anything needs to go through this authorization layer and that needs to be super fast. If the authorization layer is, for each one of these checks, taking, you know, 50 milliseconds, suddenly your entire rendering, your end customer experience, is impacted. It's almost akin to your every database query, adding in 10 milliseconds to every database query.

Emre:

So that's why we do not run servos in the cloud, which is a slight I wouldn't call it a problem, but it's a slight obstacle for very early stage startups who are not used to running any infrastructure and they need actually a service running in the cloud. But what we find is usually those tend to be hobbyist projects. The moment anything like that starts getting serious, there's actually an infrastructure that comes into play and Servos can actually run in those environments. The other thing we call cloud-native. From a cloud-native perspective, servos was born on the cloud native age. So what does that mean? We actually integrated in all the tooling that comes with cloud-native, whether it's tracing, whether it's telemetry. All of those fine tools and technologies are part of Servos from day zero.

William:

Gotcha, gotcha. Okay. So by the time this episode launches, I guess you will have made Surboss Hub generally available from beta. So first of all, congratulations, that's great. Thank you, and so do you want to talk a little bit about that? First of all, what is Surboss Hub versus the open source core component for Servos?

Emre:

Yes. So, if we are going with industry terms, servos open source is. Servos PDP is a policy decision point. This is the module you access with the information Can this user do this action to this resource or can the service? Can the subject do this action to this resource? And it tells you allow or deny. Service PDP is what interprets the policies, what consumes the policies and interprets the incoming requests and gives you a decision, and that's our open source product that's generally available.

Emre:

We are on, I believe, 37, 38 iteration of releasing that and it's pretty stable and that works great for developers who are willing to take that and implement it and manage it themselves, so they can actually. We give all the usual tooling for that. We give a playground online IDE where you can write policies into it. You can write policies and test them, simulate different scenarios. We give a unit testing framework that you can actually use to validate your policies before updating them so that you don't end up shooting yourself in the foot with an incorrect update, and that's available to developers. Take it Apache 2, freely available Go.

Emre:

Once we released Servos ADP open source. One of the things that we've seen is you know what are the additional things that large enterprises or larger companies need when they're using Servos. And we actually identified a couple of pain points that every company was going through. And that's what built Servos Hub. And Servos Hub is what it is it's a policy administration point. It's not a cloud hosted of Servos, it's a control plane for all your Servos instances. So now, rather than running each one of your service instances yourself and implementing a full, it runs all of your unit tests in the background, lets you know if you're stepping in the wrong direction right away, so you don't have to build, deploy, test and then have a much longer cycle. It connects to all of your instances, it monitors them, it has statuses of each one of them, monitors them, it has statuses of each one of them, it in real time streams all of your new policies to the instances all at the same time.

Emre:

So one of the problems with the open source because it's a pull model and you can actually define, let's say, 10 seconds or one minute as a refresh interval for a policy update. Each one of those open source ones are capable of checking for updates and updating themselves hot updating themselves. But if your refresh interval is one minute and if you're running more than one instance. Now you have about a minute of discrepancy potential among all your instances. So Service Hub turns that into a push model.

Emre:

When every instance is connected, it can take your policies, run CI on them, make sure they actually compile and pass all the tests and, when they do, in real time, synchronize all of your instances at the same time. And additionally it does two more things. One is it builds a web assembly version of your policy. So now you can actually deploy Serbos PDPs what we call them as embedded PDPs in environments where you cannot run a binary, ie a web browser, ie a Vercel Netlify kind of environment where you can make the checks again using the same SDK, but you don't have to do a full round trip to a binary that's running somewhere.

Emre:

And the other feature is actually, as we are releasing CERBOS into GA, we're now also releasing CERBOS logs into beta. And CERBOS logs are collecting all of the log data from all your instances and be able to actually expose them to security teams. Because, because service is behind every decision, it means service logs actually contain information about who tried to do when, whether they were allowed or not and why, which policy actually enabled them to do, which is a very valuable piece of information for security teams. And now imagine all of your stack whether it's back-end, front-end, mobile application, batch processing actually has these logs in a uniformed way and now you can actually access them. So with Servos Hub release going to GA, we're actually also releasing serverless logs into beta but it almost sounds like it's the second persona would be that of your security engineer.

William:

that's really like when you have to go back and you have to figure out what happened. It takes so long in certain circumstances because, just yeah, it's just a pain to know exactly what you just said, who did what when they did it, with what account, like all these different things. So having a usable, a consistent way of you know, garnering that information and doing something with it, that's huge. That's a big, a big win right there.

Emre:

Yes, absolutely. And you know there are two parts of that story. One is writing the new requirements and distributing them, so that again makes security engineers' life easier. So now your roles, the role definitions and the actions that map to roles can be deployed independent of the application. And then the backside of that story is now who did what, whether they were allowed or not. And there are actually many other use cases. After we released logs into beta that we were working on to make the security use cases better, which make policy composition and security implementation easier and faster.

William:

Awesome. Well, yeah, best of luck with the launch. Yeah, and just it's amazing. You know you launched this during COVID. The launch yeah, and just it's amazing. You know you launched this during COVID, which is a huge you know, seeing where you are now and knowing what the climate was like during COVID, obviously for startups it wasn't easy for you know anybody, obviously. But yeah good luck with the launch. Looking forward to it. And yeah, where can? So where can folks find you on the internet if they want to connect?

Emre:

So I am on Twitter. I still call it Twitter, not X, yet, although I believe the domain name already switched over to xcom. My Twitter handle is Emre and on LinkedIn I'm Emre Baran. I'm sure the listeners can find these in the show notes, and Serbos is serbos Rebaran. I'm sure the listeners can find these in the show notes, and CERBOS is CERBOSdev Awesome and I love the website, by the way.

William:

So there's many, many bad websites out there and the CERBOS website's very well. It's clean, the colors just finding things. It's very apparent exactly what you need to know and not much more. So, yeah, kudos on a good website.

Emre:

Thank you very much. We still think there's a lot more we can improve, but it's been always designed with developers in mind first, because they are the ones who actually take this product and implement. Without developers, I don't think we'd be anywhere. Product and implement Without developers I don't think we'd be anywhere. And us, coming from a development background, our mission number one is to make life easier for them and, in turn, they can make life easier for the rest of the people in their organizations.

People on this episode