Feb. 5, 2024

#292 Jake Moshenko on the Frontlines of Tech: Building, Scaling, and Innovating with Purpose

#292 Jake Moshenko on the Frontlines of Tech: Building, Scaling, and Innovating with Purpose

Join us as we sit down with Jake Moshenko, the dynamic CEO of AuthZed and co-founder of Quay, and chart his impressive journey from Michigan's engineering halls to the cutting edge of tech entrepreneurship. As we dissect his early career at Boeing and subsequent roles at Amazon and Google, Jake gives us an insider's glimpse into the genesis of his groundbreaking projects. The stories of developing Quay, the pioneering private Docker registry, and its evolution through acquisitions by CoreOS, Red Hat, and IBM, are testament to the power of engineering-driven solutions to real-world problems.

 

In the ever-changing realm of software deployment, Jake brings to light the transformation from manual server management to the marvels of Kubernetes, revealing how such advances have fundamentally altered the global tech landscape. This episode is not just about deployment; it's an in-depth look at the challenges of scalable authorization, particularly through the lens of Jake's latest venture, AuthZed. Listeners will find Jake's insights into balancing security with scalability invaluable, especially those navigating the fintech sector or handling sensitive data.

 

As our conversation ventures into the entrepreneurial spirit that propels innovators like Jake, we discuss the roles of risk tolerance, perseverance, and adaptability in the startup ecosystem. Looking to the horizon, we then probe the potential impact of AI on cloud-native technologies, differentiating between buzzword automation and genuine machine learning advancements. This episode is a treasure trove for anyone curious about the future of tech, the journey of a serial entrepreneur, and the intricate dance of innovation and customer satisfaction that shapes successful ventures.

 

About Jake:

Jake Moshenko has been an innovator in the cloud-native ecosystem for over 15 years. After engineering roles at Amazon and Google, Jake founded Quay, the first private Docker registry, which was acquired by CoreOS. Jake then became an engineering leader at CoreOS, which was acquired by Red Hat (and then IBM). He is now the co-founder and CEO of AuthZed, the company commercializing SpiceDB, the industry-leading cloud-native permissions database.

 

https://www.linkedin.com/in/jacob-moshenko-381161b

https://authzed.com

 

00:46 Introduction and Guest Background

01:19 Jake's Journey from Michigan to Boeing

02:36 Transition into the Tech World: Amazon and Google

03:57 Venturing into Entrepreneurship: DevTable and Quay

04:38 The CoreOS Experience and Acquisition by Red Hat

05:17 From Red Hat to IBM and the Decision to Start Again

08:36 The Birth of AuthZed: Solving Authorization Challenges

12:14 The Role of AI and Future Trends in Cloud Native Ecosystems

20:00 The Journey from Engineer to Leader

25:58 The Art of Building and Scaling High Tech Startups

36:05 The Future of AuthZed and Final Thoughts

Transcript

0:00:02 - Mehmet
Hello and welcome back to any episode of the CTO Show with Mehmet. Today I'm very pleased joining me from the US, jake Moshenko. Jake, thank you very much for being with me on the show today. The way I love it is. I love my guests to introduce themselves and tell us a little bit about their background and what they are doing. So the floor is yours, jake. 

0:00:22 - Jake
Thanks, happy to be here. Hi, my name is Jake Moshenko and I am the CEO and one of the co-founders of a company called AuthZed. Of course, this hasn't been what I've always done. I originally am from a place in the US called Michigan very cold, not so different from how it is here in New York right now and my parents were both business owners and I've always been a builder. So, growing up as a young boy in the state of Michigan, I just always wanted to be a builder. I always thought I'd become an engineer. I ended up studying computer engineering at the University of Michigan and it was there when I really honed my engineering and computer skills. 

And then, straight out of college, my first job was out at Boeing. Boeing has been in the news a lot lately and not for good reasons, but when I was there back in 2005, it was an absolute dream. So at Boeing I got to work on computer flight simulators. So we were creating the engineering flight simulators that Boeing would use to verify and validate new airplane designs before they put them in giant airplanes. It was an incredibly fun job, a total dream. I got to fly these massive six degree of freedom simulators around and get paid for it. 

