>>Hello, everyone. Welcome to the cubes presentation of the a startup showcase. This is our season two episode four of the ongoing series covering exciting hot startups from the a AWS ecosystem. And here we talk about cybersecurity. I'm John furrier, your host we're joined by Carl Mattson, CISO, chief information security officer of no name security, keep alumni. We just chatted with you at reinforce a business event. We're here to talk about securing APIs from code to production. Carl, thanks for joining. >>Good to see you again. Thanks for the invitation, John. >>You know, one of the hottest topics right now about APIs is, you know, it's a double edged sword, you know, on one hand, it's the goodness of cloud APIs make the cloud. That's the API first. Now you're starting to see them all over the place. Is APIs everywhere, securing them and manage them. It's really a top conversation at many levels. One, you're gonna have a great API, but if you're gonna manipulate the business logic, that's a problem too. So a lot going on with APIs, they're the underpinnings of the modern enterprise. So take us through your view here. How are you guys looking at this? You want to continue to use APIs, they're critical connective tissue in the cloud, but you also gotta have good plumbing. Where, what do you do? How do you secure that? How do you manage it? How do you lock it down? >>Yeah, so the, the more critical APIs become the more important it becomes to look at the, the API as really a, a, a unique class of assets, because the, the security controls we employ from configuration management and asset management, application security, both testing and, and protection like, like EDR, the, the, the platforms that we use to control our environments. They're, they're, they're poorly suited for APIs. And so >>As the API takes prominence in the organization, it goes from this sort of edge case of, of, of a utility now to like a real, a real crown jewel asset. And we have to have, you know, controls and, and technologies in place and, and, and skilled teams that can really focus in on those controls that are, that are unique to the API, especially necessary when the API is carrying like business critical workloads or sensitive data for customers. So we really have to, to sharpen our tools, so to speak, to, to focus on the API as the centerpiece of a, of an application security program, >>You know, you guys have a comprehensive view. I know the philosophy of the company is rooted in, in, in API life cycle development management runtime. Can you take a minute to explain and give an overview of no name security? And then I wanna jump into specifically the security platform and the capabilities. >>Sure. So we're an API security company just under three years old now. And, and we we've taken a new look at the API, looking at it from a, from a, a full lifecycle perspective. So it, it, isn't new to application security professionals that APIs are, are a software asset that needs to be tested for security, vulnerabilities, security testing prior to moving into production. But the reality is, is the API security exposures that are hitting the news almost every day. A lot of those things have to do with things like runtime errors and misconfigurations or changes made on the fly, cuz APIs are, are changed very rapidly. So in order for us to counter API risks, we have to look at the, the full life cycle from, from the moment the developer begins, coding the source code level through the testing gates, through the, the operational configuration. And then to that really sophisticated piece of looking at the business logic. And, and as you mentioned, the, the business logic of the API is, is unique and can be compromised with, with exploits that, that are specific to an API. So looking at the whole continuum of API controls, that's what we focused on. >>It's interesting, you know, we've had APIs for a while. I mean, I've never heard and seen so much activity now more than ever around APIs and security. Why is it recently we're seeing this conversation increase with specific solutions and why are we seeing more breaches and concerns about security? Because APIs are hardened. I mean, like, what's the big deal. Why now what's the big focus? Why is APIs becoming more in the conversation for CSOs and companies to secure? And why is it a problem? >>Well, take, take APIs that we had, you know, eight, 10 years ago, most of those were, were internally facing APIs. And so there were a lot of elements of the API design that we would not have put in place if we had intended that to be public facing authentication and authorization. That that was, is we kind of get away with a little bit of sloppy hygiene when it's internal to the network. But now that we're exposing those APIs and we're publishing APIs to the world, there's a degree of precision required. So when we, when we put an API out there for public consumption, the stakes are just much higher. The level of precision we need the business criticality, just the operational viability and the integrity of that API has to be precise in a way that really wasn't necessary when the API was sort of a general purpose internal network utility as it was in the past. And then the other, other area of course, is then just the sheer use of a API at the infrastructure layer. So you think about AWS, for example, most of the workloads in the modern cloud, they communicate and talk via API. And so those are even if they're internally facing APIs misconfigurations can occur and they could be public facing, or they could be compromised. And so we wanna look at all, all of the sort of facets of APIs, because now there's so much at stake with getting API security, right. >>You know, this brings up the whole conversation around API to API, and you guys talk about life cycle, right? The full life cycle of an API. Can you take me through that and what you mean by that? Because, you know, some people will say, Hey, APIs are pretty straightforward. You got source code, you can secure it. Code scanning, do a pen test. We're done why the full cycle approach is it because APIs are talking to third parties? Is it because what I mean, what's the reason what, what's the focus, why full life cycle of an API? Why should a company take this approach? >>Sure. So there's, there's really three sort of primary control areas that we look at for, for APIs as like what I call the traditional controls. There would be those to, to test and ensure that the source code itself has as quality or is, is secure. And that can, that can, of course, usually a step one. And that's, that's an important thing to, to do, but let's say let's for the sake of discussion that API that is designed securely is deployed into production, but the production environment in which it's deployed, doesn't protect that API the way that the developer intended. So a great example would be if an API gateway doesn't enforce the authentication policy intended by the developer. And so there we have, there's not the developer's fault. Now we have a misconfiguration in production. And so that's a, that's a type of example also where now a, an attacker can send a sort of a single request to that API without authentication or with, you know, misformed authentication types and, and succeed resulting in data. >>The waft didn't protect against it. It was secure code. And so when we look at the sequence of API controls, they all really have to be in sync because source code is really the first and most important job, but good, good API design and source code doesn't solve all challenges for their production environment. We have to look at the whole life cycle in order to counter the risk IBM's research last year in its X worth survey, estimated that 60% of all API breaches are due to misconfiguration, not to source code design. And so that's really where we have to marry the two of the runtime protection configuration management with the, the, the source code testing and design. >>It's, it's interesting, you know, we've all been around the block, we've seen the early days and you know, it was really great back in the day you sling an API, Hey, you know, Carl, you have an API for that. Oh, sure. I'll bang it out tonight. You know? So, so the, you know, they've gotten better, I'm over simplifying, but you get the idea they've been kind of really cool to work with and connect with systems. It's now plumbing. Okay. So organizations have, are dealing with this, they're dealing with APIs and more of them, how do they know where they stand? Is there like a API discovery capability? What do they do? What does a CSO do? What does a staff do saying, okay, you know what? We don't wanna stop the API movement cuz that's key to the cloud. How do we reign it in? How do we reign in the chaos? What do they do? Is there playbook? What does, how does an organization know exactly where it stands with the state of their APIs? >>Yeah. That, and that's usually where we started a discussion with a, with a customer is, is, is a diagnosis, right? Because when we, when we look at sort of diagnosing what our API risk exposure, the, you know, the, the first critical control is always know your assets and, and that we, we have to discover them. So we, we, we employ usually discovery as the very first step to see the full ecosystem of APIs, whether they're internal, external facing, whether they're routed through a gateway or whether they're routed through a WF, we have to see the full picture and then analyze that API footprint in terms of its network context, it's vulnerabilities, it's configuration qualities so that we can see a picture of where we are now in, in any particular organization, we may find that there's a, a, a, a high quality of source code. >>Perhaps the gaps are in configuration, or we may see the reverse. And so we, we don't necessarily make an assumption about what we'll find, but we know that that observability is really the, the first step in that, in that process is just to really get a firm sort of objective understanding of, of where the APIs are. And, and the really important part about the, the observability to the API inventory is to do it with the context also of the sense of the data types. Because, you know, for example, we see organizations, our own research showed that for organizations over 10,000 employees, the average population of APIs is over 25,000 in each organization, 25,000 AP thousand APIs is an extraordinary amount to, to even contemplate a human understanding of. So we have to fingerprint our APIs. We have to look at the sensitive data types so that we can apply our intellect and our resources towards protecting those APIs, which have, which are carrying sensitive data, or which are carrying critical workloads, because there are a lot of APIs that still remain today, even sort of internally facing utilities, work courses that keep the lights on, but not particularly high risk when it comes to sensitive data. >>So that, that, that triage process of like really honing in on the, on the high risk activity or the high risk APIs that they're carrying sensitive data, and then then sort of risk exposure assessing them and to see where an organization is. That's always the first step, >>You know, it's interesting. I like your approach of having this security platform that gives the security teams, the ability to kinda let the developers do their thing and, and then have this kind of security ops kind of platform to watch and monitor and any potential attacks. So I can see the picture there. I have to ask you though, as a CSO, I mean, what's different now, because back in the old days where API's even on the radar and two, there's a big discussion around software supply chain. This kind of this API is now a new area. As you'd been referring to people, stealing data, things are in transit with APIs. What is the, the big picture, if you had to kind of scope out the magnitude of like the API problem and, and relevance for a fellow CSO, how, how would you have that conversation? You'd be like, Hey, APIs are outta control. You gotta reign it in. Or is it a 10 and a 10? Is it a eight? I mean, yep. Take me through a conversation you're having with security teams or other CSOs around the magnitude of the scoped scoping the problem. >>Yeah. So I, I think of the, the, the API sort of problem space has a lot of echoes to the, to the conversations and the thought processes we were having about public cloud adoption a few years ago. Right. But there was, there were early adopters of public cloud and, and over the course of time, there was sort of a, an acquiescence to public cloud services. And now we have like actually like robust enterprise grade controls available in public cloud. And now we're all racing to get there. If we, if we have anything in the data center left, we're, we're trying to get to the public cloud as fast as possible. And so I think organization by organization, you'll, you'll see a, a, a reminiscent sort of trajectory of, of API utilization, because like an application we're out of gone are the days of the monolithic application, where it's a single, you know, a single website with one code base. >>And I kind of compare that to the data center, this comparison, which is the monolithic application is now sort of being decomposed into microservices and APIs. There are different differences in terms of how far along that decomposition into microservices and organization is. But we definitely see that the, that that trend continues and that applications in the, you know, three to five to 10 year timeframe, they increasingly become only APIs. So that an organization's app development team is almost exclusively creating APIs as, as the, as the output of software development. Whereas there's a, there's a journey to, towards that path that we see. And so, so a security team looking at this problem set, what I, you know, advise for, for a CISO. The looking at this maybe for the first time is to think about this as this is the competency that we, our security teams need to have. That competency may, may be at different degrees of criticality, depending on where that company is in transition. But it's not a, it's not a question of if it's a question of when and how fast do we need to develop this competency in a team because our applications will become almost exclusively APIs over time, just like our infrastructures are on the way to becoming almost exclusively public cloud hosted over time. >>Yeah. I mean, get on the API bus basically is the message like, look it, if you're not on this, you're gonna have a lot of problems. So in a way there's a proactive nature here for security teams at the same time, it's still out there and growing, I mean, the DevOps movement was essentially kind of cavalier, very Maverick oriented, sling APIs around no problem, Linga Franco connecting to other systems and API to an endpoint to another application. That's what it was. And so as it matures, it becomes much more of a, as you say, connective tissue in the cloud native world, this is real. You agree with that obviously? >>Yeah, absolutely. I mean, I think that the, I think that these, these API connections are, are, are the connective tissue of most of what we do right now. Even if we are, are not, you know, presently conscious of it, but they're, they're increasingly gonna become more and more central. So that's, that's, that's a, that's a journey whether, whether the, the focus on API security is to let's say, put the toothpaste back in the tube for something that's already broken, or whether it is preventative or prep preparing for where the organization goes in the future. But both of those, both of those are true. Or both of those are valid reasons to emphasize the investment in API security as a, as a talent processes, technologies all the above. >>Okay. You sold me on I'm the customer for a minute. Okay. And now I'm gonna replay back to you. Hey, Carl, love it. You sold me on this. I'm gonna get out front we're we're in lift and shift mode, but we can see APIs as we start building out our cloud native. And, but I'm really trying to hire a team. I got a skills gap here too. Yep. That's one customer. Yep. The other customers, Hey man, we've been on this train for a while. Kyle. We, we, we feel you, we in DevOps pioneer, we're now scaling out. We got all kinds of sprawl, API sprawl. How do I reign it in? And what do you guys do? What's your answer to those scenarios from a security platform perspective and how does that, what's the value proposition in those scenarios? >>I think the value proposition of what we've done is really to, to lean into the API as the, as the answer key to the problem set. So, you know, whether it's integrating security testing into a code repo, or a C I C D pipeline, we can automate security testing and we can do that very efficiently in, in such a way that one applic when a one API security specialist with the right tools, it ins insulates the organization from having to go out and hire 10 more people, because they've all, all of a sudden have this explosive growth and development. There's so much about API security that can capitalize on automation and capitalize on API integrations. So the API integrations with web application firewalls, with SIM systems, those types of workflows that we can automate really do empower a team to, to use automation to scale and to approach the problem set without needing to go to the, the, sort of the impossible ask of growing these growing teams of people with special skills and, and who aren't available anyways, or they're extremely expensive. So we definitely see ourselves as, as a, as a sort of leaning into the API as, as part of the answer and creating opportunities for automation. >>Yeah. So I got one more kind of customer role play here. I says, I love this. This is a great conversation. You know, there's always the, the person in the room, Carl, hold on, boss. This is gonna complicate everything on the network layer, application changes. There's a lot of risks here. I'm nervous. What's your, how do you guys handle that objection that comes up all the time. You know, the, the person that's always blocking deals like, oh, it's risky implementing no name or this approach. How do you, how do you address the frictionless nature of developers? Wanna try stuff now they wanna get it in and they wanna try things. How do you answer the quote, complication or risk to network and application changes? >>Sure. Two, two really specific answers. The, the first is, is for the developers. We wanna put a API security in their hands because when they can, when they can test and model the security risks on their APIs, while they're developing, like in their IDE and in their code repos, they can iterate through security fixes and bugs like lightning fast. And they, and developers Le really appreciate that. They appreciate having the instant feedback loop within their workspace, within their workbench. So developers love being able to self-service security. And we want to empower developers to, to do that. Self-service rather than tossing code over the fence and waiting two weeks for the security team to test it, then tossing it back with a list of bugs and defects that annoys everybody. It's an inefficient. So >>For the record, just for the record, you guys are self-service to the developers. >>Yeah. Self-service to the developers. And that's really by customer sort of configuration choices. There are configuration choices that have, for example, the security team, establishing policy, establishing boundaries for testing activities that allow the developers to test source code iterate through, you know, defect, fixes, things like that. And then perhaps you establish like a firm control gate that says that, you know, vulnerabilities of, of medium and above are a, have to be remediated prior to that code committing to the next gate. That's the type of control that the security policy owner can can apply, but yes, the developers can self-service service and the, and the security team can set the threshold by which the, the, the, the source code moves through the SDLC. Everybody will. Yep. Exactly. And, and, but we're, we have to, we have to practice that too, because that's a, that's a new way of, of, of the security team and the developers interacting. >>So we, we, we, we have to have patterns that that teams can then adopt procedurally because we aren't, we aren't yet accustomed to having a lot of procedures that work that way. So yeah, we, we have templates, we've got professional services that we want to help those teams get that, that equation, right? Because it it's a, it's a truly win-win situation when you can really stick the landing on getting the developers, the self-service options with the security team, having the confidence level that the controls are employed. And then on, on the network side, by the way, I, I too am mortified of breaking infrastructure and, and which is exactly why, you know, what, what we do architecturally out of band is, is really a, a game changer because there are technologies we can put in, in line, there are disruptors and operational risks that we can incur when we are, where we utilizing a technology that, that can break things, can break business, critical traffic. >>So what we do is we lean into the, the, the sort of the network nodes and the, and the hosts that the organization already has identifying those APIs, creating the behavioral models that really identify misuse in progress, and then automate, blocking, but doing that out of, out of band, that's really important. That's how I feel about our infrastructure. I, I don't want sort of unintended disruption. I want, I want to utilize a platform that's out of band that I can use. That's much more lightweight than, you know, putting another box in, in the network line. Yeah, >>What's interesting is what you're talking about is kind of the new school of thought. And the script has flipped. The old school was solve complexity with more complexity, get in the way, inject some measurements, software agents on the network, get in the way and the developer, Hey, here's a new tool. We agreed in a, in a vacuum, go do this. I think now more than ever, developers are setting the agenda on, on, on the tooling, if it's, and it has to be self-service at our super cloud event that was validated across the board. That if it's self-service, it's gotta be self-service for the developer. Otherwise they won't use it pretty much. >>Oh, well, I couldn't agree more. And the other part too, is like, no matter what business we're in the security business is, is yeah, it has to honor like the, the, the business need for innovation. We have to honor the business need for, for, for speed. And we have to do our best to, to, to empower the, the sort of the strategy and empower the intent that the developers are, are delivering on. And yes, we need to be, we need to be seeking every opportunity to, to lift that developer up and, and give them the tools sort of in the moment we wanna wrap the developer in armor, not wake them down with an anchor. And that's the, that's the thing that we, we want to keep striving towards is, is making that possible for the security team. >>So you guys are very relevant right now. APIs are the favorite environment for hackers was seeing that with breaches and in the headlines every day, I love this comprehensive approach, developer focused op security team enablement, operationally relevant to all, all, all parties. I have to ask you, how do you answer and, and talk about the competition, cuz with the rise of this trend, a lot of more people entering this market, how should a customer decide between no name and everyone else pitch in API security? What's the, is there nuances? Is there differences? How do you compare what's the differentiation? >>Yeah, I think, you know, the, the, the first thing to mention is that, you know, companies that are in the space of API security, we, we have a lot more in common. We probably have differences cause we're focused on the same problems, but there's, there's really two changes that we've made bringing to market an API platform. Number one is to look full lifecycle. So it used to be that you could buy, you know, DAST and SAS software testing tools, no name has API testing in, so, you know, for source code and for pipeline integrations along with then the runtime and posture management, which is really the production network. And so we really do think that we span east west a much broader set of controls for the API. And then the second characteristic is, is architectural fit. Particularly in a runtime production environment, you have to have a solution that does, does not create significant disruptions. >>It doesn't require agent deployment that can maximize the, the, the infrastructure that an organization already has. So we think our, you know, a big advantage for us in, in the production environment is that we can, we can adapt to the contour of the customer. We don't have to have the customer adapt to the contour of our architecture. So that flexibility really serves well, particularly with complex organizations, global organizations or those that have on, you know, data centers and, and, and public cloud and, and multiple varieties. So our ability to sort of adapt to a customer's architecture really makes us sort of like a universal tool for organizations. And we think that's really, you know, bears out in the, in the customers, in the large organizations and enterprises that have adapted us because we can adapt really any condition. >>Yeah. And that's great alignment too, from an execution consumption standpoint, it's gotta be fast with a developer. You gotta be frictionless as much as possible. Good stuff there. I have to ask you Carl, as, as you are a CISO chief information security officer, you know, your peers are out there. They're they're, they got, man there's so much going on around them. They gotta manage the current, protect the future and architect, the next level infrastructure for security. What do you, what do you see out there as a CSO with your peers in the marketplace? You know, practitioners, you know, evaluating companies, evaluating technologies, managing the threat landscape, unlimited surface area, evolving with the edge coming online, what's on their mind. How do you see it? What's your, what's your view there? What's your vision if you were, if you were in the hot seat in a big organization, I mean, obviously you're got a hot seat there with no name, but you're also, you know, you're seeing both sides of the coin at no name, you know, the CISO. So are they the frog and boiling water right now? Or like, like what's going on in their world right now? How would you describe the state of, of the CISO in cyber security? >>Yeah, there's, there's, there's two kind of tactical themes. I think almost every CISO shares the, the, the, the, the first tactical theme is, is I as a CISO. I probably know there's a technology out there to solve a little bit of every problem possible. Like, that's you objectively true. But what I don't wanna do is I don't wanna buy 75 technologies when I could buy 20 platforms or 12 that could solve that problem set. So the first thing I wanna do is as I, I want to communicate what we do from the perspective of, of like a single platform that does multiple things from source code testing, to posture and configuration to runtime defense, because I, a CISO's sensibilities is, is, is, is challenged by having 15 technologies. I really just want a couple to manage because it's complexity that we're managing when we're managing all these technologies. >>Even if something works for a point problem set, I, I don't want another technology to implement and manage. That's, that's just throwing money. Oftentimes at, at suboptimal, you know, we're not getting the results when we just throw tools at a problem. So the, that that platform concept is I think really appealing cuz every CSO is looking to consider, how do I reduce the number of technologies that I have? The second thing is every organization faces the challenge of talent. So what are, what are my options for talent, for mitigating? What is sort of, I, I can't hire enough qualified people at a remotely reasonable price to staff, what I'd like to. So I have to pursue both the utilizing third parties who have expertise in professional services that I can deploy to, to, to, to solve my problems, but also then to employing automation. So, you know, the, a great example would be if I have a team that has a, you know, a five person application security team, and now next year, my applications security or my, my applications team is gonna develop three times the number of, of applications and APIs. >>I can't scale my team by a factor of three, just to meet that demand. I have to pursue automation opportunities. And so we really want to measure the, the, the successes that we can achieve with automation so that a CISO can look at us as, as an answer to complexity rather than as a source of new complexity, because it is true that we're overwhelmed with the options at our disposal. Most of those options create more complexity than they solve for. And, and, you know, I pursue that in, in my practice, which is to, is to figure out how to sort of limit the complexity of what is already very complicated, you know, role and protecting an organization. >>Got it. And when you, when, when the CSO says Carl, what's in it for me with no name, what's the answer, what's the bumper bumper sticker. >>It, it's reducing complexity. It's making a very sophisticated problem. Set, simple to solve for APIs are a, are a class of assets that there's an answer for that answer includes automation and includes professional services. And we can, we can achieve a high degree of sophistication relatively speaking with a low amount of effort. When we look across our security team, this is a, this is a solvable problem space and, and we can do so pretty efficiently. >>Awesome. Well call, thank you so much for showcasing no name. And the last minute we have here, give a quick plug for the company, give a little stats, some factoids that people might be interested in. How big is the company? What are you guys doing enthusiastic about the solution? Share some, yep. Give the plug. >>Sure. We're, we're, we're a company of just about 300 employees now all across the globe, Asia Pacific, north America, Europe, and the middle east, you know, tremendous success with the release of our, of our software testing module, which we call active testing. We have such a variety of ways also to, to sort of test and take Nona for a test drive from sandboxes to POVs and, and some really amazing opportunities to, to show and tell and have the organizations diagnose quickly where, where they are. And so we, we love to, we love to, to, to show off the platform and, and let people take it for a test drive. So, you know, no name, security.com and any, anywhere in the world, you are, we can, we can deploy a, a, a sales engineer who can help show you the platform and, and show you all the things that, that we can, we can offer for the organization. >>Carl, great insight. Thank you again for sharing the stats and talk about the industry and really showcasing some of the key things you guys are doing in the industry for customers. We really appreciate it. Thanks for coming on. >>Thanks John. Appreciate it. >>Okay. That's the, this is the ADBU startup showcase. John fur, your host season two, episode four of this ongoing series covering the exciting new growing startups from the AWS ecosystem in cybersecurity. Thanks for watching.

