 From San Mateo, it's the Cube, covering Scalar Innovation Day, brought to you by Scalar. Everyone, welcome to this special Cube Innovation Day here in San Mateo, California. Scalers headquarters, I'm John Furrier, Coast of the Cube. We're here with two great guests, Claudia Carpenter, co-founder, Dave McAllister, who's Dev Evangelist. Great to have you guys here. We're chatting before we came on. Thanks for having us. Yeah, great to be here. So Scalar, it's all about the logs. The answer is in the logs. That's the title of this segment. Obviously, log files, we've got a lot of exhaust in there. Data value, extracting that. But it's got more operational impact. What's, why is the answer in the logs? Because that's where the real information is. It's one thing to be able to tell that something is going wrong on one of your systems, but what is going wrong? As engineers, what we tend to do is the old printf. It's like, here's everything I can think of in this moment. I leave it as breadcrumbs for myself to find later. And then I need to go and look at those breadcrumbs. And the challenge, of course, with this is that logs themselves are proliferating. There's lots of data. There's lots of services inside these logs. So you've got to be able to find your answers as fast as possible. You can't afford to wait for something else to lead you to them. You need to deep dive away. You guys have this saying, it's the place to start. What does that mean, and why is that the new approach? We're trying to differentiate. Because there's this trend right now in the DevOps world towards metrics, because they're much smaller to store. Predigesting what's going on in your systems, and then you display a lot of graphs and things like that. We agree with that. You do need to be able to see what's going on. You need to be able to set alerts. Metrics are good, but they only get you so far. A lot of people will go through, look at metrics, dig through, and then they stop. Switch over and go to their logs. We like to start with the logs, build our metrics from them, and then we go direct to the source. Clay, I think I'm going to explain what you mean by metrics, because that has multiple meanings. The current way around metrics, and you're kind of talking about a new approach, can you just take a minute to explain what you meant by metrics and how logs are setting up the metrics and the difference there? So to me, metrics is just counting things, right? So log files are these long textual representations of what's going on in my system, and it's impossible to visually parse that. I mean, literally 10,000 lines, so you count. I've got five of this one and six of this one, and it's much smaller to store. I've got five of this one and six of this one, but that's also not very much information. So that's really the difference. But we have customers who use their metrics to help them indicate something might be wrong inside of here. The problem is that in modern environments where we have instant gratification needs and people, if you wait five seconds, basically it's a lost sale online here, you need to know what went wrong, not just where it went wrong or that something went wrong. So building for the logs to the metrics allows you to also have a perfect tie back to that specific entrance that lets you figure out what was wrong. You mentioned Cloudy DevOps, and this is really kind of a fun market because DevOps is now going mainstream, and you see the enterprise now starting to adopt it still. Gene Kim from Enterprise DevOps estimates only 3% of the enterprise is really there yet. So the actions on the cloud native public cloud side, where it's full blown, cloud native, more services are coming, you see Kubernetes, things of that nature out there. And these services are being stood up and torn down algorithmically. So who the hell stores that data? So logs, the nature of log files and data is changing radically with DevOps. And certainly this is going to be more complications for developers in figuring out what's what. How do you see that? What's your reaction to that trend? Yeah, so DevOps is a very exciting thing. When we were at Google, it was sort of like the new thing is that developers had to do their own operations and that's where this comes from. Unfortunately, a lot of enterprise will just rename their ops people DevOps. And that's not the same thing. It's literally developers doing operations. And right now that it's never been so exciting as it is right now in the tech stacks because you can get so much that's open source, prebuilt, just glue this, all these things together. But since you haven't written the code yourself, you have no idea what's going on. So it's kind of like braille. You got to go back and look and feel your way through it to figure out what's going on. And that's where logs come into play. So logs essentially can lift up and give people eyesight into visibility of things that they care about. Absolutely. So what's this red thing? You're talking about red. What is red? Red is one of the approaches. You'll hear things like golden signals. You'll hear use and you'll hear red. But red stands for rates, errors, and duration. And red is a concept that says how do you actually work with some of these complex technologies working with you're talking about and actually determine where your problems are. So if you think about it, rate is kind of how much traffic's going through a signal for this as a metric, it's a cumulative number. So back to Claudia's point, it's just a number here. But if your traffic goes up, you want to know what's going wrong. Errors, self-explanatory, something broke, fix it. And then duration is how long things took. You talked about Kubernetes. Kubernetes works hands and hands with this concept of microservices. Microservices are everywhere. And there can be places that have thousands of little services all serving the bigger need here. If one of them goes slow, you need to know what went slow as fast as possible. So rate, duration, and errors actually combine to give you the overall health of your system while at the same point, logs will actually figure out why it's causing those problems. Well, I think I'm intrigued by what Claudia said around this Braille concept. Because essentially a lot of people are flying blind with what's going on. But you mentioned microservices, that's one area that's coming, you've got stateful data, stateless data, where if an API economy certainly has state becomes important for these applications, the developers don't may or may not know what's happening. So they need to have some intelligence. Also security we've seen in the cloud when you have a lot of people standing up instances, whether it's on Amazon or other clouds, they don't actually have security on some of their things. So they got to figure out the trails of what the data looks like. They need log files to have understanding of did something happen, what happened, what is the bottom line here Claudia? What do people do to kind of get visibility so they're not flying blind as developers and organizations? Well, you've got to log everything you can within reason, you always have to take into account privacy and security, but log as much as you can and pull logs from every one of the components in your systems. The microservices that Dave was just talking about are so cool and as engineers we can't resist them. We love complexity. And cool things. And cool things, especially cool things. And new things, green things, sorry, easily distracted. But they are harder to support. They can be a really difficult environment. So again, it's back to breadcrumbs leaving that trail and being able to go back and reconstruct what happened. Okay, what's the coolest thing about scaler since we talked about cool and relevant? You guys, certainly on the relevant side, I think check the box there. What's cool? What's cool about scaler? What isn't? Technology, tell us. That's a great answer, what isn't? But honestly, when I came to work here, I had no idea. I was made with log management. I was really with log search and so forth. And the first time I actually saw the product, my jaw dropped. Okay, I now go to a trade show for instance and I'm showing people to use this and I hit my turn button to get my results and the show bandwidth can be really bad. And it stalls for a tenth of a second and I complain about it now. There's nothing quite as thrilling as getting your results as fast as you can think about them. Almost your thought process is the slow part of determining what's going on. And that is mind-boggling. So the speed is the killer? The speed is what killed me, but honestly, something that Chloe's been heavily involved in, it takes you two minutes to get started. I mean, there's no long learning curve. You get the product and you are there. You're ready to go. Chloe, let's talk about ease of use and simplicity because developers are fickle but they're also loyal. You have a good product though. They love to get in. They love the freebie, the 30-day trial. They'll keep the tires on anything. But if the product isn't working, you hear about it. When it does work, there's mass traffic too if people pound to the doorstep of the product. What's the compelling value proposition for the developer out there? Because they don't want to waste time. That's like the killer death to any product for developers. If they waste their time, they don't want to deal with it. So we live in the TLDR world right now. Frankly, if I have to read something, I usually move on. And that's the approach we take with Scalar as well. Yes, we have some documentation but I always feel like I have failed with the user interface design if I require you to go read the documentation. So I try to take that into account with everything that we put out there, making it really easy and fast to just jump in and try stuff. How do you guys solve the complexity problem? Through abstraction software, what's the secret sauce for the simplicity of the system? For me, it's a complete lack of patience. It's just like, I wouldn't put up with that. I'm not going to ask you to. Frankly, I view, this sounds a little bit trite, but I view software as a relationship and I view whoever is looking at it as a peer of mine and I would be embarrassed if they couldn't figure it out if it wasn't obvious. But it is, we do have this sort of slope here of people who really know what's going on and people who want to optimize, this is your 80-20 split, and people that don't know and just want to come in, I want both of them to be happy. So we need to blend those two. We talk about the value proposition of what you guys have because we've been covering log file management, log management, as long events we've gone to. There's been solutions that are, I think maybe going on 10 years old that were once cutting edge, but the world changes so fast with Amazon Web Services, with Google Cloud, with Azure, then you got the international clouds out there as well, it's here. I mean, the scale is there, you got compute, you got the edge of the network right around the corner. I mean, the data problem's not going away. Log file's going to be needed. We're going to have all this data exhaust that needs to be valued. If anything, there's always going to be more data that's out there, you're going to have more sources of that data coming in here. You're talking a little bit about, you're going to have the hybrid cloud where it's part on-prem, part in the cloud. You're going to have multi-clouds where it crosses boundaries. You're going to have the wonderful IoT world where you have no idea when or where you're going to get an upload from to this, to an edge environment, and you've got to worry about this. And at the same time, the logging everything, the breadcrumbs, you have ephemeral events. They're not always there, and those are the ones that'll kill you. So the model is really simple, and applaud Claudia for concept-wise, but you're familiar with the concept of kiss, right? Well, here it's keep it simple and sophisticated at the same time. So I can teach you to do this demo in two minutes flat. And from there, you can teach yourself everything else that this product is capable of doing. It's that simple. Talk about who the person out there that you want to use this product and why should they give Scaler a look? What's in it for them? So for me, I think the perfect is to have DevOps use it. It's developers. We really have designed a product less for ops and more for engineers. So one of the things that is different about Scaler is you have somebody come in and set it up. You parse the logs at ingestion of logs, which is different than Splunk and Sumo. And then it's ready to use right out of the box. So for me, I think that our sweet spot is engineers because a lot of our formulations of things you do are more technical. You're thinking about what are the patterns here. I'm not going to say it's calculus because then that wouldn't be simple, but it's along those lines. For engineers, it might be. Calc one maybe. Well, calculus is fabulous. And also cloud native is a really key part. I mean, people who are cloud native or actually looking at born in the cloud or cloud migration. Right, we see a lot, for instance, in the Kubernetes space from the cloud native compute foundation. We're seeing a tremendous interest in Prometheus. We're seeing a lot of interest in Istio, which is Service Mesh. The nice thing is that they are already all admitting logs themselves. And so from our viewpoint, we bring them in, we put them together. So now you can look at each piece as it relates to the other piece. Claudia, share with the folks who are watching this just some anecdotal use cases that you guys have used internally with other customers that give them a feel for how awesome Scalar is and what could they expect? Oh, wait, put me on the spot here. I'll kick off. So we have a customer in Germany. They're an e-commerce shop. They have a thousand engineers for here. When we started, the product we replaced because it was on a charge basis that was basically per user, they came back and they said, oh my God, you don't understand. Our queries are taking 15 minutes to get back. By the time the query comes back, the engineer's forgotten why he asked the question for this. And so they loaded up. They rapidly discovered something unique. It's that they can discover things because anyone can use it. We now have 500 engineers that touch the log files every day. I will attest, having written code myself, nobody reads log files for fun, but Scalar makes it easy to discover new things and new connections, and they actually look at what happens. So discovery is a real value proposition. Discovery is a massive value proposition. Where you figure out things that you don't know about. Back to that events thing that Claudia started about, was you can only measure the events that you can already considered. You can't measure things that didn't happen. Claudia, I quickly talk about the culture. And Dave, you can chime in. What's the culture like here, Scalar? It is a unique culture. And I know everyone probably says that about their startup, but we keep work-life balance as a very important component. We're such nerds and unabashed nerds. We love what we do. It's a joyful atmosphere to work in. Our founder, Steve Newman, is there in his flannel shirt and his socks cruising around. And we are very much into our quality of our code. We have a lot of the principles of Google sort of combined into a startup. I would say it's a very honest environment. Solve hard problems, make it a good work environment. Yeah, and provide real value. Provide real value is so critical for me. And have fun at the same point in time. The people here work hard, but they share what they're working on. They share information. They're not afraid to answer the, what are you working on question? But we always manage to have fun. We're a pretty tight group that way. Well, thanks for sharing the insight. We have a lot of fun here. At Innovation Day with theCUBE here, I'm John Furrier. Thanks for watching.