But ultimately, my background and my propensity for building would take me into the tech world More of the traditional tech world. So, being out in Seattle, that's where a lot of the cloud companies and a lot of the tech companies Dujeur were building their cloud experiences and were building their companies. So from Boeing I went over to Amazon and then Amazon I worked in e-commerce web services so the e-commerce platform that drives Amazoncom and worked on highly scalable web services that would drive the experience, the user experience, with a high focus on scalability and uptime, because anytime Amazoncom is down, amazon was losing money. And from there, after my time at Amazon, I moved over to Google here in New York and at Google, that's when I got into the developer tooling space. So at Google, I worked on the API's infrastructure team, working on a project which was designed to make it a common and portable infrastructure for talking to all of Google's various APIs, and that's where I really got my feet wet in designing APIs and designing things that developers really love. That's also where I met my current CTO and second time co-founder now, joey. So Joey and I left Google to build a company called DevTable. That was a web IDE. The web IDE unfortunately never went anywhere. 

But as part of that journey, we also built a product called Quay, and Quay was the first private Docker registry. Maybe you've heard of it. It was even we were offering private Docker registry hosting before Docker Hub was even a thing. So that's how we started to get into this whole containerization, infrastructure, kubernetes, cloud, native space. It was also my first taste of entrepreneurship and it was actually a quite popular, quite successful product and you can actually go and you can still buy it from IBM today. 

So the Quay journey took us to a company called CoreOS. We sold Quay to CoreOS CoreOS you may have heard of it. It was very popular from around 2013 to 2018 when it was acquired by Red Hat, and the thesis of CoreOS was that we were going to bring Google style infrastructure to everybody else. So, based on Kubernetes and based on these machines that were self updating and always secure, we were going to give everybody else the power that Google has, the way Google develops and deploys apps internally, and that sold to Red Hat in 2018. And then I continued that journey at Red Hat, working on infrastructure software for Red Hat, so helping Red Hat build software that runs software better, which is really just a continuation of the CoreOS journey. And then CoreOS and then Red Hat sold to IBM, and then I found myself going from a two person company to a 400,000 person company. And that's when we said you know what? It's time to do something new again. Let's go off and do outside. 

0:05:03 - Mehmet
What a rich career, Jake, and you know the thing that just came to mind you know being, you know having all this background. So I like to, you know, to ask this question for every founder, every CEO, CTO, I meet on the show here there must be, every time, some trend or challenge that you might have been facing yourself to come up with these products Like, was it always, you know, it's something that you were trying to solve your own problem, or was it like because you did multiple times actually and successfully every time, which is, you know, it's a rare combination. Or was it like something you were hearing from customers or we're hearing from colleagues? So how did you come up with all these ideas? That became something very big. 

0:05:56 - Jake
Yeah, I think when you look at the archetype of the engineer founder, right, the engineer turned founder they're almost always scratching their own itch, and we're no different. So when we built Kwe, it was because we were trying to develop this Web IDE. And part of a Web IDE is having a way to run language analysis engines and run the applications and test the applications. Right, that's part of what makes an integrated development environment integrated, right? Otherwise it's just a text editor. And so when we were, we had this challenge, we were packing all of this proprietary software that we had written and we were packing it into these container images and we had nowhere to put them. And so I turned to Joey, our my co-founder and our CTO at the time, and I said you know, if we're having this problem having a place to store container images with private software in them, I'm sure other people are having the same problem. Let's, you know, let's build and launch a product in that space and see, see what happens, see if other people are having that problem. 

And when we made this decision, we had already booked a Docker meetup appearance. It was, I think you know, every time to tell the story it probably changes, but it was probably about a month out, and so we had a month to completely create and build and launch this product, because the idea was that we would launch it at this Docker meetup. And we did right. We built a product in one month and we launched it, and the response was just like it was a resounding yes, right, like this was clearly a need. I remember our very first ticket that we ever got through our support channel was I'm having trouble paying you, so we had forgotten to switch the stripe keys out from the development keys to the production keys on the front end specifically, and so credit card payments weren't going through. But it was just such a breath of fresh air to have something that the market was pulling for. And there was this need that other people had as well, and the story is no different with AuthZed. So I guess I should quickly introduce AuthZed. So AuthZed sells authorization services to companies, and we're trying to make it so that companies engineers aren't rewriting this brittle hacky authorization code over and over again. So we want to sell you your last authorization system that you'll ever have to work on. This was again a pain that we had been feeling in our day jobs, in our daily lives. So at Quay we built permissions from scratch, like most companies do. We said, all right, well, we'll copy the GitHub permissions model. So we did that. We wrote some code and we stored some relationships in a database and we said, all right, well, we've got the GitHub model now, but we didn't have the full GitHub permissions model. 