>>Hello, Ron. Welcome to AWS reinforce here. Live in Boston, Massachusetts. I'm John feer, host of the cube. We're here at Carl Matson. CSO at no name security. That's right, no name security, no name securities, also a featured partner at season two, episode four of our upcoming eightish startup showcase security themed event happening in the end of August. Look for that at this URL, AWS startups.com, but we're here at reinforc Carl. Thanks for joining me today. Good to see >>You. Thank you for having us, John. >>So this show security, it's not as packed as the eight of us summit was in New York. That just happened two weeks ago, 19,000 people here, more focused crowd. Lot at stake operations are under pressure. The security teams are under a lot of pressure as apps drive more and more cloud native goodness. As we say, the gen outta the bottle, people want more cloud native apps. Absolutely. That's put a lot of pressure on the ops teams and the security teams. That's the core theme here. How do you see it happening? How do you see this unfolding? Do you agree with that? And how would you describe today's event? >>Well, I think you're, you're spot on. I think the, the future of it is increasingly becoming the story of developers and APIs becoming the hero, the hero of digital transformation, the hero of public cloud adoption. And so this is really becoming much more of a developer-centric discussion about where we're moving our applications and, and where they're hosted, but also how they're designed. And so there's a lot of energy around that right now around focusing security capabilities that really appeal to the sensibilities and the needs of, of modern applications. >>I want to get to know name security a second, and let you explain what you guys do. Then I'll have a few good questions for you to kind of unpack that. But the thing about the structural change that's happened with cloud computing is kind of, and kind of in the past now, DevOps cloud scale, large scale data, the rise of the super cloud companies like snowflake capital, one there's examples of companies that don't even have CapEx investments building on the cloud. And in a way, our, the success of DevOps has created another sea of problems and opportunities that is more complexity as the benefits of DevOps and open source, continue to rise, agile applications that have value can be quantified. There's no doubt with the pandemic that's value there. Yeah. Now you have the collateral damage of success, a new opportunity to abstract away, more complexity to go to the next level. Yep. This is a big industry thing. What are the key opportunities and areas as this new environment, cuz that's the structural change happening now? Yep. What's the key dynamics right now. That's driving this new innovation and what are some of those problem areas that are gonna be abstracted away that you see? >>Well, the, the first thing I I'd suggest is is to, to lean into those structural changes and take advantage of them where they become an advantage for governance, security risk. A perfect example is automation. So what we have in microservices, applications and cloud infrastructures and new workloads like snowflake is we have workloads that want to talk, they want to be interoperated with. And because of that, we can develop new capabilities that take advantage of those of those capabilities. And, and so we want to have on our, on our security teams in particular is we wanna have the talent and the tools that are leaning into and capitalizing on exactly those strengths of, of the underlying capabilities that you're securing rather than to counter that trend, that the, the security professional needs to get ahead of it and, and be a part of that discussion with the developers and the infrastructure teams. >>And, and again, the tructure exchange could kill you too as well. I mean, some benefits, you know, data's the new oil, but end of the day it could be a problematic thing. Sure. All right. So let's get that. No names talk about the company. What you guys do, you have an interesting approach, heavily funded, good success, good buzz. What's going on with the company? Give the quick overview. >>Well, we're a company that's just under three years old and, and what APIs go back, of course, a, a decade or more. We've all been using APIs for a long time, but what's really shifted over the last couple of years is the, is the transition of, of applications and especially business critical processes to now writing on top of public facing APIs where API used to be the behind the scenes interconnection between systems. Now those APIs are exposed to their public facing. And so what we focus on as a company is looking at that API as a, as a software endpoint, just like any other endpoint in our environments that we're historically used to. That's an endpoint that needs full life cycle protection. It needs to be designed well secure coding standards for, for APIs and tested. Well, it also has to be deployed into production configured well and operated well. And when there's a misuse or an attack in progress, we have to be able to protect and identify the, the risks to that API in production. So when you add that up, we're looking at a full life cycle view of the API, and it's really it's about time because the API is not new yet. We're just starting to now to apply like actual discipline and, and practices that help keep that API secure. >>Yeah. It's interesting. It's like what I was saying earlier. They're not going anywhere. They're not going, they're the underpinning, the underlying benefit of cloud yes. Cloud native. So it's just more, more operational stability, scale growth. What are some of the challenges that, that are there and what do you guys do particularly to solve it? You're protecting it. Are you scaling it? What specifically are you guys addressing? >>But sure. So I think API security, even as a, as a discipline is not new, but I think the, the, the traditional look at API security looks only at, at the quality of the source code. Certainly quality of the source code of API is, is sort of step one. But what we see in, in practices is most of the publicly known API compromises, they weren't because of bad source code that they because of network misconfiguration or the misapplication of policy during runtime. So a great example of that would be developer designs, an API designs. It in such a way that Gar that, that enforces authentication to be well designed and strong. And then in production, those authentication policies are not applied at a gateway. So what we add to the, we add to the, to the conversation on API security is helping fill all those little gaps from design and testing through production. So we can see all of the moving parts in the, the context of the API to see how it can be exploited and, and how we can reduce risk in independent of. >>So this is really about hardening the infrastructure yep. Around cuz the developer did their job in that example. Yep. So academic API is well formed working, but something didn't happen on the network or gateway box or app, you know, some sort of network configuration or middleware configuration. >>Absolutely. So in our, in our platform, we, we essentially have sort of three functional areas. There's API code testing, and then we call next is posture management posture. Management's a real thing. If we're talking about a laptop we're talking about, is it up to date with patches? Is it configured? Well, is it secure network connectivity? The same is true with APIs. They have to be managed and cared for by somebody who's looking at their posture on the network. And then of course then there's threat defense and run time protection. So that posture management piece, that's really a new entrant into the discussion on API security. And that's really where we started as a company is focusing on that sort of acute gap of information, >>Posture, protection, >>Posture, and protection. Absolutely >>Define that. What does that, what does posture posture protection mean? How would you define that? >>Sure. I think it's a, it's identifying the inherent risk exposure of an API. Great example of that would be an API that is addressable by internal systems and external systems at the same time. Almost always. That is, that is an error. It's a mistake that's been made so well by, by identifying that misconfiguration of posture, then we can, we can protect that API by restricting the internet connectivity externally. That's just a great example of posture. We see almost every organization has that and it's never intended. >>Great, great, great call out. Thanks for sharing. All right, so I'm a customer. Yep. Okay. Look at, Hey, I already got an app firewall API gateway. Why do I need another tool? >>Well, first of all, web application firewalls are sort of essential parts of a security ecosystem. An API management gateway is usually the brain of an API economy. What we do is we, we augment those platforms with what they don't do well and also when they're not used. So for example, in, in any environment, we, we aspire to have all of our applications or APIs protected by web application firewall. First question is, are they even behind the web? Are they behind the w at all? We're gonna find that the WAFF doesn't know if it's not protecting something. And then secondary, there are attack types of business logic in particular of like authentication policy that a WAFF is not gonna be able to see. So the WAFF and the API management plan, those are the key control points and we can help make those better. >>You know what I think is cool, Carl, as you're bringing up a point that we're seeing here and we've seen before, but now it's kind of coming at the visibility. And it was mentioned in the keynote by one of the presenters, Kurt, I think it was who runs the platform. This idea of reasoning is coming into security. So the idea of knowing the topology know that there's dynamic stuff going on. I mean, topes aren't static anymore. Yep. And now you have more microservices. Yep. More APIs being turned on and off this runtime is interesting. So you starting to see this holistic view of, Hey, the secret sauce is you gotta be smarter. Yep. And that's either machine learning or AI. So, so how does that relate to what you guys do? Does it, cuz it sounds like you've got something of that going on with the product. Is that fair or yeah. >>Yeah, absolutely. So we, yeah, we talked about posture, so that's, that's really the inherent quality or secure posture of a, of an API. And now let's talk about sending traffic through that API, the request and response. When we're talking about organizations that have more APIs than they have people, employees, or, or tens of thousands, we're seeing in some customers, the only way to identify anomalous traffic is through machine learning. So we apply a machine learning model to each and every API in independently for itself because we wanna learn how that API is supposed to be behave. Where is it supposed to be talking? What kind of data is it supposed to be trafficking in, in, in all its facets. So we can model that activity and then identify the anomaly where there's a misuse, there's an attacker event. There's an, an insider employee is doing something with that API that's different. And that's really key with APIs is, is that no, a no two APIs are alike. Yeah. They really do have to be modeled individually rather than I can't share my, my threat signatures for my API, with your organization, cuz your APIs are different. And so we have to have that machine learning approach in order to really identify that >>Anomaly and watch the credentials, permissions. Absolutely all those things. All right. Take me through the life cycle of an API. There's pre-production postproduction what do I need to know about those two, those two areas with respect to what you guys do? >>Sure. So the pre-production activities are really putting in the hands of a developer or an APSEC team. The ability to test that API during its development and, and source code testing is one piece, but also in pre-production are we modeling production variables enough to know what's gonna happen when I move it into production? So it's one thing to have secure source code, of course, but then it's also, do we know how that API's gonna interact with the world once it's sort of set free? So the testing capabilities early life cycle is really how we de-risk in the long term, but we all have API ecosystems that are existing. And so in production we're applying the, all of those same testing of posture and configuration issues in runtime, but really what it, it may sound cliche to say, we wanna shift security left, but in APIs that's, that's a hundred percent true. We want to keep moving our, our issue detection to the earliest possible point in the development of an API. And that gives us the greatest return in the API, which is what we're all looking for is to capitalize on it as an agent of transformation. >>All right, let's take the customer perspective. I'm the customer, Carl, Carl, why do I need you? And how are you different from the competition? And if I like it, how do I get started? >>Sure. So the, the, the first thing that we differentiate selves from the customer is, or from our competitors is really looking at the API as an entire life cycle of activities. So whether it's from the documentation and the design and the secure source code testing that we can provide, you know, pre-development, or pre-deployment through production posture, through runtime, the differentiator really for us is being a one-stop shop for an entire API security program. And that's very important. And as that one stop shop, the, the great thing about that when having a conversation with a customer is not every customer's at the same point in their journey. And so if, if a customer discussion really focuses on their perhaps lack of confidence in their code testing, maybe somebody else has a lack of confidence in their runtime detection. We can say yes to those conversations, deliver value, and then consider other things that we can do with that customer along a whole continuum of life cycle. And so it allows us to have a customer conversation where we don't need to say, no, we don't do that. If it's an API, the answer is, yes, we do do that. And that's really where we, you know, we have an advantage, I think, in, in looking at this space and, and, and being able to talk with pretty much any customer in any vertical and having a, having a solution that, that gives them something value right away. >>And how do I get started? I like it. You sold me on, on operationalizing it. I like the one stop shop. I, my APIs are super important. I know that could be potential exposure, maybe access, and then lateral movement to a workload, all kinds of stuff could happen. Sure. How do I get started? What do I do to solve >>This? Well, no name, security.com. Of course we, we have, you know, most customers do sandboxing POVs as part of a trial period for us, especially with, you know, being here at AWS is wonderful because these are customers who's with whom we can integrate with. In a matter of minutes, we're talking about literally updating an IAM role. Permission is the complexity of implementation because cloud friendly workloads really allow us to, to do proofs of concept and value in a matter of minutes to, to achieve that value. So whether it's a, a dedicated sandbox for one customer, whether it's a full blown POC for a complicated organization, you know, whether it's here at AWS conference or, or, or Nona security.com, we would love to do a, do a, like a free demo test drive and assessment. >>Awesome. And now you guys are part of the elite alumni of our startup showcase yep. Where we feature the hot startups, obviously it's the security focuses episodes about security. You guys have been recognized by the industry and AWS as, you know, making it, making it happen. What specifically is your relationship with AWS? Are you guys doing stuff together? Cuz they're, they're clearly integrating with their partners. Yeah. I mean, they're going to companies and saying, Hey, you know what, the more we're integrated, the better security everyone gets, what are you doing with Amazon? Can you share any tidbits? You don't have to share any confidential information, but can you give us a little taste of the relationship? >>Well, so I think we have the best case scenario with our relationship with AWSs is, is as a, as a very, very small company. Most of our first customers were AWS customers. And so to develop the, the, the initial integrations with AWS, what we were able to do is have our customers, oftentimes, which are large public corporations, go to AWS and say, we need, we need that company to be through your marketplace. We need you to be a partner. And so that partnership with, with AWS has really grown from, you know, gone from zero to 60 to, you know, miles per hour in a very short period of time. And now being part of the startup program, we have a variety of ways that a customer can, can work with us from a direct purchase through the APS marketplace, through channel partners and, and VA, we really have that footprint now in AWS because our customers are there and, and they brought our customers to AWS with us. >>It's it nice. The customers pulls you to AWS. Yes. Its pulls you more customers. Yep. You get kind of intermingled there, provide the value. And certainly they got, they, they hyperscale so >>Well, that creates depth of the relationship. So for example, as AWS itself is evolving and changing new services become available. We are a part of that inner circle. So to speak, to know that we can make sure that our technology is sort of calibrated in advance of that service offering, going out to the rest of the world. And so it's a really great vantage point to be in as a startup. >>Well, Carl, the CISO for no name security, you're here on the ground. You partner with AWS. What do you think of the show this year? What's the theme. What's the top story one or two stories that you think of the most important stories that people should know about happening here in the security world? >>Well, I don't think it's any surprise that almost every booth in the, in the exhibit hall has the words cloud native associated with it. But I also think that's, that's, that's the best thing about it, which is we're seeing companies and, and I think no name is, is a part of that trend who have designed capabilities and technologies to take advantage and lean into what the cloud has to offer rather than compensating. For example, five years ago, when we were all maybe wondering, will the cloud ever be as secure as my own data center, those days are over. And we now have companies that have built highly sophisticated capabilities here in the exhibit hall that are remarkably better improvements in, in securing the cloud applications in, in our environments. So it's a, it's a real win for the cloud. It's something of a victory lap. If, if you hadn't already been there, you should be there at this point. >>Yeah. And the structural change is happening now that's clear and I'd love to get your reaction if you agree with it, is that the ops on security teams are now being pulled up to the level that the developers are succeeding at, meaning that they have to be in the boat together. Yes. >>Oh, lines of, of reporting responsibility are becoming less and less meaningful and that's a good thing. So we're having just in many conversations with developers or API management center of excellence teams to cloud infrastructure teams as we are security teams. And that's a good thing because we're finally starting to have some degree of conversions around where our interests lie in securing cloud assets. >>So developers ops security all in the boat together, sync absolutely together or win together. >>We, we, we win together, but we don't win on day one. We have to practice like we as organizations we have to, we have to rethink our, we have to rethink our tech stack. Yeah. But we also have to, you have to rethink our organizational models, our processes to get there, to get >>That in, keep the straining boat in low waters. Carl, thanks for coming on. No name security. Why the name just curious, no name. I love that name. Cause the restaurant here in Boston that used to be of all the people that know that. No name security, why no name? >>Well, it was sort of accidental at, in the, in the company's first few weeks, the there's an advisory board of CISOs who provides feedback on, on seed to seed companies on their, on their concept of, of where they're gonna build platforms. And, and so in absence of a name, the founders and the original investor filled out a form, putting no name as the name of this company that was about to develop an API security solution. Well, amongst this board of CSOs, basically there was unanimous feedback that the, what they needed to do was keep the name. If nothing else, keep the name, no name, it's a brilliant name. And that was very much accidental, really just a circumstance of not having picked one, but you know, a few weeks passed and all of a sudden they were locked in because sort of by popular vote, no name was, >>Was formed. Yeah. And now the legacy, the origination story is now known here on the cube call. Thanks for coming on. Really appreciate it. Thank you, John. Okay. We're here. Live on the floor show floor of AWS reinforced in Boston, Massachusetts. I'm John with Dave ALO. Who's out and about getting the stories in the trenches in the analyst meeting. He'll be right back with me shortly day tuned for more cube coverage. After this short break.

