>> from San Matteo. It's the Cube covering Scaler. Innovation Day. Brought to You by Scaler >> The Run Welcome to this special on the Ground Innovation Day. I'm John for a host of The Cube. We're here at scale. His headquarters in San Mateo, California Hardest Silicon Valley. But here the cofounder and CEO Steve, It's Irwin Ski and Jeff Low product marketing director. Thanks for having us. Thanks for having us. Thank you. But a great day so far talked Teo, the other co founders and team here. Great product opportunity. You guys been around for a couple of years, Got a lot of customers, Uh, just newly minted funded syriza and standard startup terms. That seems early, but you guys are far along, you guys, A unique architecture. What's so unique about the architecture? >> Well, thinks there's really three elements of the architecture's designed that I would highlight that differentiates us from our competitors. Three things that really set us apart. I think the biggest the 1st 1 is our use of a common our database. This is what allows us to provide a really superior search experience even though we're not using keyword indexing. Its purpose built for this problem domain and just provides us with great performance in scale. The second thing I would highlight would be the use of well, essentially were a cloud native solution. We have been architected in such a way that we can leverage the great advantage of cloud the scale, ability that cloud gives you the theological city. That cloud gives you andare. Architecture was built from the ground up to leverage that, uh and finally I would point out the way that we do our data. Um, the way that we don't silo data by data type, essentially any type of observe ability, data, whether it's logs or tracing or metrics. All that data comes into this great platform that we were in that provides a really great superior query performance over, >> and we talked earlier about Discover ability. I want to just quickly ask you about the keyword indexing and the cloud native. To me, that seems to be a two big pieces because a lot of the older all current standards people who are state of the art few years ago, 10 years ago, keyword index thing was a big part of it, and cloud native was still emerging except for those folks that were born the clouds. So >> this is a dynamic. How important is that? Oh, it's It's just critical. I mean, here, when we go to the white board, I love to talk about this in a little more detail in particular. So let's let's talk about keyword indexing, right? Because you're right. This is a lot of the technology that people leverage right now. It's what all of our competitors do in keyword indexing. Let's let's look at this from the point of view of a log ingestion pipeline. So in your first stage, you have your input, right? You've got your raw logs coming in. The first thing you do after that typically is parse. You're goingto parse out whatever fields you want from your logs. Now, all of our competitors, after they do that, they do in indexing step. Okay, this has a lot of expense to it. In fact, I'm going to dig into that after the log content is index. It's finally available for search. Where will be returned as a search result. Okay, this one little box, this little index box actually has a lot of costs associated with it. It contributes to the bloat of storage. It contributes to the cost of the overall product. In fact, that's why I love our competitors. Charge you based on how much you're indexing now, even how much you're ingesting. When you look at the cost for indexing, I think you can break it down into a few different categories. First of all, building the index. There's certain costs with just taking this data, building the index and storing it. Computational storage, memory, everything okay, But you build the index in order to get superior query performance, Right? So that kind of tells you that you're going to have another cost. You're going tohave an optimization cost. Where the index is that you're building are dependent on the queries that your users want to conduct, right, because you're trying to make sure you get as good of query performance as possible. So you have to take a look at the career. Is that your user performing the types of logs that you're coming in and you have to decide what indexing that you want to do? Okay. And that cost is shouldered by the burden of the customers. Um, okay, but nothing static in this world. So at some point your logs are going to change. The type of logs here in Justin is going to change. Maybe your query is goingto change. And so you have another category of costs, which is maintenance, right? You're going to have to react to changes in your infrastructure. It's used the type of logs you're ingesting, and basically, this is just creates a whole big loop where you have to keep an eye on your performance. You have to be constantly optimizing, maintaining and just going around in the circle. Right? And for us, we just thought that was ridiculous because all this costs is being born by the customer. And so when we designed the system, we just wanted to get rid of that. >> That's the classic shark fin. You see a fin on anything great whites going to eat you up or iceberg. You see that tip you don't see what's underneath? This seems to be the key problem, because the trend is more data. New data micro services gonna throw off new data type so that types is going up a CZ. Well, that's what that does that consistent with what you got just >> that's consistent. I mean, what we hear from our customers is they want flexibility, right? These are customers that are building service oriented, highly scalable applications on top of new infrastructure. They're reacting to changes everywhere, so they want to be able to not have to, you know, optimize their careers. They're not goingto want to maintain things. They just want to search product that works. That works over everything that they're ingesting. >> So, good plan. You eliminate that fly wheel of cost right for the index. But you guys, you were proprietary columnist, Or that's the key on >> your That's a Chiana and flexibility on data types. Yes, it does. And here, let me draw a little something to kind of highlight that because, you know, of course, it's a it begs the question. Okay, we're not doing keyword indexing. What do you do? What we do actually is leverage decades of research and distribute systems on commoner databases, and I'll use an example on or two >> People know that the data is, well, that's super fast, like a It's like a Ferrari. >> Yes, it's a fryer because you're able to do much more targeted essentially analysis on the data that you want to be searching over, right? And one way to look at this is, uh, no, Let's take a look at ah, Web access lock. Okay. And when we think about this and tables, we think that each line in the table represents, ah, particular entry from the access log. Right. And your columns represent what fields you've extracted. So for example, one the fields you might extract is thie HP status code. You know, Was it, um, a success or not? Right. Or you might have the your eye, or you might have the user agent of the incoming web request. Okay. Now, if you're not using a commoner database approach to execute a quarry where you're trying to count the number of non two hundreds that you've your Web server has responded with, you'd have to load in all the data for this >> table, right? >> And that's just its overkill in a commoner database. Essentially, what you do is you organize your data such that each column essentially has saved as a separate file. So if I'm doing a search where I just want to count the number of non two hundreds. I just have to read in these bites. And when your main bottleneck, it's sloshing bites in and out of Main Ram. This just gives you orders of magnitude better performance. And we've just built this optimize engine that does essentially this at its core and doesn't really well, really fast leveraging commoner database technology. >> So it lowers the overhead. You have to love the whole table in. That's going to take time. Clearing the table is going to take time. That seems to be the update. That's exactly right. Awesome, right? Okay. All right, Jeff. So you're the director of product marketing. So you got a genius pool of co founders here? Scaler. Been there, done that ball have successful track records as tech entrepreneurs, Not their first rodeo, making it all work. Getting it packaged for customers is the challenge that you guys have you been successful at it? What does it all mean? >> Yeah, it essentially means helping them explore and discover their data a lot more effectively than they happen before, you know, With applications and infrastructure becoming much more complex, much more distributed, our engineering customers are finding it increasingly difficult to find answers And so all of this technology that we've built is specifically designed to help him do that at much greater speed, Much greater ease, much more affordably and at scale. We always like to say we're fast, easy, affordable, at scale. >> You know, I noticed in getting to know you guys and interviewing people around around company. The tagline built by engineers for engineers is interesting. One. You guys are all super nerdy and geeky, so you get attacked and you take pride in the tech in the code. But also, your buyers are also engineers because they're dealing with cloud Native Wholenother Dev ops, level of scale where they love scale people in that market love infrastructures code. This is kind of the ethos of that market, but speed scale is what they live for, and that's their competitive advantage in most cases. How do you hit that point there? What's the alignment with the customers on scale and speed? >> Yeah, you know, with the couple of things that Stephen had mentioned, you know, the columnar database on DH, he mentioned cloud native. We like to refer to that as massively parallel or true multi tendency in the cloud those 11 two things give us really to key advantages when it comes to speed. So speed on in just that goes back to what Steven was talking about with the column. In our database, we're not having a weight to build the index so weakening unjust orders of magnitude faster than traditional solutions. So whereas a conventional solution might taking minutes even up to hours to ingest large sets of data, we can literally do it in seconds. It's the data's available immediately for used in research. One of our customers, in fact, that I'm thinking of down Australia actually uses our live tail because it actually works and as they push code out to production that can actually monitor what happens and see if the changes are impacting anything positively or negatively >> and speed two truths, a tagline the marking people came up with, which is cool. I love that kind of our fallouts. We have to get the content out there and get that let the people decide. But in your business, ingestion is critical. Getting the ingestion to value time frame nailed down is table stakes. People engineers want to test stuff. It doesn't work out of the box we ingest and they don't see value. They're not gonna kind of be within next levels. Kind of a psychology of the customer. >> Yeah, You know, when you're pushing code, you know, on an hourly basis, sometimes even minutes now, the last thing you want to do is wait for your data to analyse it, especially when a problem occurs. When a problem occurs and it's impacting a customer or impacting your overall business. You immediately go into firefighting mode, and you just can't wait to have that data become available so that speed to ingest becomes critical. You don't want to wait. The other aspect on the speed topic is B to search. So we talked about the types of searches that are calling. Our database affords us a couple that, within massively parallel and true multi tendency approach, basically means that you could do very, very ad hoc searches extremely quickly. You don't have to bill the keyword index. You don't have to have two, even build a query or learn how to build queries on DH, then run and then wait for it. And maybe in the meantime, wait to get a coffee or something like that. >> I mean, we grew up in Google search. Everyone who's exactly the Web knows what searches and discoveries kind the industry word in discovering navigation. But one of the things about searches about that made Google say Greg was relevance. You guys seem to have that same ethos around data discover, ability, speed and relevance. Talk about the relevance piece, because I think that, to me is what is everyone's trying to figure out as more data comes in? You mentioned some of the advantages Steven around, you know, complexity around data types. You know, Maur data types are coming on, so Relevance sees, is what everyone's chasing. >> So one of >> the things that I think we are very good at is helping people discover what is relevant. There are solutions out there. In fact, there's a lot of solutions out there that will focus on summarizing data, letting you easily monitor with a set of metrics, or even trace a single transaction from point A to point B through a set of services. Those are great for telling you that there is a problem or that problem exist. Maybe in this one service, this one server. But where we really shine is understanding why something has happened. Why a problem has occurred. And the ability to explore and discover through your data is what helps us get to that relevancy. >> Ameren meeting Larry and Sergey back into 1998. And you know, from day one it's fine. What you looking for him? And they did their thing. So I want to just quickly have you guys explain it. I think one thing that also has come up love to get your take on it, guys, is multi tendency urine in the clouds to get a lot of scale. We're out of resource talk about the debt. Why multi tendency is an important piece and what does that specifically mean? But the customer visa be potentially competitive solutions. And what do you guys bring for the tables? That seems to be an important discussion Point >> sure know. And it is one of the key piece of our architecture. I mean, when we talk about being designed for the cloud, this is a central part of that right? When you look at our competitors, for the most part, a lot of them have taken existing open the source off the shelf technologies and kind of taking that and shoved it into this, you know, square hole of, you know, let's run in the cloud, right? And so they're building. These SAS services were essentially they pretend like everyone's got access to a lot. Resource is but under the covers there, sitting there, spinning up thes open source solutions. Instances for each of the customers each of these instances are on ly provisioned with enough ramsi pew for that customer's needs, right? And so heaven forbid you try to issue more crews than you normally do or try to use Mohr you know, storage than you normally do, because your instance will just be capped out, right? Um, and also it's kind of inefficient in that when your users aren't issue inquiries, those CPU and RAM researchers are just sitting there idle instead, what we've done is we've built a system where we essentially have a big pool of resource is we have a big pool of CPU, a big pool of ram, a big pool of disc. Everyone comes in, get access to that, so it doesn't matter what customer you are. Your queries get full access to all these si pues that we have run around right? And that's that's the core of multi tendency is that we're able to not provision for just one look for each individual customer. But we have a big pool of resource is that everyone gets the >> land that's gonna hit the availability question on. And it's also have a side effect for all those app developers who want to build a I and stuff used data and build these micro services systems. >> They're going to get >> the benefit because you have that closed loop. Are you fly? Will, if you will. >> Yeah, yeah, the fight could just add the multi tendency really gives us a lot of economies of scale, both from, you know, the over provisioning and the ability to really effectively use resources. We also have the ability to pass those savings on to our customers. So there's that affordability piece that I think is extremely important. Find answers, this architectural force that >> Stephen I want to ask you because, you know, I know the devil's work pretty well. People are they're hard core, you know. They build their own stuff. They don't want us, have a vendor. Kuo. I can do this myself. There's always comes up there. But this use cases here. You guys seem to be doing well in that environment again. Engineering led solution, which I think gives you guys a great advantage. But what's the How do you handle the objection when you hear someone say, Well, I could do it. Just go do it myself. >> What I always like to point at is, yes, you can up to a decree, right? We often hear people that use open source technologies like elk. They can get that running and they can run it up to a certain scale like a you know, tens of gigabytes per day of logs. They're fine, right? But with those technologies, once it goes above a certain scale, it just becomes a lot more difficult to run. It's one those classic things you know, getting 50% of the way. There is easy getting 80% of the way. There is a lot harder. Getting 100% is almost impossible, right? And you, as whatever company that that that you're doing whatever product you're building, do you really want to spend your engineer? Resource is pushing through that curve, getting 80%. 100% of kind of good, a great solution. No, what we always pitches like Look, we've always solve these problems. These hard problems for this problem, too may come and leverage our technology. You don't have to spend your engineering capital on that. >> And then the people who are doing that scale that you guys provide, they want, they need those engineering resource is somewhere else. So I have to ask, you just basically followed question. Which is how does the customer know whether they have a non scaleable for scaleable solution? Because some of these SAS services air masquerading as scaleable solutions. >> No, they are. I mean, we we actually encourage our customers when they're in the pre sale stage to benchmark against us. We have ah customer right now that sending us terabytes of data per day as a trial just to show that we can meet the scale that they need. We encourage those same customers to go off and ask the other competitors to do that. And, you know, the proof is in the pudding. >> And how's the results look good? Yeah. So bring on the ingest Yes, that's that's That's the sales pitch. Yes, guys, thanks so much for sharing the inside. Even. Appreciate it, Jeff. Thanks for sharing. Appreciate it. I'm John for the Cube. Here for a special innovation Days scales >> headquarters in the heart of >> Silicon Valley's sent Matteo California. Thanks for watching.