Again, the first ticket that came in when we launched was I need organization support. So we had just launched with individual users owning individual repositories. The need for organization support is a really direct, really obvious need. But it caused us to have to go back and do a ton of rework and a ton of rewrite and whenever you're messing with permissions or authorization code, you're always potentially opening a security hole. So it was this big challenge to add organization support, and we finally launched it and the request just kept coming. So it was now I need group support, I need team support within my organization, and now I want teams to be part of other teams so that I can model my company structure, my company's hierarchy, and the request just kept coming and we actually never even fully solved it. So there were requests for features that we weren't able to ship because of the way our authorization and our permissions model were architected so that, I mean, that was a very clear need right there. 

And then again at CoreOS, we were trying to build this Google's infrastructure for everyone else, this platform where you would build and deploy applications, and part of the idea was that you would have an AWS style management console and control plane, but for services that the users brought in themselves. So AWS has S3, as you know, and there are a number of open source alternatives to S3 that you could bring in and install on a Kubernetes-like platform, and so the question became how do we offer this console and IAM experience on services that we don't know, we can't name, we can't enumerate those services, and how do we do that in a scalable, flexible way? So this was twice that we had been bitten by this complicated permissions bug and we said there's got to be a better way. So in 2019, google released the Zanzibar paper and, having experienced this problem so many times in the past, I was very eager to read the paper and about halfway through the paper, I turned to Joey, who is our current CTO and my last co-founder, and I said this is the solution. 

This solves the problem that we've experienced so many times in the past, and here's a blueprint for how to go and build a solution in the space. And so in 2019, I wasn't able to convince him to leave. But then in 2020, we were in the middle of a pandemic and I said this is the perfect time to found a startup. There's no FOMO, right, we're not missing out on anything Like. Let's go do it. And in 2020, I was able to convince Joey and our other co-founder, jimmy, to go and found a company around this very hard problem that we've experienced and, yeah, we've been doing that ever since. 

0:11:30 - Mehmet
You know I really always, as I was telling you, jake I enjoy, you know, like these innovations that come out of you know, trying to solve problems that can and what I don't claim by any mean, I'm a very cloud guru guy but, of course, like I'm aware of the technology but anything that can you know, like make the life, whether you are working on the infrastructure side or from the development perspective, like software, you make the lives easy by making it faster, cheaper or more secure, like it's something always that fascinates me honestly. Now you've been doing, you know or you've been in this cloud native space for quite some time now. So you did it with, you know, with the way and CoroS, and you know you've been sometime also with Red Hat and IBM. So how did you see the cloud native ecosystem evolve and what do you think the role that you know the CoroS has played in this evolution? 

0:12:31 - Jake
Oh boy, yeah, what was the state of the art before CoroS came out? Before we had things like Kubernetes, we had software that would reach out to a server and that would just deploy a piece of software. But that was kind of where. That was kind of where the story ended, right? So it wasn't highly involved in the management of the software and of the evolution the full the software, the full software, the full service lifecycle of that software that was deployed. Think things like Vagrant, right? So Vagrant will talk to a machine and it will say install and run the software and that's kind of where it ends. 

So the evolution has been from really talking about things in terms of like atomic, small deployable units and turning them into globally available services. So being able to react when the app is in a degraded state, react automatically, being able to coordinate deploys of an app across the planet such that they seem like a seamless global service to the end consumer, so really just sort of leveling up the way we think about deploying software. Right, like even before we had things like Ansible to deploy software. We were really dealing with like the state of the art was let's spin up 20 servers and then we would have ops, people manually move releases over to those 20 servers. If you look back at where we are today, we've just come so far. So now we're managing software that runs in dozens of clusters on thousands of nodes, and it's potentially even easier than it was to care and feed for those 20 servers. Does that answer your question? 

0:14:23 - Mehmet
Absolutely, absolutely, jake. Now I want to a little bit focus and before I shift to some other topics, so coming to your current style of that, so if I wanted to do this, imagine I'm your ICP, I'm your ideal customer profile and you want to tell me why I should be doing this. Because maybe for me and again I have like a blend of backgrounds, but let me take the seat of someone who's interested in such solution. I would tell you like, maybe there are like plenty of solutions that can do this permissions and role-based access. So what is the innovation that you bring on the table, jake, with OSZ, and why I should be really interested to know more about your solution. 

