>>mhm. Hello and welcome to the cubes Ducker con coverage. I'm John Ferry, host of the Cube. We've got a great segment here with slim dot AI CEO John Amaral. Stealth mode, SAS Company. Start up in the devops space with tools today and open source around. Supply chain security with containers closed beta with developers. John, Thanks for coming on. Congratulations for being platinum sponsor here, Dr Khan. Thanks for coming on The Cube. >>Thanks so much on my pleasure. >>You know, container analysis, management optimisation. You know, that's super important. But security is at the centre of all the action we're seeing with containers. We've been talking shift left on a lot of cube conversations. What that means? Is it an outcome? Is that the product software supply chain? You seek them? A secure where malware. All these things are part of now the new normal in cloud Native. You guys at the centre of this, the surface areas change. All these things are important. Take a minute to explain what you guys are doing as a as a tools and open source. Some of the things you're doing, I know you got a stealth mode product. You probably can't talk about. But you gotta close, Beta. Can you give us a little bit of a teaser? What slim dot ai about >>sure. So someday I is about helping developers build secure containers fast, and that really plays to a few trends in the marketplace that are really apparent and important right now in a federal mandate and a bunch of really highly publicised breaches that have all been caused by software supply, chain risks and security and software supply, chain security has become a really top of mind concept for people who secure things and people who develop software and runs. SAS so slim that AI has built a bunch of capabilities and tools that allow software developers at their desks to better understand and build secure containers that really reduce software supply. Chain risk as you think about containers being run in production. And we do three things to help developers one, as we help them know everything about their software. It's a kind of a core concept of suffering supply chain security. Just know what software is in your containers to. Another core concept is only ship to production. What you need to run. That's all about risk surface and the ability for you to easily make a container small that has as much a software reduction in it as possible. And three, it's removed as many vulnerabilities as possible to Slim Toolset. Both are open source and our SAS data platform make that easy for developers to do >>so. Basically, you have a nice, clean, secure environment. Know what's in there. Don't only put in production was needed and make sure it's tight and it's trimmed down perfectly. So you're kind of teasing out this concept of slimming, which is in the name of the company. But it really is about surface area of attack around containers and super important as it becomes more and more prominent in the environment these days. What is container slimming and why is it important for supply chain security? >>Sure. So in the in the in the realm of software supply chain security, best practises right, there are three core concepts. One is the idea of an S bahn that you should know the inventory of all the software that runs in your world to its security posture, signing containers, making sure that the authenticity of the software that you use and production is well understood. And the third is, well, managing exactly what shopper you ship. The first two things I said are simply just inventory and basics about knowing what software you have. But no one answers the question. What software do I need? So I run a container and say, It's a gig and it's got all these packages in. It comes from the operating system from note, etcetera. It's got all this stuff in it. I know the parts that I write my code to. But all that other stuff, what is it? Why is it there? What's the risk in it? That slimming part is all about managing the list of things you actually shipped to the absolute minimum and with confidence that you know that that code will actually work when it gets production but be as small as possible. That's what slimming is all about, and it really reduces supply chain risk by lowering the attack surface in your container, but also trimming your supply chain to only the minimum pieces you need, which really causes a lot of improvements in in the operational overhead of having software supply chain security >>It's interesting as you get more more volume and velocity around containers, uh, and automation kicks in. Sometimes things are turning on and off you don't even know. And shift left has been a great trend for getting in the CI CD pipeline for developer productivity. Really cool. What are some of the consequences that's going on with this? Because then you start to get into some of these areas like some stuff happens that the developers have to come shift back and can take care of stuff. So, you know, C. Tus and CSOs are really worried about this container dynamic. What's the What's the new thing that's causing the problems here? What's the issue around the management that CDOs and CDOs care about? >>Sure. And I'll talk about the shift left implications as well for that exact point. So as you start to worry about software supply, chain security and get a handle on all the software you ship to prod well, part of that is knowledge is power. But it's also, um, risk and work as soon as I know about problems with my containers or the risk surface, and I got to do something about it so we're really getting into the age where everyone has to know about the software they ship. As soon as you know about that, say there's a vulnerability or a package that's a little risky or some surface area you don't really understand. The only place that can be evaded is by going back to the developers and asking them. What is that? How do I remove it? Please do that work. So the software supply chain security knowledge turns into developer security work. Now the problem is, is that historically, the knowledge was imperfect, and the developer, you know, involvement in that was, I'd say, at Hawk, meaning that developers had best practises that did the best they could. But the scrutiny we have now on minimising this kind of risk is really high. The beautiful part about containers is their portable, and it's an easily transferrable piece of software. So you have a lot of producers and a lot of consumers of containers. Consumers of containers that care about supply chain risk are now starting to push back on, producers saying, Take those vulnerabilities out, move those packages, make this thing more secure, lower the risk profile this works its way all the way back to the developers who don't really have the tools, capabilities and automation is to do the work I just described easily, and that's an opportunity that Slim is really addressing, making it easy for developers to remove risk. >>And that's really the consequences of shifting left without having the slimming. Because what you're saying is your shift left and that's kind of annulled out because you've got to go back and fix it. The work comes, >>that's right. And yeah, and it's not an easy task for a developer to understand the code that they didn't intentionally put in the container. It's like, Okay, there's a package in that operating system. What does it do? I don't know. Do I even use it? I don't know. So there's like tonnes of analytic and I would say even optimisation questions and work to be done, but they're just not equipped to, because the tooling for that is really immature Slims on a mission to make that really easy for them and do it automatically so they don't have to think about it. We just automatically remove stuff you don't use and voila! You've got this like perfectly pre optimised capability. >>You know, this suffer supply chain is huge, and I remember when open source started when I remember when I was breaking into the business. Now it's such a height in such an escalation of new developers. This it's a real issue that that's going to be resolved. It has to be because supply chain is part of open source, right? As more code comes in, you got to verify. You gotta make sure it's it's slimming where it needs to be slim and optimised. There needs to be optimised, huge trend. Um and so I just love this area. I think it's really innovative and needed. So congratulations on that, you know, have one more question for you before we get into to close out. Um, you guys are part of the Docker Extensions launch and your partner, >>Why >>is this important to participate in this programme and and what do you guys hope to hope it does for slim dot ai, >>First of all, doctors, the ubiquitous platform, their hub has millions and millions of containers. We've got millions and millions of developers using Docker desktop to actually build and work on containers. It's like literally the sandbox for all local work for building containers. It's a fair statement. So inclusion in Dr Khan and the relationship we're building with Docker is really important for developers and that we're bringing these capabilities to the place where developers work and live every day. It's where all the containers live in the world. So we want to have our technology be easy to use with docker tools. We want to keep developers workflows and systems and and tools of record be the same. We just want to help them use those tools better and optimist outputs. From that we've we've worked since our inception to make our tools really, really friendly for darker and darker environments to, um, we are building a doctor extension. Uh, they have, uh, in this darker con. They're launching their doctor extensions programme to the worldwide audience. We have been one of the lucky Cos that's been selected to build one of the early Dr desktop plug ins. It's derived from our capabilities and our Saas platform and an open source, and it's it's effectively an MRI machine, an awesome analytic tool that allows any developer to really understand the composition, security and profile of any container they work with. So it's giving the sight to the blind, so to speak, that it's this new tool to make container analysis easy. >>Well, John, you guys got a great opportunity. Container analysis, management, optimisation key to security, enabling it and maintaining and sustaining it. And it's changing. I know you guys. Your co founder also did a doctor Slim. So you guys are deep in the open source. I Congratulations on that. We'll see a Q. Khan for the remaining time. We have give a plug for the company, obviously in stealth mode price going to come out later this year. You got a developer preview? What's What's the company all about? What's the most important story here? Dr. Khan? >>Sure, just to playback. So we help developers do three important things. Know everything about the software in their containers to only ship stuff to production that you need, and and and three remove as many vulnerabilities as possible. That's really about managing and understanding the risk surface. It ties right back to software supply chain security, and any developer can use these tools today to emit and build containers that are more secure and better production grade containers, and it's easy to do. We have an open source project called Dioxin. Go check it out. Uh, it's not. It's on git Hub. It's easy to find if you go to w w w dot slim that ai you can find access to that. We have tens of thousands of developers, 500,000 plus downloads. We have developers everywhere using those tools today and open source to do the objectives. I just said You can also easily sign up for our data for our Saas platform, you can use the doctor extension, go ahead and do that and really get on your journey to make those outcomes reality for you. And really kind of make those SEC ops people downstream not have to shift anything left. It's super easy for you to be a great participant in software slash insecurity. >>All right. John Amaral, CEO slim dot ai Stealth. Most thanks for coming The Cube Cube coverage of Dr Khan. Thanks for watching. I'm John Kerry hosted the Cube back to more Dr Khan after the short break. Mhm mhm

