>>from San Francisco. It's the Cube covering. Get lab commit 2020 Brought to you by get lab. >>Welcome back. I'm Stew Minutemen, and this is get lab Commit 2020 here in San Francisco. Happy to welcome to the program. First time guests and TN Who is the co founder and CEO of Matter Most in. Nice to meet you. >>Thanks. Thanks for having me. >>Alright. S O. I always love. When you get the founders, we go back to a little bit of the why. And just from our little bit of conversation, there is a connection with get lab. You have relationships, Syd, Who's the co founder and CEO of get lab? So bring us back and tell us a little bit about that. >>Yeah, thanks. So I'm you know, I'm ex Microsoft. So I came from collaboration for many years there. And then, you know what I did after Microsoft's I started my own started a sort of video game company was backed by Y Combinator and, you know, we had were doing 85. Game engine is very, very fun on. We ran the entire company off of a messaging product. Misses, You know, a little while ago and it happens that messing product got bought by a big company and that got kind neglected. It started crashing and lose data. We were super unhappy. We tried to export and they wouldn't let us export. We had 26 gigs of all information. And when we stop paying our subscription, they would pay one less for our own information. So, you know, very unhappy. And we're like, holy cats. Like what? I'm gonna d'oh! And rather than go to another platform, we actually realized about 10 million hours of people running messaging and video games. Well, why don't we kind of build this ourselves? So we kind of build a little prototype, started using ourselves internally and because, you know, Sid was this a 2015 and said was out of my Combinator, We were y commoner would invent and we started talking. I was showing him what we built and sits like. You should open source that. And he had this really compelling reason. He's like, Well, if you open source it and people like it, you can always close source it again because it's a prototype. But if you open source, it and no one cares. You should stop doing what you do. And he was great. Kind of send me like this email with all the things you need to dio to run open source business. And it was just wonderful. And it just it is a start taking off. We started getting these wonderful, amazing enterprise customers that really saw what mattered most was at the very beginning, which was You know, some people call us open source slack, but what it really is, it's a collaborates, a collaboration platform for real Time Dev ops and it release. For people who are regulated, it's gonna offer flexibility and on Prem deployment and a lot of security and customization. So that's kind of we started and get lab is we kind of started Farley. We started following get labs footsteps and you'll find today with get lab is we're we're bundled with the omnibus. So all you have to do is put what your own would you like matter most on one. Get lab reconfigure and europe running. >>Yeah, I love that. That story would love you to tease out a little bit when you hear you know, open source. You know, communications and secure might not be things that people would necessarily all put together. So help us understand a little bit the underlying architecture. This isn't just, you know, isn't messaging it, Z how is it different from things that people would be familiar with? >>Yeah, that's a great question. So how do you get more secure with open source products? And the one thing look at, I'll just give you one example. Is mobility right? So, in mobile today, if you're pushing them, if you're setting a push notification to an Iowa, sir. An android device, It has a route through, like Google or Android. Right? And whatever app that you're using to send those notifications they're going to see you're going to see your notifications. They have to, right? So you just get encryption all that stuff in order to send to Google and Andrew, you have to send it on encrypted. And you know these applications are not there, not yours. They're owned by another organization. So how do you make that private how to make it secure? So with open source communication, you get the source code. It's an extreme case like we have you know, perhaps you can views, and it's really simple in turnkey. But in the if you want to go in the full privacy, most security you have the full source code. APS. You have the full source code to the system, including what pushes the messages to your APS, and you can compiling with your own certificates. And you can set up a system where you actually have complete privacy and no third party can actually get your information. And why enterprises in many cases want that extreme privacy is because when you're doing incident response and you have information about a vulnerability or breach that could really upset many, many critical systems. If that information leaked out, you really can't. Many people don't want ever to touch 1/3 party. So that's one example of how open source lets you have that privacy and security, because you because you control everything >>all right, what we threw a little bit the speeds and feeds. How many employees do you have? How many did you share? How many customers you have, where you are with funding? >>So where we are funding is, you know, last year we announced a 20 million Siri's A and A 50 million Siri's be who went from about 40 folks the beginning the aired about 100 a t end of the year. We got over 1000 people that contribute to matter most, and what you'll find is what you'll find is every sort of get lab on the bus installations. Gonna have a matter most is gonna have the ability to sort of turn on matter most so very broad reach. It's sort of like one step away. There's lots of customers. You can see it. Get lab commit that are running matter. Most get lab together, so customers are going to include Hey, there's the I T K and Agriculture that's got six times faster deployments running. Get lab in Madame's together, you've got world line. It's got 3000 people in the system, so you've got a lot of so we're growing really quickly. And there's a lot of opportunity working with Get lab to bring get lab into mobile into sort of real times. Dev up scenarios. >>Definitely One of the themes we hear the at the show is that get labs really enabling the remote workforce, especially when you talk about the developers. It sounds like that's very much in line with what matters most is doing. >>Absolutely. Madam Mrs Moat. First, I don't actually know. We're probably in 20 plus countries, and it's it's a remote team. So we use use matter most to collaborate, and we use videoconferencing and issue tracking across a bunch of different systems. And, yeah, it's just it's remote. First, it's how it's how we work. It's very natural. >>Yeah, it just give us a little bit of the inside. How do you make sure, as a CEO that you, you know, have the culture and getting everyone on the same page when many of them, you know, you're not seeing them regularly? Some of them you've probably never met in person, so >>that's a great question. So how do you sort of maintain that culture 11? The concert that get lips pioneered is a continent boring solutions, and it's something that we've taken on as well. What's the most boring solution to preserve culture and to scale? And it's really do what get labs doing right? So get love's hand, looked up. Get lab dot com. We've got handbook that matter most dot com. It's really writing down all the things that how we operate, what our culture is and what are values are so that every person that onboard is gonna get the same experience, right? And then what happens is people think that if you're building, you're gonna have stronger culture because, you know, sort of like, you know, absorbing things. What actually happens is it's this little broken telephone and starts echoing out, and it's opposed to going one source of truth. It's everyone's interpretation. We have a handbook and you're forced to write things down. It's a very unnatural act, and when you force people to write things down, then you get that consistency and every we can go to a source of truth and say, like, This is the way we operate. >>2019 was an interesting year for open source. There were certain companies that were changing their models as toe how they do things. You started it open source to be able to get, you know, direct feedback. But how do you position and talk to people about you know, the role of open source on still being ableto have a business around that >>so open source is, I think there's a generation of open source cos there's three ways you can really make money from open source, right? You can host software, you can provide support, and service is where you can do licensing, which is an open core model. When you see his categories of companies like allowed, you see categories like elastic like Hash corporate Terra Form involved with Get Lab that have chosen the open core model. And this is really becoming sort of a standard on what we do is we fall that standard, and we know that it supports public companies and supports companies with hyper growth like get Lab. So it's a very it's becoming a model that I'm actually quite familiar to the market, and what we see is this this sort of generation, this sort of movement of okay, there was operating systems Windows Circle. Now there's now there's more servers running Lennix than Windows Server. On Azure, you seen virtual ization technology. You've seen databases all sort of go the open source way and we see that it's a natural progression of collaboration. So it's really like we believe collaboration will go the open source way we believe leading the way to do that is through open core because you can generate a sustainable, scalable business that's going to give enterprises the confidence to invest in the right platform. >>All right, in what's on deck for matter most in 2020. >>It's really we would definitely want to work with. Get lab a lot more. We really want to go from this concept of concurrent Dev ops that get labs really champion to say Real time de Bob's. So we've got Dev ops in the world that's taking months and weeks of cycle times. And bring that down to minutes. We want to take you know, all your processes that take hours and take it down to seconds. So what really people, developers air sort of clamoring for a lot is like, Well, how do we get these if I'm regulated if I have a lot of customization needs? If I'm on premise, if I'm in a private network, how do I get to mobile? How do I get quicker interactions on? We really want to support that with instant response with deficit cock use cases and with really having a complete solution that could go from all your infrastructure in your data center, too. You know, that really important person walking through the airport. And that's that's how you speed cycle times and make Deb sec cops available anywhere. And you do it securely and in do it privately. >>All right, thanks so much for meeting with us. And great to hear about matter most. >>Well, thank you. Still >>all right. Be sure to check out the cube dot net for all the coverage that we will have throughout 2020 I'm still minimum. And thanks for watching the cue.