0:15:15 - Jake
Yeah, sure. So role-based access control is a model, but it's just the first part of the story. So role-based access control, if you're not familiar, is each person gets a role and then the role grants them rights. So, for example, if you're an admin on a bank account, you can do anything, you can make payments, you can look at the transactions, etc. But if you're a bookkeeper, then you only have read-only access to the bank account. You can't authorize payments, things like that. So this is a model for people to think about how permissions should work from the user's perspective. 

But not all software falls into that model. In fact, it's very rare that things very cleanly fall into that model. If you think about something like Google Docs, each document itself has a set of roles that an individual could have. This is very highly specialized to Google. Being able to model things that exactly represent your specific app is often a challenge when you're trying to use an out-of-the-box canned authorization model like RBAC. So Google, for example, is very share-heavy, role-based, but within the context of a document or a folder or an organization. 

And so once you step out of this box, once you step out of this really simple model, things can really go off the rails and you can start having challenges around. Well, did I absolutely imagine all of the different edge cases and all of the different uses that can crop up when I start stepping off the rails and I start thinking outside of the box? And did I close all the security holes? And once you've got all of that settled, you still have the problem of can this thing scale? Can I, will this thing be with me through the phases of my journey? So that's sort of like the problem statement. 

This code always seems easy at the beginning, but then, as time goes on and as your platform and your application progress and get more rich and become more complicated, this permission code ends up becoming a bottleneck to your velocity, whether it's feature velocity or whether it's your ability to scale or explore new geos, et cetera. And so what OTSED does is OTSED gives you a flexible, scalable way to take out all of that tricky authorization code and replace it with something that's very isolated, testable and scalable and globally distributed by default, so that you've now got an authorization platform that you can lean on to make these complicated decisions for you and to give you peace of mind in terms of having a platform that's going to be with you for the long haul. 

0:18:06 - Mehmet
That's fantastic, jake. 

Even I'm not, as I said, very deep technical in that, but I was able to grasp and understand this and the way you are changing how this permission thing works to make it easy for developers without compromising security at the same time, actually, by strengthening the security also as well. 

And I think, jake, security is on the top of mind of everyone because, especially when you need to do multiple application integrations and you're calling other functions within the application you're building, sometimes you need to go and talk to another even application using APIs. So all the time we need and this is what we've seen and I'm saying this just as an awareness for other founders who might be listening to us, because I know we have a lot of tech founders so don't skip security, and you need to think security first, especially if you are building in the fintech space or you're building something that deals a lot with data and data privacy. So thank you for explaining that, jake. Now, one thing I'm curious also about you started your career as an engineer, right, and then you shifted to a leadership role. So do you think your experiences with some of the tech giants, like Amazon and Google, helped you shape this leadership style and how this affected also the success of Way and CoreOS. 

0:19:47 - Jake
Yeah, that's an interesting question. 

Until CoreOS, I wasn't in a leadership role in any of the tech giants, so what I got exposure to was how those companies did things in terms of performance reviews or hiring or incentives, things like that. 

So I wouldn't say that the tech giants have been super influential in the way I think about leadership. 

What has been super influential in the way that I think about leadership is just my own experience of having had leaders in a variety of different roles and really latching onto the idea of the servant leader, so someone who can help set the direction and who can help shield the team from having to deal with things that they really don't need to be thinking about. And that's kind of where what I look for now, in other leaders as well, is how can I work harder, how can I work smarter to make sure that the team is as efficient and as happy and they're doing the best work that they possibly can, and using that as a framework really makes a lot of the decisions a lot easier. So if that's what you've got in mind when you're designing your incentive structure, if that's what you've got in mind when you're figuring out how your performance reviews are going to work and how you're going to get people excited about their work. It really makes those decisions a lot easier. 

0:21:25 - Mehmet
That's great. You mentioned something also kind of related to this in your introduction. So you mentioned all of a sudden when you find yourself in a big organization and then you decide to go out and start again. I read it in some books also as well, and I find that sometimes it's kind of something that keeps repeating Founders like yourself, jake, that always they like to be maybe in a more agile environment. Is this the feeling that you've got, and do you think this is something now with even your current startup? Do you think if someone comes and, let's say, a choir company, you're going to go back and start again, so you become this kind of serial entrepreneur? Is it something you think it's in the DNA of a founder, or is it just because you are always on the hunt for the next big thing? 