>> So welcome to the special. Keep conversation here in Palo Alto, California John, for a host of the Cube. We're here with two co founders. Adam Casella was the CTO and Glenn Sullivan's cofounder. Snap Route Hot Start up, guys. Welcome to this Cube conversation. Thank you. Thank you. So left on the founders in because you get the down and dirty, but you guys are launching. Interesting product is for Cloud Cloud Native Super sighting. But first, take a man to explain what is snap brought. What do you guys do? What's the main core goal of the company? >> Right? So your your audience and you familiar with white Box now working disaggregated networking, where you're buying your hardware and your software from different companies. There's a lot of different Network OS is out there, but there's nobody doing what we're doing for the now ergo es, which is a cloud native approach to that where it's a fully containerized, fully micro serviced network OS running on these white box, which is >> test your background. How did you guys start this company? Where'd you come from? What was the epiphany? Was the motivation? >> Sure. So our heritage is from operations running at some of the largest Edison is in the world. We came from Apple. Ah, and running the networks there. And the issues and problems that we saw doing that is what led us to found stabbed. >> And what are some of the things that apples you guys notice on a huge scale? Yep. I mean, Apple. You know, a huge market share most probable company. I think it's now the largest cat. Microsoft was there for a while, but and apples, the gold standard, get from privacy to scale. What were some of the things that you saw, that what was the authority? >> So, I mean, there was a couple of things going on there, one we were driving driving too, doing white box for more control. So we wanted to have a better sense of what we could do with the network operating system on those devices. And we found very quickly that the operating systems that were out there, whether they be from a traditional manufacturer Ah, we and the planes or from someone from a disaggregated marketplace were basically using the same architecture. And this was this old, monolithic single binary item that goes in the pleasant device, and you know that worked in, you know, back in the day when you know applications didn't move, they were static there, One particular location. But as we were seeing, and one things that we were really pushing on is being able to dynamically have move workloads from one location to another quickly to meet demand. The network was not able to keep up with that, and we believe that it really came down to the architecture that was there. Not being flexible enough and not allowing our control to be able to put in the principles would actually allow us to allow that that application time to service be faster. >> You know, one of these on personally fascinated, you know, seeing startups out there and living in this cloud error and watching those like Facebook and Apple, literally build the new kind of scale in real time. It's like you have, you know, changing the airplane engine out of thirty five thousand feet. As the expression goes, you have to be modern. I mean, there's money on the line that's so much scale, and when you see an inefficiency, you've got to move on it Yeah, this is like, what, you guys did it. Apple. What were some of the things that yet you observed was that the box is Was it the software? A CZ? You wanted to be more agile. What was the the problem that you saw? >> So it it's really in fragility, right? It's it's basically, this Network OS is as they were, our design in a way so that you don't touch him right. If you look at the code releases and how often they, you know, fixed security vulnerabilities or you know they have patches or even knew regular versions right there. The cycle isn't weekly. It's not daily like you see in some C I C. Environments, right? You might have a six month or a twelve month or an eighteen month cycle for doing this sort of a new release for for, you know, whatever issue new features or or fixes, right. And the problem that we would see is we would be we would be trying to test a version in the lab, right? We would be qualifying code and say there's a security vulnerability. You know, something like heart bleed, right? That comes out the guys on the server side, they push a new patch using, you know, answerable Scheffer puppet and, you know, two days later, everything's good, even two hours later in some environments. But we had to wait for the new release to come from one of the traditional vendors we had to put in our lab, and we get this sort of kitchen sink of every other fix. There'd be enhancements to be GP that we didn't ask for. There'd be enhancements to, you know, Spanish or that we didn't ask for. Even if they patched it, you'd still get this sort of all in one update. And by the time you're done qualifying, there might be another security vulnerability. So you got to start over. So you'd be in this constant cycle of months of qualified, you know, qualifying the image because you you'd be testing everything that's in the image. And not just that. The update. And that's really the key difference between what we're >> going to work involves shapes you eventually chasing your tail. Exactly. One thing comes in and opens up a lot of consequences, but that's what systems over >> all about this consequences, right? This is right systems are challenging. And what it does is it is it creates this culture and no from the network folks, right? Because the network folks are basically, like, not in my backyard. You want to add this new thing? No. Because they're judged by up time. They're judged by how long the network is up and how long the applications available. They're not judged by how quickly they can put a new feature out or how how quickly they can roll an update. Their They're literally judged in most organizations by up time. How many nines are they giving? So if I'm judged by up time and somebody wants to add something new, my first answer as a network person has anybody really is gonna be No, no, no, don't touch anything. It's it's fragile >> because they're jerks or anything. They just know the risk associate with what could come from the consequence exactly touching something. So, yes, it's hard right now to yes, Okay, so I gotta ask you guys a question. How come the networking industry hasn't solved this problem? >> Well, there's a There's a few different reasons I feel it is, and that's because we've had very tightly coupled, very tightly controlled systems that have been deployed his appliances without allowing operators to go ahead and add their innovations onto those items. So if you look at the way thie compute world is kind of moved along in the past fifteen, you know, fifty, thirty years, you mean, really a revolution started to athletics, right? From their particular perspective, you have Lennox. You can open up the system, you get people constructing open source items everyone knows just end. A story that makes the most is the most successful, monolithic, you know, piece of code base that's ever existed, right? It took fifteen years later for anyone in the network industry to even run the linens on a switch. I mean, that's that's pretty, you know, huge in my mind, right? That's that's that's called like Yeah, and so and even when they've got it on the particular switch to running older versions of Colonel, they're running different things. They don't you know, back Porter versions of code that don't work with the most modern applications that are out there, and they really have it in their tight, little walled garden that you can't adjust things with and >> that was their operational mode at the time. I mean, networks were still stable. They weren't that complicated. And hence the lag and many felt had been left >> behind. Theocracy. Inefficiencies that may have function when you have dozens of devices doesn't function when you have hundreds and thousands of devices. And so when you look at, like even from the way they they presented their operating system from a config standpoint, it is a flat config file that's loaded from filing booted. That's the same paradigm people of file for forty years. Why do we still think that hotel today compute has left that behind? They're going the programmatic AP diversions with you know whether it be you know, Cooper netease war with Doctor, where they have everything built into one ephemeral container that gets deployed. Why it hasn't been working in the same thing. And I really believe it's for that close ecosystem that hasn't allowed. People look to put their innovations onto their Yeah, it's >> almost as a demarcation point in time. You think about history and him and how we got here, where it's like, Okay, we got perimeters. We got firewalls and switches top Iraq stuff. So you got scale. It's bolted down, it's secure. And incomes Cloud comes I ot So there's almost a point, You know, it almost picked. The year was a two thousand eight doesn't through two thousand twelve. You started to see that philosophy. So the question I've asked for you is that what was the tipping point? So because, you know, the fire being lit under the butts of networking guys finally hit and someone saying, Well, they don't evolve to be like the mainframe guys. I was like, not really, because mainframes is just different from client server. Networks aren't going away there around. What's the tip was the tipping point. What made the network industry stand up? >> So yeah, what it is, is it's it's being able to buy infrastructure with a credit card, Right? Because as soon as I've got a problem as an application owner was a developer, I say, Hey, I've got this thing that I've got a release, right and I go to the network came and said, I've got this new thing and I get any sort of pushback. Now you look a cloud, right? Eight of us is our Google, like all the different options out there. Fine. I don't need these guys anymore. When the grab credit card slide it, boom. Now I can buy my infrastructure. That's that's really the shift. That's what's pushing folks away from using those kind of classic network infrastructure is because they could do something else, right? >> So cloud clearly driving it, think >> I would. I would say so. Yeah, absolutely. All >> right, So the path of solve these problems, you guys have an interesting solution. What's the path? What's the solution that you guys are bringing to market? Sure. >> So the way I had kind of view, the way the landscape is set up is really if you look at you know where this innovation has happened in the compute side in the last little bit Weatherby Cloud, whether it be, you know, some of the club native items would come out there. They've all come for the operators. I haven't been a vendor to sitting there and going to play. They've kind of mirth, morph himself into vendors. But they didn't originate as vendors, right to go and supply these systems. And so what I see from the solution to that is sort of enabling operators and people who are running networks to be ableto controller their own destiny to manage how their networks are deployed right. And this boils down from our perspective to a micro services containerized network operating system that is not be spoke, not proprietary, but is using the ecosystem has been built from this P people on the computes side specifically the cloud native universe in a cloud native world and applying those perimeters and shims onto network >> learned, learned from the cloud, Right? Like don't try to make something better. Look at the reasons why folks are going to the cloud Look at the AP structures looking. He's of launching instances. Look, att the infrastructure you build with a few clicks and say, What can I learn from that environment to Moto? Mimic that in my private environment? >> Yeah, and this is why we kinda looked at cu burnett. He's is a really big piece of our infrastructure and using the company as a p I as the main interface in tor device. So that you, Khun, you know multi different reasons, is expandable. You could do, you know, a bunch of different custom options to expand that a P i But it allows people who are either in. Deva loves to look at that and go. I understand how this works. I know how these shims function and started getting in the realization that networking is not that much different than what the computer world is. >> So you guys embraced integration, his deployment, CCD pipeline, all that good stuff. And Cooper netease even saw Apple at sea Ncf conference that they have a booth there. No one would talk, but certainly communities is getting part that cloud native. What's the important solution that you guys are building to solve to solve from the problems that you're going after with now the cloud needed because Dev ops ethos is trickling down, helping down the stack. Certainly we know what cloud is, so it's So what is specifically the problem that you solved >> So a couple things that air So obviously you have your, you know, application time of service. The faster you can double your application, the faster you can get up and running the factory. People using out it is, you know, you get more money, you save money, right? Um, you have security. No one wants to be in that that, you know, that box of having a security voluntarily happened on there, but they >> were non compliance, >> Yes, or non compliance with particular thing with a P i. P. I C P C high socks and all in all things that come along with that. And finally it's the operational efficiency of day two operations. We've gotten pretty good as industry as deploying Day one operations and walking away. We don't do anything. No, no, no. We can't change the network anymore. It's really that next day when you have to to things like apply those applications or have a new application, it gets moved. Containers are ephemeral. The average container last two to three days. Viens last twenty three days. Monolithic caps last for years. That air that are not in those things that are just compute bare metal piece. So when we start moving to a location or a journey of having a two to three day ephemeral app that can be removed or moved, replace different location. The network needs to be able to react to that, and it needs to be able to take that and ensure that that not only up time but availability is there for that, >> and it's not management tools that are going to fix it, right? This is this is sort of our core argument is that you look at all of the different solutions that have come out for the last seven, eight, nine years in the networking in the open networking space. This trying to solve this from management perspective with, you know, different esti n profiling different, different solutions for solving this management. Day two operations issues, right. And our core argument is that the management layers on top aren't what needs to change. That can change. If you adopt communities, you get that kind of along with it. But you need to change the way the network OS itself is built so that it's not so brittle so that it's not so fragile breaking into micro services, breaking the containers so that you can put it into a CCD pipeline. You try to take a monolithic network OS and put it in your C. C I. C D Pipeline. You're going to be pushing a rock up. Help. >> It's funny. We've had Scott McNealy on the Cube founder Sun Microsystems and we said, You know, he has from one time. Hey, you know what about the cloud he goes? I should I had network is the computer was his philosophies. I should should we call the cloud? So if the network is the computer kind of concept thie operating environment management's not aki sub system of the network. It's a component, but the operating system has subsystems. So I like this idea of a network, operates system talk about what you guys do with your work operating system and what is day to mean. What is actually that means >> sure. So when you take your services and you divide them up into containers and, you know, call the micro services, basically taking a single service, putting container and having a bunch of dependency that might be associate with that, what you end up doing is having your ability to, uh, you know, replace or update that particular container independently of the other components on the system. If an issue happens, or if you want to get a new feature functionally for that, the other thing you could do is you, Khun Slim, down what you're running. So you don't have to run these two hundred plus features, which is the average amount you see and just a top Iraq device. And you only use maybe ten to twenty percent of those. Why do I have all these extra features that I have to qualify that may introduce a bug into my particular environment. I want to run the very specific items that I know I need to give my application, uh, up and running and the ability to go ahead and pull in the cloud native environment and tools to do that allows you to get the efficiencies that they've learned from not only the cloud way, but also even doing some on Prem communities. You know, private cloud items to get those efficiencies on their forwarding, your network running your applications. >> It's learning from the hyper sailors to write like this. This is Well, I mean, we had this when we were running networks, right? You put every protocol on the board on a white board, and then you'd start crossing them off and you start arguing in a room full of people saying, Why do I need this feature? Why do I need this other feature and it's like you have to justify it. And we know this is happening up the road at, you know, places like Facebook because, like Google, right, we know that they're that they're saying, Hey, the fewer features I have running the simple or my environment is the easier it is to troubleshoot, the less that can go wrong and the less security vulnerabilities. I have these air all. It's all goodness to run less right. So if you give people the ability to actually do that, they have a substantially better network. Yeah, >> what's unique about what you guys doing? How would you describe the difference between what you're doing and what people mean she might be looking at? >> So if you look at what you know other folks, that you know that we're going to see that look at collaborative Riku Burnett ys everything they do is a bolt on until his old architecture that's been around for twenty five years. So it's like a marriage between these two items. It's how you go ahead and have this plug in that interacts with that. Forget all that you're going to get up in the same spot with another thing you're adding on to another thing you're adding on to another thing. Hearing onto it seized these abstraction layers on top of distraction layers were taking the approach where it is native to the non core operating system. You know, Cooper, Daddy's Docker, Micro Services and containers. They're native to the system. We're not anything on. We're not bolting anything on there. That's how it is. Architect designed to be run. >> And that's key, right? The thing that we were really walking away from from our operational experience, we know that the decisions being made at that, you know, CEO Seo level and even in the you know, director of infrastructure level are going to be We're looking to build an on Prem solution, Mr Customers saying I need it to be orchestrated by an open, nonproprietary platform that gets rid of all of the platforms that are currently out there by the traditional network. Oh, yeah, Bs right. If you start out saying my orchestration platform has to be shared from compute storage network and it has to be open and has to be not proprietary, that pretty much leaves communities is you're really only choice and combinations important. It's hugely important to us, right? We knew that when we broke everything into, you know, containerized Micro Services. You need something to orchestrate those. So what we've done is we said, Hey, we're going to use this Cuban eighties tool. We're going to embed it on the device itself, and we're going to run it natively so that it can be the control point for all the different containers that are running on the system. >> That's awesome, guys. Great Chef will go forward to chatting more final question. What words of wisdom you have for other folks out there, Because there are a lot of worlds colliding as we look at the convergence of a cloud architect, which, by the way, is not a well defined position >> where you >> have infrastructure, folks who have gone through machinations of roles. Network engineer this that the other thing programmable networks air out there. You seeing this thing really time data? I oh, ti's. Also, you're all coming together yet. So what, you gotta re evaluating? What's your advice to folks out there? Who who are either evaluating running POC is rethinking their architecture. >> So the first thing that you know I think this is pretty common from folks that to hear is that evolve, or you're not going to be relevant anymore. You need to actually embrace these other items you can't ignore. Cloud. You can't pretend like I have a network. These applications will never move because eventually they will and you're going to be out of a job. And so we need you to start looking at some of the items that are out there from the cloud native universe to couldn't see Cooper nineties universe and realizing that networking is not a special Silent is completely different from, you know, dev ops every items they need to be working together. And we need to get these two groups and to communicate to each other, to actually move the ball forward for getting applications out there faster for customers. >> Don't let the thing I would say to infrastructure, folks, especially those that are going to cloud strategy is don't let the Ivy and the Moss grow on your own prime solution yesterday. Right? Go into your multi cloud strategy with I'm gonna have some stuff in eight of us and have some stuff deserve. I'm not stuff some stuff and Google. I might have some stuff overseas because the data sovereignty. But I'm also gonna have things that are on prep. Look at your on from environment and make it better to reflect what you could do in the cloud. Because once you're developers get using the AP structures in the cloud. They're going to want something very similar on Prem. And if they don't have it than your own, Prem is going to rot. And and you're going to have some part of your business that has to be on Prem and you're going to give it a level of service that isn't as good as the cloud, and nobody wants to be in that situation. >> Glenn, Adam Thanks so much for sharing. Congratulations on the launch of Snap Out every year and thanks for coming and sharing conversation. >> Thanks. Great. >> I'm John for here in Palo Alto. The Cube Studios for Cube Conversation with Snapper Out. Launching. I'm shot for you. Thanks for watching