 Welcome back, everyone, to theCUBE's live coverage, day three of open-source summer, winding down three days of wall-to-wall coverage. I'm John Furrier, host of theCUBE, Rob Stretch A, analyzing all the data here with me. We're breaking it down, we're bringing all our best guests on, Emory, Aaron, co-founder, and CEO of Servos, hot startup, authorization, fine-grained privileges. We're going to get into it. Welcome to theCUBE. Thank you very much. Great to see you at a great dinner the other night with other entrepreneurs out there. You guys feeling good about the event? Yeah, very well, very good. I mean, it's a great community, open-source software, and there are a lot of other companies that have open-source core, and then they build businesses on top of it. A lot of change happened, cloud scale, distributed computing, big driver, AI coming in like a tornado, as we've been saying. A lot of conditions ripe for innovation, and one of the things we've been tracking theCUBE is super cloud, we call it. This idea of multi-cloud, multi-environment cloud operations, big part of it. Take a minute to explain what your company does. We cover some Amazon news, I want to get into that around Cedar. Yes. You guys have some product that's similar but not the same. Indeed. Take a minute to explain to the company what you guys do, what's your product vision. Sure. At Servos, we provide an authorization layer for software applications to be able to implement roles and permissions. What we see often is a lot of, pretty much every B2B application, and even if you have a massive B2C operation, you have a back office that actually behaves like a B2B that needs to implement roles and permissions for multiple people to work together in order to complete a workflow. And often, right after you handle authentication and directory, who's this user, what departments they belong to, what roles they have, all these software need to implement what permissions does this user have, what can they do and what can't they do. And traditionally, software engineers actually built that authorization layer and for companies that don't have their own dedicated software engineering teams, maintaining that is a problem. It always takes a second seat compared to many other features. And at Servos, we provide that as an authorization layer, as a microservice that you can run in your environments. All you have to do is define your policy and rules and it gives you a very flexible API that you can use from anywhere on your stack to be able to ask a question, can this principle do this action on this resource? And it tells you yes or no, you implement that, you move on with your life and everything else. I love this trend as the perimeter got killed with cloud, you now have everything's kind of distributed, acts as if you have the security and all these controls. Open source is a big driver. What's your relationship with the open source? How you guys make money? What's the commercial relationship? Explain the dynamic there, because it's super important. We believe, so one of the main reasons why we open source our product is security is at the core of every software. And as a security layer, authorization layer, you need to take Servos and implement at the heart of your network. We want to make sure that it's secure, that it's transparent to developers who want to implement it. Another main reason why Servos is open source, because we want to make sure that every developer who has a tendency to say, oh, I can build that, shouldn't. And security is one of those things like crypto. Nobody should be writing their own algorithms. We believe security should live up to those standards as well. And we want to make sure that developers feel very comfortable looking at the code, understanding what it is, and therefore not be tempted into writing their own authorization. And how do you guys make money? Real quick, what's the business model? So the business model is for developers who actually have the tendency, oh, I can do that, I can run that. We give an open core library that's Apache 2 license that they can implement and move on with their life. And we very recently announced Servos Cloud, which is a control plane for that binary or for the Kubernetes process that they're running in their environment to be able to manage that. So if you need to handle DevOps to be able to handle distribution of policies, that's part of our premium offering. But if developer wants to do it themselves, they can do that. Similarly, if you want to listen to your product manager and convert those requirements into a YAML policy, developer wants to do that, it's free. If you want a WYSIWYG interface for your product manager to get off your back as a developer and let them do, get on with their roles, that's premium. And similarly, we have an offering for the security teams and CSOS to be able to handle and interact with logs. So pretty straightforward open source model. Yeah, and it seems like it makes it easier for somebody, because you provide the control plane to then go and scale their applications as well. Absolutely. I would assume that it's part of that also making sure, I mean, because security and all of that, looking at it from a platform engineering perspective and making sure that it's part of the SBOM and it's part of all of that. Well, with the premium solution, we make scaling and operations of its sampler. So if the moment the role gets out of a developer and becomes a DevOps, we want to provide all the tooling. So a regular developer shouldn't actually deal with it and we can actually provide all of that. We very much so focus on developer experience because what we see is a lot of shift left, right? Developers now need to handle the security and authorization and various other things. We want to make their lives easier, but by providing these tools, ultimately they need to actually now manage an additional system and we want to actually take that away from them and do that in our cloud hosted control plane. You know, we covered this week on the first day, Amazon had news, they open sourcing Cedar, which is, they say, fine grain permissions. It's their thing. Is that similar to what you guys do? Is that just Amazon? What's the difference? How do you guys compare to say that? It's similar in fact that so Cedar, what Amazon open source is a Cedar language, the policy language and being able to write policy and convert that. But then whatever that policy is, it needs to actually run on what's called a PDP, policy decision point, that actually needs to make these decisions and interact with your software. So Serbos is very similar. We have a very simple language, similar to Cedar, but we actually even tried to make it simpler to developers by making it a YAML configuration and not a programming language. So in that regard, we are similar, but different. And when it comes to running the decision point, Amazon actually runs it in their own environment where Serbos is a binary that you can run in your own environment, whether that's on Amazon Cloud, Google Cloud, or on-prem, or even- So multi-environment. Multi-environment as well as air-gapped, right? You can actually run it in air-gapped environments. We have customers running Serbos on physical ATM machines. We have some government clients running it in airtight environments. And why do they do that? For ransomware protection, with backup recovery? That's actually their setup, right? That's the setup of their environment. It's not because they're running Serbos, they're running in such an environment. It's part of their environment, and that's what prerequisite that we needed to play in. Awesome. Well, so Amazon runs only in their cloud, basically? Yes. So you're set up for multi-cloud? Eventually, potentially, they will open that up as an API call, but there's something else in authorization. Unlike authentication, authorization needs to be very fast. Authentication, when you log in, press the button, you can afford to wait 100 milliseconds to just log in. Once you're logged in, you're in... Even a second is fine. Even a second is fine. But when it comes to authorization, it needs to be super fast. Authorization is behind every interaction with a website, with a product, behind every API, it's in the blocking path. So therefore, it needs to be super fast. And by co-locating with the code and where this logic runs, Serbos provides that. Amazon can afford to do that within their environment. They have low latency within their network, but the moment your application is multi-cloud, now you need to actually make that request across the network, which is going to start slowing you down. And that's what people are realizing multi-cloud's hardest is latency. Absolutely. And what about actual microservices themselves doing the authentication? Is that part of what Serbos does as well so that I can have them have their role in their policy? Or is it really around people? So Serbos does not handle authentication or the user directory. So all of the Serbos is stateless on its own. So Serbos only interprets your policies and by looking at the incoming request, can this user do this action on this resource? It evaluates and gives you a yes, no answer. So in fact, one of the very early things that we focused on Serbos is integration with our ecosystem. We integrate with every authentication provider. We have examples of how it integrates and within that also the directories are part of it. Any authentication provider, any directory provider, Serbos consumes data from that and makes that decision in a stateless manner and returns an answer. Talk about the role of ecosystems because you guys are a very valuable piece. You mentioned Amazon, you can work with them, multi-cloud, you have to have multiple partners, environments. Talk about the ecosystem, how you guys fit in the variety, you mentioned octa earlier. Do you have to play with everybody? How does that work? How do you deal with other opportunities? We need to be compatible with everybody. So when we look at a security layer of an application, the critical components are authentication, which is are you who you say you are? Can you log in? Are you credentials valid? Once you're logged in, it's the directory. Who are you? What are your roles? What departments do you belong to? What geographies do you belong to? Once you know those two pieces of information, then comes authorization, which is, are you allowed to do that action? Are you allowed to see those records? Are you allowed to edit, make that payment, edit a record? And then a fourth one of that is the logs, ultimately SCIM, it's like all the actions of who tried to do what, whether they were allowed or not, and why, why were they rejected, why they were allowed. So that is the ecosystem that we're playing in and all of that, of course, plugs into the rest of your application. And you've got to handle all the languages, SDKs, deployment methodologies, authors, authentication, these are all the key areas you've got to thread through. Indeed. So as you put it, the top thing is the SDKs. We need to make sure, so Serbos exposes an API, but not many of the developers are willing to write plugins for how to do GRPC calls to us to be very fast. So we actually have now SDKs in every major language. So to a developer, it looks just like a regular function call. They can get away with it. After that, we actually have examples or any integrations with every major framework because we are in the process of educating developers that authorization got solved. Do not start, do not. Yeah. We got you covered. We got you covered. And if you're operating with these major frameworks, here is the best practice of how to integrate, how to actually use authorization. Then, as you mentioned, comes the deployment. Every, although everybody runs on the cloud, everybody's on a different stack, different architecture. How do you actually run Serbos in each one of those architectures? And lastly, as we just mentioned, the integration with the authentication providers. Yeah, and I would expect that, again, open source is one, as we've been talking about in proprietary is going, but there still is, especially in where you have to do your integrations, there are still some proprietary type systems that for the actual authentication portions and things of that nature. Do you find that those folks are embracing Serbos? And from the, do we try to decouple this as much as possible? The, our very original message was authorization not decoupled, how do you decouple authorization so that it's out of your business logic and it operates on its own. Because it is, you know, the other thing part of the decoupling, when we looked at this landscape of who decoupled certain processes very successfully, when you actually historically look, Stripe has been a great one, right? It comes, Twilio is another one, right? They took a very complex process, 75 calls and trying to figure out what it is into a very simple API call. So when we were building Serbos, we looked at the world as like, what is that simple API call for us? How can we simplify all of these decisions? And that was the Kennis principle, do this action on this resource. That is the API call that you get to do. And as part of that, we build all the API SDKs so that no matter where you are in your application stack, you can make that call and you get a very simple answer back, allow or deny. So you guys do the heavy lifting on the integration side to make it easier for that- By simplifying the API. You do the back end heavy lifting, give that simple interface function call to the framework SDK, deployment, allegation. And what we give back is that very simple decision. So as the developers implement that decision, if business logic changes, you don't have to change your code, you just change your policy. It's a very simple idea, but hard to execute. What's the secret sauce for you guys, speed? So let me go through the principles that we always, when we were first designing servers, what were the principles we looked at? Number one is security. We are in a security space. This needs to work as expected. Right after that comes two very key requirements. One is speed. The other one is reliability. Security layer is not like your A-B testing layer. If it's not working, you can default to something, right? It needs to- If it's not working, someone's going to get fired. So it's just- It needs, if it gives yes to every answer to everything, that's as good as your doors open. And if it says deny to everything, because it's not working, you're as good as your application is shot. And then the second one right there is speed. As we mentioned earlier, it's behind a blocking path of every API call. It needs to be super fast, super responsive. Right after that, the other next two design principles were extensibility and scalability. We want to make sure that if your application is suddenly running 10,000 pods, we don't become our bottleneck. That's why we design servers in a very stateless manner. It runs super efficiently and effectively with a minimum footprint. And the extensibility is the core requirement where a developer says, I can do that. They write the if-then-else statement. They're done. But every business actually grows. Every business has to handle these additional users. And that's where the extensibility of servers comes, how you can define and design new roles and very easily deploy them. And underlying every single one of them is developer experience. Because if a developer says, oh, that's too hard, all of the work that we've done doesn't matter because they're not adopting it. And authorization as we see it is not something that a CTO can actually enforce on top of developers. Developers actually will go and find the best tool. And we wanted to make sure that it's a pleasant environment to work in. It makes it really helpful for the developers. Indeed. Well, this fits right into our super cloud narrative because we have our event coming up on January, July 18th where we're seeing companies wanting to do more cross environment. And that's where they're putting all their creative energy. You guys provide a simple way to allow them to do that and not worry about authorization. It's a uniform authorization that works across everyone. It's centralized but distributed. And the danger is if someone does the one off and doesn't complete it, maybe it's open to vulnerabilities. A lot of risk. It's a lot of risk. And the design that we've chosen, a lot of companies run. A lot of apps too. Microservices, right? And those microservices are all in different languages. So now imagine your requirements changing and somebody having to take that and translate it in every single language and make sure nothing gets lost in translation. And then once those requirements are coded and it's also a deployment nightmare to make sure you actually coordinate each one of those. And if you've got an API, you can have a set of services that you can go to. Competitor goes out of business or changes their spec. Exactly. You can go to another provider. You can just replace it. And that's why service is Apache 2 license as well. So the very first objection that we always heard, like, what if you go away out of business? I'm like, here you go. The code is yours. No escrow, none of those B2B enterprise hustles. It sounds basic, but it's really great architecture from a cloud standpoint. It's all in line with API first, decoupling, highly cohesive elements. And distributed. Distributed, yeah. So you fit all those key attributes. Exactly. Which is going to be the next 10, 20 years of computer architecture, all right? Let's hope so. Well, thanks for coming on. I really appreciate it. Great to see you there tonight at dinner. Congratulations on your success. Thank you very much. How many people in the company are you guys in terms of funding? What's the status? As you mentioned before we came on camera, you're a virtual first company. Take a minute to explain what you guys do, what you're looking for, and why people should work with you. So we announced our fundraising and launch of our service cloud product about a couple of weeks ago. We've raised recently $7.5 million from All Merse Ventures. Here we are in Canada. So that's a great moment to announce that. And we are in the process of releasing our cloud, service cloud premium service, which is the control plane on top of our environment to make life easier for non-technical users as well as developers helping them with DevOps. We have, we've been remote from day one. This was a COVID company. We started a company in March 21. And in about a week and a half time, we're going to be, for the first time, full company coming together. We have employees from New Zealand covering every time zone pretty much going west. What's your vision? What's your key milestones you want to achieve over the next 12 to 24 months? What's your goal? Do another round of financing or be cashflow positive? What's the key goals? We are right now, we have great traction with our open source product. We have hundreds of companies using it in production. This includes like public companies, FTSE 250 companies, major crypto companies for their trading platform. So our product market fit is getting there. But of course we want to actually improve that over time. And our next major milestone is success with our cloud hosted control plane, which is our premium offering. We're going to be focusing on- Is that shipping now or is that in beta? It's in private beta right now in two weeks. It's going to be actually on open beta. And we're going to spend the rest of the year refining that for developers before we go on to additional users. Servers cloud control plane, sounds like a sustainable differentiated position. Grow the company, congratulations by the way. Great goals, be secure, be fast, decouple, make it easier for developers. Indeed. Great stuff. Thanks for coming on theCUBE. Thank you very much. Okay, day three coverage of theCUBE here, breaking it down. Robert Trecce and I just have a great time with a great view here and beautiful Vancouver. Got a great office. We'll be right back with more day three coverage as we wind down our coverage of open source summit. We'll be right back.