0:22:27 - Jake
Yeah, I think there is a component to it being in the DNA of a founder. I think if you look at every individual's profile in terms of risk tolerance and in terms of thinking that there might be a better way and in terms of the impact that they wanna have on the world, like I think, you will find that there is an archetype for a serial entrepreneur, and I think that's me at this point, and I think I'll just keep doing this as long as I can, because there's nothing more fun in the world to me, but to some people, when you tell them like, hey, you're gonna give up your steady thing, paycheck, and you're gonna go build something and there's a very high probability of failure For some people that you know that it sounds like you know you just ask them to sleep in a bed full of spiders or something right, like that's the worst possible thing that they could imagine. But for me it's very exciting, right, it's like let's, you know, let's put it all on the line, let's see what we can do, let's see how we can change the world, and I don't think that that's something that you can really train or you can really teach. I think it's just something that's inherent in each individual person. 

But a company, of course, is made up of all kinds of different people, right, and you need various archetypes. You need the people who are happy optimizing one very small part of the stack, because those people are often the most impactful when it comes to bottom line, for example. So, right, like Google has people where all they do is they comb through the Lennox kernel and they look for opportunities to shave half a percent of CPU off of what the Lennox kernel is doing, and when you apply that across millions of servers, of course that turns into huge savings. So those people are incredibly important to a functioning organization as well. 

0:24:18 - Mehmet
Absolutely. I agree with you, jake, and I think you know like you're one of the lucky ones, I would say, because I watch a lot of people who give up sometimes, who they don't have whatever it takes, as they say, you know, to keep continuing, doing whatever they do. I'm lucky enough, like now I know, like now I get to know you also as well, so to meet people like yourself who are really inspiring for you know fellow people who can start. You know they are on the verge of doing something, but I'm sure, like now, because you've done this couple of times, there are some kinds of like things. Maybe the first time you started it, I'm sure, like you've learned a lot, and the second time it was much easy. And now you know you have built kind of. 

You know you have some kinds of key learnings, you know on how to start, build scale, you know these high tech, you know startup companies. So, for you, what were like the major key learnings that you can share with us today? So for people, maybe to avoid and maybe to follow, so they cannot, you know, I would say, give up so they can keep themselves in the game. So what are like? A couple of, maybe one or two if you can share key learnings with the audience. 

0:25:44 - Jake
Yeah, sure, one of the things is that it's never gonna be a straight line to success, right? So there will always be bumps along the road and things that don't go to plan and pivots that you have to make. I think the key learning there is that you should have the things that are non-negotiable, right, the things that make your business special, the things that make what you're doing worth starting a company around, and those non-negotiable things should be set in stone and you shouldn't waver on those. But then for sort of the rest of the decisions that you have to make and for the rest of how the company operates, like, you should be very flexible and listen to the market, right. So if your key insight is that you should do ABC in the market, it's like, well, we really want something that does DEF, right. Like if you start just following the market, then that's the old Henry Ford, like faster horses quip, if you've heard that one. 

0:26:43 - Mehmet
Sure yeah. 

0:26:45 - Jake
Yeah. So if you give up on your key insight, then there's really nothing special anymore. But everything else you should be flexible around and you should kind of follow where the market wants to take you and you should listen to your customers, talk to as many customers as possible and when you have a setback, it's not the end of the world, right? So if you can find a way to keep going, Paul Graham has another famous saying, that's there are a hundred ways that startups die, and if you can find a way to avoid all of them, then success is guaranteed, right? So that's an interesting way to think about it. Just find a way to keep going and find a way to keep iterating and keep talking to people and keep learning and keep integrating, keep listening. 

So, yeah, that's, I would say, sort of the big one. 

0:27:33 - Mehmet
Yeah, another thing which also it came to my mind out of curiosity. So for you, your exits were acquisitions like Quay being acquired by CoroS, and CoroS. 

0:27:45 - Jake
It's really just one acquisition chain, right Like four different companies with the same software. 