(upbeat music) >> 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. We 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 the street is, they got something different and unique. We're going to' dig into it. Amit Govrin who's the CEO and co-founder of Kubiya, which stands for Cube in Hebrew, and they're headquartered in Bay Area and in Tel Aviv. Amit, congratulations on the startup launch and thanks for coming in and talk to us in theCUBE >> Thank you, John, very nice to be here. >> So, first of all, a little, 'cause we love the Cube, 'cause theCUBE's kind of an open brand. We've never seen the Cube in Hebrew, so is that true? Kubiya is? >> Kubiya literally means cube. You know, clearly there's some additional meanings that we can discuss. Obviously we're also launching a KubCon, so there's a dual meaning to this event. >> KubCon, not to be confused with CubeCon. Which is an event we might have someday and compete. No, I'm only kidding, good stuff. I want to get into the startup because I'm intrigued by your story. One, you know, conversational AI's been around, been a category. We've seen chat bots be all the rage and you know, I kind of don't mind chat bots on some sites. I can interact with some, you know, form based knowledge graph, whatever, knowledge database and get basic stuff self served. So I 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 you know, AI as a service, machine learning, developer focused action. 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 Kubiya, what's happening? >> Certainly. So thank you for that. Kubiya is what we would consider the first, or one of the first, advanced virtual assitants with a domain specific expertise in DevOps. So, we respect all of the DevOps concepts, GitOps, workflow automation, 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 the 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. >> So the market you're going after is kind of, it's, I love to hear starters when they, they don't have a Gartner Magic quadrant, they can fit nicely, 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's subcategories within that. We can talk about the different internal developer tools, or platforms, shared services platforms, service catalogs are tangential 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". >> I think you're starting to see a lot of autonomous stuff going on, autonomous pen testing. There's a company out there doing I've seen 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, essentially hosted at their own location. >> So primary cloud, but you're agnostic on where they could consume, how they want to' consume the product. >> Technology agnostic. >> 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 value here, when you guys did the company, what problems did 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 a 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, 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. >> And that basically is what everybody wants. I mean, the developers want self-service. I mean, that's kind of like, you know, that's the nirvana. 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 and the industry insiders are talking about self-service platforms as being what's going to' remove the dependency of the operator in the loop the entire time, right? Because the operator, that 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 comes 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 is 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 want to be here, we're going to' go and do this because we're on call. We have to take it on a chin, if you may, for this. >> It's their child, they got to' 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. 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 platform, and low and behold, it's not as self-service as it may seem. >> 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. You know, 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 a human, like in the loop, essentially augment that person and give the end users all of the answers they require, as if they're talking to a person. >> I mean it's basically, you're taking the virtual assistant concept, or chat bot, to a level of expertise where there's intelligence, jargon, experience into the workflows that's known. Not just talking to chat bot, 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 EC2's with two days (indistinct). But let's say you want to go and provision new EC2 instances, 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 the loop, they would ask you the following questions: what type of environment? what are we attributing this to? what type of instance? 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. Now the problem is users don't always have these questions. So imagine the following scenario. Somebody comes in, they're in Jira 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 a context, they lose essentially the momentum. And a simple access request, or a simple provision request, can easily become a couple days of ping pong back and forth. This won't happen with the virtual assistant. >> You know, I think, you know, and you mentioned chat bots, 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, it disrupts the entire experience at that point. RPA and chat bots don't have that contextualization. Is that what you guys do differently? Is that the unique flavor here? Is that difference between current chat bots 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 bidirectional feedback loop 'cause that's actually what feeds the context and the intent. We all know Waze, right, in the world of navigation. 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 have 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 bidirectional feedback loop that the end nodes help educate the system, make the system be 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? 'Cause that's the part that they dread. And the maintenance of the system is democratized across all the users that they can teach the 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 you came on this camera interview, you said playfully that the Siri for DevOps, which kind of implies, hey infrastructure, do something for me. You know, we all know Siri, so we get that. So that kind of illustrates kind of where the direction is. Explain why you say that, what does that mean? Is that like a NorthStar vision that you guys are approaching? You want to' have a state where everything's automated in it'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 assistant, but it's not necessarily a virtual assistant. So what we're saying is we're anchoring people to that thought and saying, we're actually allowing it to be operational, turning complex operations into simple conversations. >> I mean basically they take the automate with voice Google search or a query, what's the score of the game? And, it also, and talking to the guy who invented Siri, I actually interviewed 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 AI, is it the machine learning, is it the data, is it the model? Take us through the secret sauce. >> In fact, it's all 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. Five course meal, hopefully with Michelin stars as part of that. So a few things, maybe a few of the secret sauce element, 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. >> Someone might say, hey, you know, conversational AI, that was yesterday's trend, it never happened. It was kind of weak, chat bots 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? 'Cause you know, I would argue that it's, you know, 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. We call it last mile, you know, bottlenecks. And that's really where we're helping. We're helping in a way tribalize 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 going to' go and sit down an 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 toils. And into workflows. >> Yeah, I mean some will call it grunt work, or low level work. And I think the automation is interesting. 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 were hard to do, but now harder things are coming around the corner. So, you know, 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 is the ability to abstract away the complexity. So you're starting to see the smart, hired 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 know, you don't want a high salaried 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, 'cause this goes into essentially what you just said. Think about it's not the virtual system, 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's almost like Siri, it travels in your mobile phone, it's on your laptop, it's with you everywhere. >> 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, we've met at every CubeCon 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, and the CICD pipeline, with infrastructure's 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. There's like six or seven main use cases in DevOps. So the guardrails just need to be set. So it sounds like you guys are going down the road of saying, hey here's the use cases you can bounce around these use cases all day long. And just keep doing your jobs cause 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, 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 1, on so and so customer environment last week?", and it will know how to give you that information. >> Can I ask, should I buy a reserve instances or not? Can I ask that question? 'Cause 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 the experts in here. We can tap into the partnerships, API, we have full extensibility in API and the software development kit that goes into. >> It's interesting, opinionated and declarative are buzzwords in developer language. So you started to get into this editorial thing. So I can bring up an example. Hey cube, implement the best service mesh. What answer does it give you? 'Cause there's different choices. >> Well this is actually where the operator, there's clearly guard rails. Like you can go and say, I want to' spin up a machine, and it will give you all of the machines on AWS. Doesn't mean you have to get the X one, that's good for a SAP environment. You could go and have guardrails in place where only the ones that are relevant to your team, ones that have resources and budgetary, you know, guidelines can be. So, the operator still has all the control. >> It 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 I think 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 story because that goes on to the web, that goes onto stock overflow, and that's actually one of the things. So inside the CLI, you could actually go and ask for 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. >> I was saying to a friend and we were talking about open source and how when I grew up, there was no open source. 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. >> Certainly. >> 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 a smart system is interesting 'cause 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 no code is not necessarily, even though we have the low-code editor, we're not necessarily considering ourselves low-code. >> Serverless, no code, low-code. I was so thrown on a term the other day, architecture-less. As a joke, no we don't need architecture. >> There's a use case around that by the way, yeah, we do. Show me my AWS architecture and it will build the architect 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. Again, how they deploy it is the neuron. That's what we've been striving for. >> But infrastructure is code. You can destroy, you know, terraform, you can go and create one. It's not necessarily going to' operate it for you. That's kind of where this comes in on top of that. So it's really complimentary to infrastructure. >> 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 OP 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 is now, is kind of moved into the developer realm, but the new IT is data ops and security ops basically. >> A hundred percent, and the lines are so blurred. Like who's what in today's world. I mean, I can tell you, I 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 'em operators 'cause I don't want to offend anybody because that's just the way it is. >> Architectural-less, we're going to' come back to that. Well, I know we're going to' see you at CubeCon. >> 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 itch 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 take a minute to explain the story. >> No, absolutely. So I've been living in Palo Alto for the last couple 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 for 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 pains 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 Shaked, Shaked Askayo, my co-founder and CTO. Amazing guy, unbelievable technologists, probably one the most, you know, 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, a 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 the SRE guideline would tell. >> That's more than 10 x rate developer. >> Oh, absolutely. Sure enough. And just imagine it's four different time zones. He finishes day shift and you already had the US team coming, asking for a question. He said, this is kind of a, >> Got to' 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 programed myself in the form of a bot. Essentially, when people came to him, he said, "Don't talk to me, talk to the bot". Now that was a different generation. >> 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, froze the headcount and the developer team kept on going. So that meant that he was doing some right. >> When you have a problem, and you need to solve it, the creativity comes out of the woodwork, you know, invention is the mother of necessity. So final question for you, what's next? Got the launch, what are 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. >> A hundred percent. So, Kubiya, as you can imagine, announcing ourselves at CubeCon, so in a couple weeks. Opening the gates towards the public beta and NGA in the next couple months. Essentially working with dozens of customers, Aston Martin, and business earn in. We have quite a few, our website's full of quotes. You can go ahead. But effectively we're looking to go and 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 could be essentially shared. >> How many customers do you guys have in your pre-launch? >> It's above a dozen. Without saying, because we're actually looking to onboard 10 more next week. So that's just an understatement. It changes from day to day. >> What's the number one thing people are saying about you? >> You got that right. 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. But I mean they're obviously, they're using the product and you're getting good feedback. Saving time, are they saying 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 who are in the trenches, or feeling the pain, or 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 for the 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 it on the Cube at our events, everyone says the same thing. Every developer wants self-service, period. Full stop, done. >> What they don't say is they need somebody to help them babysit to make sure they're doing it right. >> The old dashboard, green, yellow, red. >> I know it's an analogy that's not related, but have you been to Whole Foods? 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 something's not working, someone's helping you out, that's what people want. They want a human in the loop, or a human like in the loop. We're giving that next best thing. >> It's really the ratio, it's scale. It's a scaling. It's force multiplier, for sure. Amit, thanks for coming on, congratulations. >> Thank you so much. >> See you at KubeCon. Thanks for coming in, sharing the story. >> KubiyaCon. >> CubeCon. Cube in Hebrew, Kubiya. Founder, co-founder and CEO here, sharing the story in the launch. Conversational AI for DevOps, the theory of DevOps, really kind of changing the game, bringing efficiency, solving a lot of the pain points of large scale infrastructure. This is theCUBE, CUBE conversation, I'm John Furrier, thanks for watching. (upbeat electronic music)