>>We'll come back to the cubes coverage of AWS reinvent 2021, the industry's most important hybrid event. Very few hybrid events, of course, in the last two years. And the cube is excited to be here. Uh, this is our ninth year covering AWS reinvent this the 10th reinvent we're here with Joel Minnick, who the vice president of product and partner marketing at smoking hot company, Databricks and Greg Rokita, who is executive director of technology at Edmonds. If you're buying a car or leasing a car, you gotta go to Edmund's. We're gonna talk about busting data silos, guys. Great to see you again. >>Welcome. Welcome. Glad to be here. >>All right. So Joel, what the heck is a lake house? This is all over the place. Everybody's talking about lake house. What is it? >>And it did well in a nutshell, a Lakehouse is the ability to have one unified platform to handle all of your traditional analytics workloads. So your BI and reporting Trisha, the lake, the workloads that you would have for your data warehouse on the same platform as the workloads that you would have for data science and machine learning. And so if you think about kind of the way that, uh, most organizations have built their infrastructure in the cloud today, what we have is generally customers will land all their data in a data lake and a data lake is fantastic because it's low cost, it's open. It's able to handle lots of different kinds of data. Um, but the challenges that data lakes have is that they don't necessarily scale very well. It's very hard to govern data in a data lake house. It's very hard to manage that data in a data lake, sorry, in a, in a data lake. >>And so what happens is that customers then move the data out of a data lake into downstream systems and what they tend to move it into our data warehouses to handle those traditional reporting kinds of workloads that they have. And they do that because data warehouses are really great at being able to have really great scale, have really great performance. The challenge though, is that data warehouses really only work for structured data. And regardless of what kind of data warehouse you adopt, all data warehouse and platforms today are built on some kind of proprietary format. So once you've put that data into the data warehouse, that's, that is kind of what you're locked into. The promise of the data lake house was to say, look, what if we could strip away all of that complexity and having to move data back and forth between all these different systems and keep the data exactly where it is today and where it is today is in the data lake. >>And then being able to apply a transaction layer on top of that. And the Databricks case, we do that through a technology and open source technology called data lake, or sorry, Delta lake. And what Delta lake allows us to do is when you need it, apply that performance, that reliability, that quality, that scale that you would expect out of a data warehouse directly on your data lake. And if I can do that, then what I'm able to do now is operate from one single source of truth that handles all of my analytics workloads, both my traditional analytics workloads and my data science and machine learning workloads, and being able to have all of those workloads on one common platform. It means that now not only do I get much, much more simple in the way that my infrastructure works and therefore able to operate at much lower costs, able to get things to production much, much faster. >>Um, but I'm also able to now to leverage open source in a much bigger way being that lake house is inherently built on an open platform. Okay. So I'm no longer locked into any kind of data format. And finally, probably one of the most, uh, lasting benefits of a lake house is that all the roles that have to take that have to touch my data for my data engineers, to my data analyst, my data scientists, they're all working on the same data, which means that collaboration that has to happen to go answer really hard problems with data. I'm now able to do much, much more easy because those silos that traditionally exist inside of my environment no longer have to be there. And so Lakehouse is that is the promise to have one single source of truth, one unified platform for all of my data. Okay, >>Great. Thank you for that very cogent description of what a lake house is now. Let's I want to hear from the customer to see, okay, this is what he just said. True. So actually, let me ask you this, Greg, because the other problem that you, you didn't mention about the data lake is that with no schema on, right, it gets messy and Databricks, I think, correct me if I'm wrong, has begun to solve that problem, right? Through series of tooling and AI. That's what Delta liked us. It's a man, like it's a managed service. Everybody thought you were going to be like the cloud era of spark and Brittany Britain, a brilliant move to create a managed service. And it's worked great. Now everybody has a managed service, but so can you paint a picture at Edmonds as to what you're doing with, maybe take us through your journey the early days of a dupe, a data lake. Oh, that sounds good. Throw it in there, paint a picture as to how you guys are using data and then tie it into what y'all just said. >>As Joel said, that they'll the, it simplifies the architecture quite a bit. Um, in a modern enterprise, you have to deal with a variety of different data sources, structured semi-structured and unstructured in the form of images and videos. And with Delta lake and built a lake, you can have one system that handles all those data sources. So what that does is that basically removes the issue of multiple systems that you have to administer. It lowers the cost, and it provides consistency. If you have multiple systems that deal with data, you always arise as the issue as to which data has to be loaded into which system. And then you have issues with consistency. Once you have issues with consistency, business users, as analysts will stop trusting your data. So that was very critical for us to unify the system of data handling in the one place. >>Additionally, you have a massive scalability. So, um, I went to the talk with from apple saying that, you know, he can process two years worth of data. Instead of just two days in an Edmonds, we have this use case of backfilling the data. So often we changed the logic and went to new. We need to reprocess massive amounts of data with the lake house. We can reprocess months worth of data in, in a matter of minutes or hours. And additionally at the data lake houses based on open, uh, open standards, like parquet that allowed us, allowed us to basically hope open source and third-party tools on top of the Delta lake house. Um, for example, a Mattson, we use a Matson for data discovery, and finally, uh, the lake house approach allows us for different skillsets of people to work on the same source data. We have analysts, we have, uh, data engineers, we have statisticians and data scientists using their own programming languages, but working on the same core of data sets without worrying about duplicating data and consistency issues between the teams. >>So what, what is, what are the primary use cases where you're using house Lakehouse Delta? >>So, um, we work, uh, we have several use cases, one of them more interesting and important use cases as vehicle pricing, you have used the Edmonds. So, you know, you go to our website and you use it to research vehicles, but it turns out that pricing and knowing whether you're getting a good or bad deal is critical for our, uh, for our business. So with the lake house, we were able to develop a data pipeline that ingests the transactions, curates the transactions, cleans them, and then feeds that curated a curated feed into the machine learning model that is also deployed on the lake house. So you have one system that handles this huge complexity. And, um, as you know, it's very hard to find unicorns that know all those technologies, but because we have flexibility of using Scala, Java, uh, Python and SQL, we have different people working on different parts of that pipeline on the same system and on the same data. So, um, having Lakehouse really enabled us to be very agile and allowed us to deploy new sources easily when we, when they arrived and fine tune the model to decrease the error rates for the price prediction. So that process is ongoing and it's, it's a very agile process that kind of takes advantage of the, of the different skill sets of different people on one system. >>Because you know, you guys democratized by car buying, well, at least the data around car buying because as a consumer now, you know, I know what they're paying and I can go in of course, but they changed their algorithms as well. I mean, the, the dealers got really smart and then they got kickbacks from the manufacturer. So you had to get smarter. So it's, it's, it's a moving target, I guess. >>Great. The pricing is actually very complex. Like I, I don't have time to explain it to you, but knowing, especially in this crazy market inflationary market where used car prices are like 38% higher year over year, and new car prices are like 10% higher and they're changing rapidly. So having very responsive pricing model is, is extremely critical. Uh, you, I don't know if you're familiar with Zillow. I mean, they almost went out of business because they mispriced their, uh, their houses. So, so if you own their stock, you probably under shorthand of it, but, you know, >>No, but it's true because I, my lease came up in the middle of the pandemic and I went to Edmonds, say, what's this car worth? It was worth like $7,000. More than that. Then the buyout costs the residual value. I said, I'm taking it, can't pass up that deal. And so you have to be flexible. You're saying the premises though, that open source technology and Delta lake and lake house enabled that flexible. >>Yes, we are able to ingest new transactions daily recalculate our model within less than an hour and deploy the new model with new pricing, you know, almost real time. So, uh, in this environment, it's very critical that you kind of keep up to date and ingest their latest transactions as they prices change and recalculate your model that predicts the future prices. >>Because the business lines inside of Edmond interact with the data teams, you mentioned data engineers, data scientists, analysts, how do the business people get access to their data? >>Originally, we only had a core team that was using Lakehouse, but because the usage was so powerful and easy, we were able to democratize it across our units. So other teams within software engineering picked it up and then analysts picked it up. And then even business users started using the dashboarding and seeing, you know, how the price has changed over time and seeing other, other metrics within the, >>What did that do for data quality? Because I feel like if I'm a business person, I might have context of the data that an analyst might not have. If they're part of a team that's servicing all these lines of business, did you find that the data quality, the collaboration affected data? >>Th the biggest thing for us was the fact that we don't have multiple systems now. So you don't have to load the data. Whenever you have to load the data from one system to another, there is always a lag. There's always a delay. There is always a problematic job that didn't do the copy correctly. And the quality is uncertain. You don't know which system tells you the truth. Now we just have one layer of data. Whether you do reports, whether you're data processing or whether you do modeling, they all read the same data. And the second thing is that with the dashboarding capabilities, people that were not very technical that before we could only use Tableau and Tableau is not the easiest thing to use as if you're not technical. Now they can use it. So anyone can see how our pricing data looks, whether you're an executive, whether you're an analyst or a casual business users, >>But Hey, so many questions, you guys are gonna have to combat. I'm gonna run out of time, but you now allow a consumer to buy a car directly. Yes. Right? So that's a new service that you launched. I presume that required new data. We give, we >>Give consumers offers. Yes. And, and that offer you >>Offered to buy my league. >>Exactly. And that offer leverages the pricing that we develop on top of the lake house. So the most important thing is accurately giving you a very good offer price, right? So if we give you a price, that's not so good. You're going to go somewhere else. If we give you price, that's too high, we're going to go bankrupt like Zillow debt, right. >>It took to enable that you're working off the same dataset. Yes. You're going to have to spin up a, did you have to inject new data? Was there a new data source that we're working on? >>Once we curate the data sources and once we clean it, we see the directly to the model. And all of those components are running on the lake house, whether you're curating the data, cleaning it or running the model. The nice thing about lake house is that machine learning is the first class citizen. If you use something like snowflake, I'm not going to slam snowflake here, but you >>Have two different use case. You have >>To, you have to load it into a different system later. You have to load it into a different system. So like good luck doing machine learning on snowflake. Right. >>Whereas, whereas Databricks, that's kind of your raison d'etre >>So what are your, your, your data engineer? I feel like I should be a salesman or something. Yeah. I'm not, I'm not saying that. Just, just because, you know, I was told to, like, I'm saying it because of that's our use case, >>Your use case. So question for each of you, what, what business results did you see when you went to kind of pre lake house, post lake house? What are the, any metrics you can share? And then I wonder, Joel, if you could share a sort of broader what you're seeing across your customer base, but Greg, what can you tell us? Well, >>Uh, before their lake house, we had two different systems. We had one for processing, which was still data breaks. And the second one for serving and we iterated over Nateeza or Redshift, but we figured that maintaining two different system and loading data from one to the other was a huge overhead administration security costs. Um, the fact that you had to consistency issues. So the fact that you can have one system, um, with, uh, centralized data, solves all those issues. You have to have one security mechanism, one administrative mechanism, and you don't have to load the data from one system to the other. You don't have to make compromises. >>It's scale is not a problem because of the cloud, >>Because you can spend clusters at will for different use cases. So your clusters are independent. You have processing clusters that are not affecting your serving clusters. So, um, in the past, if you were running a serving, say on Nateeza or Redshift, if you were doing heavy processing, your reports would be affected, but now all those clusters are separated. So >>Consumer data consumer can take that data from the producer independ >>Using its own cluster. Okay. >>Yeah. I'll give you the final word, Joel. I know it's been, I said, you guys got to come back. This is what have you seen broadly? >>Yeah. Well, I mean, I think Greg's point about scale. It's an interesting one. So if you look at cross the entire Databricks platform, the platform is launching 9 million VMs every day. Um, and we're in total processing over nine exabytes a month. So in terms of just how much data the platform is able to flow through it, uh, and still maintain a extremely high performance is, is bar none out there. And then in terms of, if you look at just kind of the macro environment of what's happening out there, you know, I think what's been most exciting to watch or what customers are experiencing traditionally or, uh, on the traditional data warehouse and kinds of workloads, because I think that's where the promise of lake house really comes into its own is saying, yes, I can run these traditional data warehousing workloads that require a high concurrency high scale, high performance directly on my data lake. >>And, uh, I think probably the two most salient data points to raise up there is, uh, just last month, Databricks announced it's set the world record for the, for the, uh, TPC D S 100 terabyte benchmark. So that is a place where Databricks at the lake house architecture, that benchmark is built to measure data warehouse performance and the lake house beat data warehouse and sat their own game in terms of overall performance. And then what's that spends from a price performance standpoint, it's customers on Databricks right now are able to enjoy that level of performance at 12 X better price performance than what cloud data warehouses provide. So not only are we jumping on this extremely high scale and performance, but we're able to do it much, much more efficiently. >>We're gonna need a whole nother section second segment to talk about benchmarking that guys. Thanks so much, really interesting session and thank you and best of luck to both join the show. Thank you for having us. Very welcome. Okay. Keep it right there. Everybody you're watching the cube, the leader in high-tech coverage at AWS reinvent 2021