0:27:53 - Mehmet
That's true. But I mean like this, at least from business perspective, also gave you any kind of insights on, for example, now with OZET, like anything that you start to shape or, let's say, plan the business in a way to go into a certain direction, for example, an acquisition versus I don't know, because at the end of the day, every startup founder, I believe they have some kind of end of mind like where they want to take this company. So usually they either go for getting acquired by a bigger company or they want to go for the IPO route. So did that experience gave you anything special from planning the business? 

0:28:44 - Jake
Yeah, I mean there's certainly tactical things that you can do to make it so that acquisition would be easier. But, like I'm definitely not the archetype, I know there are people out there who build companies in order to flip them right. So they look at a public company and they say what would be on this company's shopping list if it existed, or what other company would they buy if, for example, that company were not already a public company and were available at a tenable price? And they go, when they build companies, into that niche. That's not me and that's not us, right, we're always trying to build something that's has a reasonable plan toward profitability and that can sustain and become a big, massive, enduring company what I will say is that, having gone through various different styles of acquisition so CoreOS acquiring Kuei was a very small deal. 

Red Hat acquiring CoreOS was a medium-sized deal and, of course, ibm acquiring Red Hat, one of the biggest deals in the tech industry of all times they're all very different, right, the things that they focus on, the things that they look at. Sometimes you're being acquired for team. Red Hat getting acquired by IBM was very strategic, right? Ibm thought that there was a hole that they had in their offerings and they thought that Red Hat would be capable of filling them. So I guess this is a really meandering way of saying that, like we're not building a company with an attempt or with the goal of being acquired. Now, the pragmatist in me says that most startups end up either getting acquired or dying right. It's very rare for a startup to go on to IPO so like if that became a part of our journey. I wouldn't consider it a massive failure or anything, but that's not what we're setting out to do. 

0:30:34 - Mehmet
That's great and I love what you might. I can see, jake, you're focused on customer customer, I would say benefits and customer satisfaction more than let's be honest the financial part of it. Of course, everyone would love to have this financial success as well, but I can see you're more focused on the customer satisfaction side of it. And to your points and I think I was reading a couple of articles and I read a book the other day the amount of startups that are going public is less nowadays and even the ones that are going public back in the days during the dotcom bubble, it was like in two years they would go IPO. Even the ones who are very established now are taking like seven years, eight years, even 10 years, sometimes more, until they reach that stage. So things need like more passions also, I would say, nowadays. 

Now I want to go back to the industry trends and you have, like this, extensive experience in cloud native ecosystems. Now I'm seeing a lot of like new technologies coming in that space and majority of them they focus on the automation. Now, of course, with the AI, they're trying to put the AI into that space. So but from your experience, what are like really the trends that people who are interested in cloud native ecosystems. They need to be following very closely and I would not ask you about like long-term, five, seven years. I'm asking about at least in the near future, which is like the coming one, two years from now. 

0:32:18 - Jake
Yeah, that's a great question. I think the trends that I see from talking to our customers that are really that always seemed a little bit maybe specious, but now are actually paying dividends, our edge and like functions as a service. So we actually have a solid number of customers who are building on top of functions and who are building on top of edge platforms. Think things like cloud flare workers, where you're trying to push compute all the way out to the edge. So, from the cloud native ecosystem, I would say those are the ones that I see having impacts today. 

Ai I haven't really seen make a big impact so far in terms of cloud native technologies or like being able to build and deploy software at scale. It could come right. Like I'm a big believer in AI and I'm a big believer in the transformer model that came out of Google that's powering all of our LLMs. I think it's very flexible and at some point in the near future it would be entirely possible for the operators the software operators that we count on to run our services to have some AI components in them, where some of the tokens that are coming out of the LLMs are like you should probably restart this thing or you should scale this thing right, like I think that that could totally happen and I think that would be a really exciting development in the space, right? So there's a gap when we talk about software operators, where there are the cases that we've coded for and then everything else falls through to a human engineer, and I think with AI we could probably attack more of the things that we haven't coded for. 

0:34:03 - Mehmet
I think you would agree with me, jake, like it's more about the automation, because unfortunately the word AI is sometimes misused, because actually they are doing automation but they are just putting this chat box that you type and then it does the thing in the background. 