>> Announcer: From San Francisco it's theCUBE, covering GitLab Commit 2020. Brought to you by GitLab. >> Hi, I'm Stu Miniman and this is theCUBE's coverage of GitLab Commit 2020 here in San Francisco. Happy to welcome to the program a first-time guest off the keynote stage this morning, the co-founder and CEO of GitLab, Sid Sijbrandij. Thanks so much for joining us. >> Yeah, thanks for having me. >> All right, so Sid, first of all congratulations, good energy here at the show, GitLab, definitely a company I hear lots about in my travels, so we were super excited to bring theCUBE here. So many different things on the momentum of the company, where you're going, but, I love when I have a founder on. Let's rewind a little bit as to kind of the core 'why' of the company and the skillset that that early team brought. >> Sure, the 'why' is, Demitri started GitLab in 2011. He was living in the Ukraine, he had two things he wanted to improve in life. He would like running water, he would like better collaboration software at work. And he started with what he perceived as the most important problem to solve, so he built GitLab to have that better collaboration software. I only saw it a year later, and I thought, this makes so much sense that the thing you collaborate with is also something you can collaborate on at its open source. >> Yeah, it's interesting, 'cause you say collaboration, and we saw through the Enterprise 2.0 wave and various communication technologies, I interviewed one of your partners Mattermost which is kind of related there. You get there to GitLab, which in the early days, I heard a lot about oh, is this a GitHub alternative? So how did the SCM piece end up there? >> Yeah, so we started with the SCM piece, that's what Demitri made first because he had a need for it. And it evolved, it's now a complete DevOps platform all the way from planning what you want to do on a high level to monitoring, releasing, securing what you've built. And that wasn't intuitive to us. And it came about because Demitri made Version Control, but he also made GitLabCI. That's two separate applications. And at a certain point, someone outside the company contributed a better version of GitLabCI, his name is Kamil, and we said that's amazing, we'll make that official, and do you want to join? And he joined and after a few months he said, I think we should combine the two in a single application. And my co-founder Demitri explained how he was wrong. These two are perfectly integrated, couldn't be any better. Custom-made PIs, same single sign-on, same idea of what a user can do. He also explained how he was wrong because everything in a DevOps tuning space was a point solution, people wanted to mix and match. And he kept pushing for it, and at a certain point, he said look, you might not believe that everything I say, but one thing is for sure, we'll be able to kind of ship at a faster rate if we combine it. And that was important to us, we're all about efficiency. But it turns out, he was also right about the benefits for the user. People reported like, it's so much easier having everything in a single interface, being on the same page with my other departments. And that's how we stumbled across this secret, like hey, this whole DevOps space, it started from just a few applications but now people are using 15, 20 different applications and the hand-offs between the applications were the problem. And that we could solve by bringing them together. So we doubled down on that strategy, so that's how that came about. >> Yeah, I mean there's no doubt that tool sprawl is a huge issue in the marketplace, yet when you talk to developers, when they learn a tool, they tend to really love it and they all go to bat as to, well, I sort it out and I found the best one for whatever piece of it. So how do you balance really building out a platform but if there's a piece of it that they still want to use they can, how do you balance that? >> Yeah, you got to make sure that you don't lock people in. The last thing someone wants is that they have to use everything. So open APIs, many integrations, some of which we maintain ourselves with a Jenkins and a Jura and a GitHub. But also, you make sure that sometimes people care very much about the certain piece of frictionality. So with GitLab, if they don't like a certain piece, they can improve it, they can contribute back. And every month, 200 improvements come from our users. They had something in their old application that they really liked, and now they get to add that to GitLab, and that's how you kind of take away all the objections over time. >> Yeah. Love you to comment on just the explosive growth that you've been seeing, you're now over 1100 employees, you talked about how much outside contribution you're getting there, but the amount of features that you're adding, and you're releasing every month. How do you manage the growth of the company, the growth of the product, and make sure that the company doesn't lose focus? >> Yeah. I think that we've done a really good job of splitting up the tasks of making sure every team has a part of the product that they're responsible for. They don't have to go to five other teams to get sign-off. And if you Google GitLab categories, you can find out exactly which team is responsible for the back end, for the front end, who's the product manager, who's the product marketing manager, for a specific piece of functionality. So I think that's really helped us, making sure the teams can still ship and they're not bogged down because other people don't have time. >> Yeah, the mission is that everyone can contribute, and you're looking to really help companies solve one of the key problems of being a software company, which is reducing cycle time. How does that translate into growth and revenue for your business? >> Yeah, so that cycle, the time between planning to do something and getting it out to users, that's what companies need to become software companies. And they're seeing that they're able to do that faster with GitLab. And we've seen amazing growth, we just announced we're over 100 million ARR, we're seeing amazing growth in revenue, so we're more than doubling revenue every year, we've almost tripled the amount of people working at GitLab last year to keep up with that growth. >> Yeah, very interesting dynamic, you had a sizable round of funding towards the end of 2019, congratulations on the milestone, you said in February 2020 you hit 100 million dollars ARR. I guess the question, it's publicly stated that you're looking to IPO later this year. We've seen many unicorns out there delaying what they're doing, they wait until they have 300 million dollars in revenue. Is there a reason why you're charging towards an IPO? >> We want to become a public company sooner rather than later, because first of all, we think it fits us. We're a very transparent company, we don't mind sharing what we're about and what our financials are. The second thing is, I think one of the big things holding GitLab back is that we're not as well known. And becoming a public company will help spread awareness about what we can do. And that's one of the most important things we can do. So that's why we're going forward, we'll go public when we're ready, when the market is ready. We think that's this year, we might be wrong, we'll see how it ends up this year. But we're looking forward to that, and we're looking forward to being even more transparent, and also sharing our financials. >> Sid, one of the things you said, you're over 1000 employees, and you're completely remote, as far as we know, the largest company that is 100% remote. Talk a little bit about kind of the challenges from building a culture in that type of environment but it's also something that I think GitLab's helping to enable other companies along that same journey. >> Yeah, we're figuring out a lot of things you have to do to be all remote, and we're trying to share those lessons. And that's anything from working handbook first to communication styles and being intentional about informal communications. So if you Google GitLab all remote, you'll find tons of tips. And those are based not just on what we say, but what we do. We have a public handbook of over 3000 pages with all our internal processes. You can check what we really do to make this work. And I think it's going to be the future. In the future, companies who make digital products are going to be much more all remote. And we want to enable that trend. We think it's great for team members, we think it helps you reduce your commute time, it helps you to be able to intersperse what you do at the company with what you do in your private life, you're able to go the gym or the supermarket when it's not busy, and also it helps be more flexible. So its great for team members, it's also great for companies. You get to attract people wherever they are, get much more access to talent, and the talent that people can stay with you year over year. We have a 85% retention of people who stay with GitLab every year. >> Is that something you think that spans across whatever roles they are, lots of companies that I talk to they'll have their developing groups, will be highly distributed. We've seen global development work forces for decades now, but marketing roles or product teams often have been in regional offices, obviously if you've got sales forces, groups that often they will have regional offices. So is this specific for the digital and development type organizations, or is this something you think will span across other roles? >> When we graduated at Y Combinator, they told us all this work's for engineering. It maybe works for sales because they're close to the customer. It doesn't work for finance, it doesn't work for marketing. And I think we've proven that it does work. Our marketing team is all in on GitLab. But also, we've seen other marketing teams. There was a presentation today by someone who runs a marketing team, and they're using GitLab. Not just for the issues, but they're even version controlling, they're copying, they're messaging in GitLab, so, I think the time has come to accept that the tools have gotten so good, and people have gotten so knowledgeable that it works across all departments. >> Yeah, Sid, I'd like you to comment on your partner ecosystem, that you said everything's open, so therefore there's no lock-in. How do you build more community from your peers from the vendor ecosystem? >> Yeah, you see here today we have different vendors out that they get customers here that integrate with us. There's vendors here, we have an alternative in GitLab. But they have something that they think adds unique value, and we want to give them a podium. We want people to know that we're not locking them in. So we're very helpful, we're trying to be helpful, get them on our blog, get them media, because nobody wants to be locked into one solution. So that's a really important message that we're sending. >> All right. Sid, why don't you give the final word, you've said people, GitLab is not yet a household name, what do you want to make sure that people understand who GitLab is and why they're important for the future of software development? >> Yeah, so we're a complete DevOps platform delivered as a single application, and we help people go much faster. At Goldman Sachs they went for the most important application, they went from two weeks to get that out the door to two hours to get that out the door. That's the value we can bring, because you don't have to go to 15 point solutions to get your work done. Much better visibility, people can switch teams, you have a good overview of your security posture, your productivity. That's the value we're bringing. You can reduce people's, their licensing cost, their costs of integrating things, but most importantly we can help them go faster and get to revenue faster. >> Sid Sijbrandij, thank you so much for joining us on the program, really appreciate theCUBE coming to GitLab Commit. >> Awesome, thanks for coming. >> All right, I'm Stu Miniman, check out theCUBE.net for all the shows we will be at in 2020. Thank you for watching theCUBE.