 Hello everyone, welcome to this special CUBE conversation here in Palo Alto, California. I'm John Furrier, host of theCUBE in theCUBE Studios. We've got a special video here at Love when we have startups that are launching it's an exclusive video of a hot startup that's launching, got great reviews so far. You know, word on these trees, they got something different and unique. We're going to dig into it. Amit Govran, who's the CEO and co-founder of Kubia, which stands for CUBE in Hebrew and then headquartered in Bay Area and Tel Aviv. Amit, congratulations on the startup launch and thanks for coming in and talk to us in theCUBE. Thank you, John, very, very nice to be here. So first of all, a little, because we'd love theCUBE because theCUBE is kind of an open brand. We've never seen theCUBE in Hebrew. So is that true? theCUBE, Kubia is? Kubia literally means CUBE. You know, clearly there's some additional meanings that we can discuss. Obviously, we're also launching a CUBECon. So there's a dual meaning to this event. CUBECon, not to be confused with CUBECon as an event we might have some day and compete. No, I'm not kidding. Good stuff. I want to get into the startup because I'm intrigued by your story. One, conversational AI has been around, it's been a category. We've seen chatbots be all the rage. And I kind of don't mind chatbots on some sites. I can interact with some form-based knowledge graph, whatever knowledge database and get basic stuff self-served. So you can see that, but it never really scaled or took off. And now with Cloud Native kind of going to the next level, we're starting to see a lot more open source and a lot more automation in what I call AI as code or AI as a service, machine learning, developer-focused action. So I see, to me I think you guys might have an answer there. So if you don't mind, could you take a minute to explain what you guys are doing? What's different about CUBE? What's happening? Certainly, so thank you for that. CUBE is what we would consider the first or one of the first advanced virtual assistants with the domain-specific expertise in DevOps. So we respect all of the DevOps concepts, GitOps, workflow automation, all of those categories you've mentioned, but also the added value of the conversational AI. That's really one of the few elements that we can really bring to a table to extract what we call intent-based operations. And we can get into what that means in a little bit. I'll save that maybe for the next question. Yeah, so the market you're going after is kind of, it's always, I love to hear starters when they don't have a Gartner Magic Quadrant, they can fit nicely and it means they're onto something. What is the market you're going after? Because you're seeing a lot of developers driving a lot of the key successes in DevOps. DevOps has evolved to the point where, and DevSecOps where developers are driving the change. And so having something that's developer-focused is key. Are you guys targeting the developers, IT buyers, cloud architects, who are you looking to serve with this new opportunity? So essentially self-service in the world of DevOps, the end user typically would be a developer, but not only, and obviously the operators. Those are the folks that we're actually looking to help augment a lot of their efforts, a lot of the toil that they're experiencing in a day-to-day. So there are sub-categories within that. We can talk about the different internal developer tools or platforms, shared services platforms, service catalogs, there's 10 gentle categories that this kind of comes on. But on top of that, we're adding the element of conversational AI, which as I mentioned, that's really the got you. Yeah, I think you're starting to see a lot of autonomous stuff going on, autonomous pen testing. There's a company out there doing that, seeing autonomous AI. Automation is a big theme of it. And I got to ask, are you guys on the business side purely in the cloud? Are you born in the cloud? Is it a cloud service? What's the product choice there? It's a service, right? Software is a service. We have the classic multi-tenancy SaaS, but we also have a hybrid SaaS solution, which allows our customers to run workflows using remote runners that's essentially hosted at their own location. So primary cloud, but you're agnostic on how they want to consume the product. Technology agnostic. Okay, got it. Okay, so that's cool. So let's get into the problem you're solving. So take me through, this will drive a lot of it value because when you guys did the company, what problems you hone in on, and what are you guys seeing as the core problem that you solve? So we, this is a unique, I don't know how unique, but this is an interesting proposition because I come from the business side, so call it the top down. I've been in enterprise sales. I've been in a CRO VP sales hat. My co-founder comes from the bottom up, right? He ran DevOps teams and SRE teams in his previous company. That's actually what he did. So we met each other halfway essentially with me seeing a lot of these problems of self-service not being so self-service after all. He had platforms hitting walls with adoption and he actually created his own self-service platform within his last company to address his own personal pains. So we essentially kind of met with both perspectives. So you're absolutely hardcore on self-service. We're enabling self-service. Yeah, and that's basically what everybody wants. I mean, the developers want self-service. I mean, that's kind of like, you know, so take us through what you guys are offering. Give us an example of use cases and who's buying your product, why? And take us through that whole piece. Do you mind if I take a step back and say why we believe self-service has somewhat failed or not gotten off? Yeah, absolutely. So look, this is essentially how we're looking at it. All the analysts in the industry inside are talking about self-service platforms as being what's gonna remove the dependency of the operator in the loop the entire time, right? Because the operator, that's scarce resource. It's hard to hire, hard to train, hard to retain those folks. Developers are obviously dependent on them for productivity. So the operators in this case could be a DevOps, could be a SecOps, it could be a platform engineer. It would come in different flavors. But the common denominator, somebody needs an access request, provisioning a new environment. You name it, right? They go to somebody, that person's operator. The operator typically has a few things on their plate. It's not just attending and babysitting platforms, but it's also innovating, spinning up, and scaling services. So they see this typically as kind of, we don't really wanna be here. We're gonna go and do this because we're on call. We have to take it on a chin if you may. That's their job, they gotta do it. Right, but it's KTLOs, right? Keep the lights on, this is maintenance of a platform. It's not what they're born and bred to do, which is innovate, and that's essentially what we're seeing. We're seeing that a lot of these platforms, once they finally hit the point of maturity, they're rolled out to the team, people come to serve themselves in a platform, and lo and behold, it's not as self-serve as it may seem. Yeah, we've seen that, certainly with Kubernetes adoption being, I won't say slow, it's been fast, but it's been good, but I think this is kind of the promise of what SRE was supposed to be. Do it once and then babysit in the sense of it's working and automated, nothing's broken yet, don't call me unless you need something, I see that. So the question, you're trying to make it easier then. You're trying to free up the talent. Talent to operate and have essentially human-like in the loop, essentially augment that person and give the end users the need, all of the answers they require, as if they're talking about a person. Yeah, I mean, it's basically, you're taking the virtual assistant constable chatbot to a level of expertise where there's intelligence, jargon, experience into the workflows. That's known, not just talking to chatbot, get a support number to rebook a hotel room. We're converting operational workflows into conversations. Give me an example, take me through an example. Sure, let's take a simple example. I mean, not everyone provisions EC2s in today's environment, but let's say you want to go and provision new EC2 incidents, okay? If you wanted to do it, you could go and talk to the assistant and say, I want to spin up a new server. If it was a human in loop, they would ask you the following questions. What type of environment, okay? What are we attributing this to? What type of instance, okay? Security groups, machine images, you name it. So these are the questions that typically somebody needs to be armed with before they can go and provision themselves, serve themselves, okay? Now the problem is, users don't always have these questions. So imagine the following scenario. Somebody comes in, they're in a giro ticket queue, they finally their turn is up and the next question they don't have the answer to. So now they have to go and tap on a friend or they have to go essentially and get that answer. By the time they get back, they lost their turn in queue. And then that happens again. So they lose the context, they lose essentially the momentum and a simple access request or a simple provisioning request can easily, easily become a couple days of ping-pong back and forth, okay? This won't happen with the virtual assistant. I think, and you mentioned chatbots, but also RPA is out there, you've seen a lot of that growth. One of the hard things and you brought this up, I want to get your reaction to is contextualizing the workflow. It might not be apparent, but the answer might be there, but it disrupts the entire experience at that point. RPA and chatbots don't have that contextualization. Is that what you guys do differently? Is that the unique flavor here? Is that the difference between current chatbots and RPA? The way we see it, I alluded to the intent-based operations. Let me give a tangible experience, even not from our own world, this will be easy. It's a bi-directional feedback loop because that's actually what feeds the context and the intent, okay? We all know ways, right? In the world of navigations. They didn't bring navigation systems to the world. What they did is they took the concept of navigation systems that are typically satellite guided and said, it's not just enough to drive down the 280, which typically has no traffic, right? And to come across traffic and say, oh, why didn't my satellite pick that up? So they said, have the end users, the end nodes, feed that direction back, that feedback, right? There has to be a bi-directional feedback loop that the end nodes help educate the system, make the system better, more customized. And that's essentially what we're allowing, the end users. So the maintenance of the system isn't entirely in the hands of the operators, right? Because that's the part that they dread. The maintenance of the system is democratized across all the users, that they can teach a system, give input to the system, hone in the system in order to make it more of the DNA of the organization. You and I were talking before we came on this camera interview, you said playfully that the Siri for DevOps, which kind of implies, hey, infrastructure, do something for me. Like, we all know Siri, so we get that. So that kind of illustrates where the direction is. Explain why you say that, what does that mean? Is that like a North Star vision that you guys are approaching? You want to have a state where everything's automated and there's conversational deployments, that kind of thing. And take us through why that Siri for DevOps is, I think it helps anchor people to what a virtual assistant is because when you hear virtual assistant, that can mean any one of various connotations. So the Siri is actually a conversational, right, assistant, but it's not necessarily a virtual assistant. So what we're saying is we're taking anchoring people to that thought and saying we're actually allowing it to be operational, turning complex operations into simple conversations. Yeah, I mean, basically they take the automate with voice, a Google search or a query, what's the score of the game. And it also, in talking to the guy who invented Siri, actually, whenever you're on theCUBE, it's a learning system. It actually learns. As it gets more usage, it learns. How do you guys see that evolving in DevOps? There's a lot of jargon in DevOps, a lot of configurations, a lot of different use cases, a lot of new technologies. What's the secret sauce behind what you guys do? Is it the conversational AIs, machine learning, is it the data, is it the model? Take us through the secret sauce. In fact, it's all of the above. And I don't think we're bringing any one element to the table that hasn't been explored before, hasn't been done. It's a recipe, right? You give two people the same ingredients. They can have complete different results in terms of what they come out with. We, because of our domain expertise in DevOps, because of our familiarity with developer workflows with operators, we know how to give a very well-suited recipe, right? Five course meal, hopefully with Michelin stars as part of that. So a few things, maybe a few of the secret sauce elements, conversational AI, the ability to essentially go and extract the intent of the user so that if we're missing context, the system is smart enough to go and to get that feedback and to essentially feed itself into that model, okay? Someone might say, you know, conversational AI, that was yesterday's trend. It never happened. It was kind of weak. Chatbots were lame. What's different now, and with you guys and the market that makes a redo or a second shot at this, a second bite at the apple, as they say, what do you guys see? Because I would argue that it's still early, real early. Certainly. How do you guys view that? How would you handle that objection? It's a fair question. I wasn't around the first time around to tell you what didn't work. I'm not afraid to share that. The feedback that we're getting is phenomenal. People understand that we're actually customizing the workflows, the intent-based operations to really help hone in on the dark spots, like the way we call it, last mile bottlenecks. And that's really where we're helping. In a way, tribalized internal knowledge that typically hasn't been documented, because it's painful enough to where people care about it, but not painful enough to where you're gonna go and sit down the entire day and document it. And that's essentially what the virtual assistant can do. It can go and get into those crevices and help document and operationalize all of those toil into workflows. Yeah, I mean, some will call grunt work or low-level work. And I think the automation is interesting. And I think we're seeing this in a lot of these high-scale situations where the talented, hard-to-hire person is hired to do, say, things that we're hard to do, but now harder things are coming around the corner. So serverless is great and all this is good, but it doesn't make the complexity go away. As these inflection points continue to drive more scale, the complexity kind of grows, but at the same time, so does the ability to abstract away the complexity. So you start to see the smart, higher guns move to higher, bigger problems. And the automation seems to take the low-level kind of like capabilities or the toil or the grunt work or the low-level tasks that you don't want a high salary person doing. Or I mean, it's not so much that they don't want to do it. They'll take one for the team, as you said, or take it on the chin, but there's other things to work on. I want to add one more thing because this goes into essentially what you just said. Think about it's not the virtual assistant what it gives you is not just the intent. And that's one element of it, is the ability to carry your operations with you to the place where you're not breaking your workflows. You're actually comfortable operating. So the virtual assistant lives inside of a command line interface. It lives inside of chat like Slack and Teams and Mattermost and so forth. It also lives within a low-code editor. So we're not forcing anyone to use uncomfortable language or operations if they're not comfortable with it. It's almost like Siri. It travels in your mobile phone, it's on your laptop, it's with you everywhere. That's right. It makes total sense. And the reason why I like this and I want to get your reaction on this because we've done a lot of interviews with DevOps with these women of every KubeCon since it started. And Kubernetes kind of highlights the value of the containers at the orchestration level. But what's really going on is the DevOps developers in the CI CD pipeline. They're with infrastructure as code, they're basically have a infrastructure configuration at their disposal all the time. And all the ops challenges have been around that the repetitive mundane tasks that most people do is like six or seven main use cases in DevOps. So the guardrails need just need to be set. So it sounds like you guys are going down the road and saying, hey, here's the use cases. You can bounce around these use cases all day long and just keep doing your jobs because they're bolting on infrastructure to every application. There's one more element to this that we haven't really touched on. It's not just workflows and use cases, but it's also knowledge, right? Tribal knowledge. We can, like you asked me for an example, you can type or talk to the assistant and ask how much am I spending on AWS on US East One and so on. So customer environment last week and it will know how to give you that information. Can I ask, can I buy a reserve instances or not? Can I ask that question? Because there's always good trade-offs between buying the reserve instances. I mean, that's kind of the thing that... This is where our ecosystem actually comes in handy because we're not necessarily going to go down every single domain and try to be an expert in here. We can tap into the partnerships API. We have full extensibility and API and the software development kit that goes into... It's interesting, opinionated and declarative or buzzwords and developer language. So you start to get into this editorial thing so I can bring up an example. Hey, Cube, implement the best service mesh. Okay, what answer does it give you? Because there's different choices, you know? Maybe you go... Well, this is actually where the operator, if there's clearly guardrails, okay? Like you can go and say, I want to spin up a machine and we'll give you all of the machines on AWS. It doesn't mean you have to get the X1 larger. That's good for a SAP environment, right? You could go and have guardrails in place where only the ones that are relevant to your team, ones that have resources and budgetary guidelines can be. So the operator still has all the control. I was kind of tongue-in-cheek around the editorialized but actually the answer seems to be, as you're saying, whatever the customer decided their service mesh is. So the thing, this is where it gets into as an assistant to architecting and operating. That seems to be the real value. Now, Code Snippets is a different store because that goes on to the web, that goes on to stock overflowing and that's actually one of the things. So inside the CLI, you could actually go and after Code Snippets and we could actually go and populate that, it's a smart CLI. So that's actually one of the things that are an added value of that. You know, I was saying to a friend, we were talking about open source and how I grew up, there was no open source. Now, if you're a developer now, I mean, there's so much code, it's not so much coding anymore as it is connecting and integrating and writing glue layers, if you will. I mean, there's still code, but it's not, you don't have to build it from scratch. There's so much code out there. This low code notion of smart, a smart system is interesting because it's very matrix like it can build its own code. Yes, but I'm also a little wary with low code and no code. I think part of the problem is we're so constantly focused on categories and categorizing ourselves and different categories take on a life of their own. So low code and no code is not necessarily even, even though we have the low code editor, we're not necessarily considering ourselves low code. This is a serverless, no code, low code. I was always thrown on term of the day, architectureless as a joke. No, we don't need architecture. There's a case around that by the way. We do. Show me my AWS architecture and it will build the architecture diagram for you. Again, serverless architect, this is all part of infrastructure's code. At the end of the day, the developer has infrastructure with code and how they deploy it is the nerve on. That's what we've been striving for. Sure. But infrastructure is code. You can destroy terraform. You can go and create one. It's not necessarily going to operate it for you, right? That's kind of where this comes in on top of that. So it's really complimentary to infrastructure. All right, so final question before we get into the origination story. Data and security are two hot areas. We're seeing fill the IT gap that has moved into the developer role. IT is essentially provisioned by developers now, but the ops side shifted to large scale, SRE like environments, security and data are critical. What's your opinion on those two things? I agree. Do you want me to give you the normal data as gravity? So you agree that IT now is kind of moved into the developer realm, but the new IT is data ops and security ops, basically. 100% and the lines are so blurred. Like who's what in today's world? I mean, I can tell you have customers who call themselves five different roles in the same day. So it's, you know, at the end of the day, I call them operators because I don't want to offend anybody because that's just the way it is. Architech's your list, we're going to go back to that. Well, I know we're going to see you at KubeCon. Yes. We should catch up there and talk more. I'm looking forward to seeing how you guys get the feedback from the marketplace. It should be interesting to hear. The curious question I have for you is, what was the origination story? Why did you guys come together? Was it a shared problem? Was it a big market opportunity? Was it an IT you guys were scratching? Did you feel like you needed to come together and start this company? What was the real vision behind the origination? Take a minute to explain the story. No, absolutely. So I've been living in Palo Alto for the last couple of years. Previous also a founder. So, you know, from my perspective, I always saw myself getting back in the game. Spent a few years in AWS, essentially managing partnerships with tier one DevOps partners. You know, all of the known players, some in public, some of them not, and really the itch was there, right? I saw what everyone's doing. I started seeing consistency in the paints that I was hearing back in terms of what hasn't been solved. So I already had an opinion where I wanted to go. And when I was visiting actually Israel with the family, I was introduced by a mutual friend to Shiked, Shiked Eskayo, my co-founder of CTO, amazing guy, unbelievable technologist, probably one of the most impressive folks I've had a chance to work with. And he actually solved a very similar problem, you know, in his own way in a previous company, Bluevine, where Fintech company, where he was head of SRE, having to essentially oversee 200 developers in a very small team. The ratio was incongruent to what that SRE guideline would tell. As more than 10X rate developer. Oh, absolutely. And sure enough, and just imagine this, four different time zones, right? He finished his day shift and he already had the U.S. team coming, asking for a question. He said, this is kind of a- He got a clone himself, basically. Well, yes, he essentially said to me, I had no day, I had no life, but I had corona. I had COVID, which meant I could work from home. And I essentially programmed myself in the form of a bot. Essentially, when people came to me, I said, don't talk to me, talk to a bot. Now, that was a different generation. It was a different country. Yeah, just a trivial example, but the idea was to automate the same queries all the time. There's an answer for that. Go here, and that's the benefit of it. Yes, so he was able to see how easy it was to solve, I mean, how effective it was, solving 70% of the toil in his organization, scaling his team, frozen headcount and the developer team kept on going. So that meant that he was doing some right. When you have a problem, you need to solve it. The creativity comes out of the woodwork, you know, invention of the mother of necessity. So final question for you, what's next? Got the launch. What do you guys hope to do over the next six months to a year? Hiring, put a plug-in for the company. What are you guys looking to do? Take a minute to share the future vision and get a plug-in. 100%, so Kubia, as you can imagine, announcing ourselves at KubeCon, so in a couple of weeks, opening the gates towards the public beta and NGA in the next couple of months, essentially working with dozens of customers, Aston Martins and business, and we have quite a few, our website's full of quotes, you can go ahead, but effectively, we're looking to go on to bring the next operator, generation of operators who value their time, who value the, essentially, the value of tribal knowledge that travels between organizations that can be, essentially, shared. How many customers do you guys have in your pre-launch stable? It's above a dozen, without saying, because we're actually looking to onboard 10 more next week, so that's just an understanding. It changes from day to day, but. What's the number one thing people are saying about you? You got that right, okay? I know it's, I'm trying to be a little bit more, you know. It's okay, you can be cocky, startups are good, so, you know, but I mean they're, obviously they're using the product and you're getting good feedback. Is it saving time? It saves us, this is a dream product, got it right. What are some of the things? I think anybody who doesn't feel the pain won't know, but the folks are in the trenches, we're feeling the pain, we're experiencing this toil. Who know what this means? They said, you're doing this different, you're doing this right, you architected it right, you know exactly what the developer workflows, you know, where all the areas, you know, where all the skeletons are hidden within that, and you're attending to that, so we're happy about that. Everybody wants to clone themselves. Again, the tribal knowledge, I think this is a great example of where we see the world going, make things autonomous, operationally automated, use cases you know are lock solid, why wouldn't you just deploy? Exactly, and we have a very generous free tier, people can, you know, there's a plugin, you can sign up for free until the end of the year, we have a generous free tier, yeah, free forever tier as well, so we're looking for people to try us out and to give us feedback. I think the self-service, I think the point is, we've talked about on theCUBE at our events, everyone says the same thing, every developer wants self-service, period, they'll stop, done. What they don't say is, they need somebody to help them babysit, to make sure they're doing it, you're right. The old dashboard, green, yellow, red. You know, I know it's an analogy that's not related, but have you been to Whole Food? Have you gone through their self-service line? That's the beauty of it, right? Having someone in a loop helping you out throughout the time, you don't get confused, if someone's not working, someone's helping you out, that's what people want, they want a human in a loop or a human-like in a loop. We're giving that next best thing. Yeah, it's really the ratio, it's a scaling, it's a force multiplier for sure. I mean, thanks for coming on, congratulations. Thank you so much. We'll see you at KubeCon, thanks for coming in, sharing the story at theCUBE. Kubiakon. Kubiakon. Kubiakon. At theCUBE. Kube in Hebrew, Kubeya. Kubeya. Here, founder, co-founder and CEO here, sharing the story in the launch, conversational AI for DevOps, the series of DevOps, really kind of changing the game, bringing efficiency, solving a lot of the pain points of large-scale infrastructure. This is theCUBE, Kube Conversation, I'm John Furrier, thanks for watching.