But to your point, I think, the machine learning, the actual machine learning that can do some predictive analysis. And to your point, maybe A-Node requires a restart or maybe, like an API is about to get the maximum number of requests that it's allowed, then you need to open a case too to increase that, whatever. So I think these are like the kind of things that, through AI or machine learning, would be relevant over there more than just and again, people knows that I cover a lot about AI. I'm personally also very excited about AI, but I don't like to just put the tag on everything and call it AI because they have this kind of chat, but that answers the questions over there. So now, as we are coming almost to the end, what should we expect on the long run for all that and what's your vision for all that, at least again in the coming future? And are you planning any expansions? Are you planning any cool thing that you can share with us today? 

0:35:33 - Jake
Yeah. So Odd said. People hear the name Odd and they think are you gonna get into authentication? I just wanna put it on the record that no, we have no plans to go into authentication. So we're authorization through and through and we plan to just keep expanding and iterating on that journey to give people the best possible authorization platform for their business, and part of that is what we're doing today in terms of permissions checks and things like that. But in the longterm it can also start to include things like powering the IGA tools or the PAM tools that companies are using, or powering the auditing workflows or giving visibility into who has access what, where, when and why who tried to access what was it good or was it bad? So right now we're replacing that core code inside the applications, but later on, once all of the applications are already speaking our language and are using our permissions database, we can start to really give businesses useful insights about the way data is being accessed within their companies. 

0:36:42 - Mehmet
That's again like something very cool. Looking forward to hear about these successes. Jake, final thing usually I ask my guests was there anything that you wished? I have asked you Like this is a space for you, if maybe something I didn't cover and you want to just shortly kind of last words you want to share with us. 

0:37:05 - Jake
Oh man, I should have probably had something prepped for that. Is there anything that you should have asked me? It's not a tricky question, no, no, and it's actually a really good one. I often ask this in interviews, when I'm interviewing somebody right Like what is it? That you forgot to talk about. I don't know. I'm really drawing a blank. You should have asked me how happy I am that my Michigan Wolverines just won the national championship. 

0:37:34 - Mehmet
Okay, sure, here you go. 

0:37:37 - Jake
Yeah, pretty happy. 

0:37:39 - Mehmet
Fantastic, amazing. Yeah. So, again, like the reason I asked this question, I stopped it for a while because I was forgetting. Honestly, I'm very transparent Now. I just remembered in the past few episodes to ask this question again. It's just a space in case, really, if I missed something or maybe there is a message you want to share with us today, jake. But actually you know you covered a lot and thank you very much for being on the show. Personally, my take is both from technical perspective and, I would say, entrepreneurship perspective. So the technology you've developed and with your co-founders, I think it's shaping the way this authorization, not authentication, to your point, it's done so. But, yeah, like, I advise everyone to go and have a look, because this is what I usually ask people whether you can find more about you and your startup. So I think, jake, going to the website is the right thing, right. 

0:38:37 - Jake
Yeah, we're always happy to talk with people about what they're doing for authorization and what they're doing for permissions, whether they think they might be a customer or not, and to that end, we've actually got a website that we've stood up just for shows like this. 

I know everybody's very busy when they're listening to these talks and whatnot. But if you just go to authzedcom so that's our website slash podcast we have a ability for you to reach out and speak directly with me and the other founders about what you're doing with authorization and how what we're doing may or may not be of a help and like honestly, whether you think you might be a customer or not, we're just happy to talk to people in the space or who are doing interesting things in the space. 

0:39:15 - Mehmet
Fantastic. I would make sure that the link is in the show notes so people can reach out to you, jake, and learn more about the work that you are doing. And again, thank you very much for sharing these insights. The other part that I want to thank you is your story is, in my opinion, inspiring for a lot of tech founders, or to be tech founders, maybe even about how you can be persistent and have this will to reach whatever goal you have put in mind, and I think few people in this world have done this, texas, that you've done, jake. Really, I want to congratulate you and I'm happy that we've met and we did this podcast recording today, and this is usually how I end my episode. So, for the folks that are keep coming, thank you for joining and thank you for your messaging. Keep them coming, keep your feedback coming and, if you just discovered this podcast by chance, thank you also for passing by. I hope you enjoyed it. 

I appreciate if you can subscribe, share it with your friends and colleagues and if you are interested to be on the show also as well. You've got this new idea you're developing. You are into a new emerging technology that you're developing with someone, or you have a great integration that you are doing today and you think people can benefit from it. You have a great story you can tell us, whether related to tech or entrepreneurship. Don't hesitate to reach out to me. I would be happy to talk and arrange for recording an episode with you, and thank you very much. We will meet very soon, thank you. 

Transcribed by https://podium.page