>> What? Welcome to a special keep conversation here in Palo Alto. Shot for host of the Cube. The Palo Alto Studios here in Palo Alto. Where here With Adam Casella, CEO and co founder of Snap Route and Glenn Sullivan, Cofounder. Snap. Right, guys, Good to see you. Thanks for coming on. So, you guys are a hot startup launching you guys? Former apple engineers, running infrastructure, I would say large scale an apple, >> just a little bit >> global nature. Tell the story. What? How did you guys start the company? We did it all come from the apple. A lot of motivation to see a lot there. You seeing huge trends? You'd probably building your own stuff. What was that? What was the story? >> So, yeah, basically way. We were running a large external stuff at Apple. So think of you know, anything you would use his user, Siri maps, iTunes, icloud, those air, the networks that Adam and I were responsible for keeping up, keeping stable on DH. You know, there was a lot of growth. So this is pretty twenty fifteen. We started snapping on August twenty fifteen, so it's a big growth period for, you know, icloud. Big growth period for iTunes. Lots of users, lots of demand. Sort of lots of building infrastructure in sort of a firefighting mode on DH. One of the things that occurred is that we needed to move to more of, you know, infrastructure kind of building out as you need it for capacity. If you start talking to the folks up the road, you know, with Facebook and Google and Microsoft and all those folks, you realize that you have to kind of build it, and then they will come. You can't really always be reactionary and building these kind of bespoke artisanal networks, right? So him and I had to come at it from both a architectural apology network kind of network engineering, geeky kind of level, and also from an automation orchestration. Visibility standpoint. So we pretty much had to do a Nen tire reimagining of what we were building as we were going to build these new networks to make sure we could could anticipate capacity and deploy things before you know it was necessary. >> Yeah, and make sure that the network is agile, flexible enough to respond to those needs, and change isn't required. >> You mentioned. The surge came around time for twenty, twelve, twenty, thirteen, different exactly apples been around for a while, so they had. They were buying boxes and start racking and stacking for years. So they have applications probably going back a decade, of course. So as Apple started to really, really grow Icloud and the iPhone seven, you still got legacy. So how did you guys constantly reshaped the network without breaking it with some of the things that you guys saw? That was successful because it's kind of a case study of, you know, you know, the next level without breaking >> anything. Yeah, did when migration was interesting, uh, essentially into doing it. She start attacking it for the legacy environments as Iraq. Iraq process, right? You gotta figure out what applications better most easily be able to move and start with the low hanging fruit first so you could start proving out the concept that you're talking about. You try with the hardest aspect or the Horace Apt to move. You're going to get it with a lot of road block. If my you might actually fail potentially and you won't get what you need where you need to go if you took, took some low hanging fruit applications that can easily migrate between, you know, an old environment and new environment. >> It's not dissimilar to environments where things are acquisition heavy, like we've got some friends at some other Silicon Valley companies that are very active. You know, acquisition heavy, right? It's It's a company that's one name on the outside, but it's twenty thirty different Cos on the inside, and what they typically end up doing is they end up treating each one of those as islands of customers, and they build out a core infrastructure, and they treat themselves more like an ice pick. So if you if you Khun, meld your environment where you're more like a service provider and you're different legacy applications and new applications arm or you know customers, then you're going to end up in a better situation and that we did a little bit of that, you know, at Apple, where they have, you know, really, really core service provider, head the type. You know, if a structure with all of these different customers hanging >> off his isolation options there. But also integration, probably smoother. If you think it was a service provider. >> DeMarcus solid right and clear. >> So talk about the nature you got cloud experts. I'll see infrastructure experts. You're really in the The Deep Dev ops movement as it goes kind of multi and agree because he got storage, networking and compute the holy trinity of infrastructure kind. All changing on being reimagined. Storage isn't going away. More data is being stored. Networks need to be programmable on DH, Secure and Computers unlimited. Now it's naming all kinds of innovation. So you're seeing companies, whether it's the department defense with the Jed I contract trying to. You're the best architecture on enterprise that might have a lot of legacy trying to re imagine the question of what to do around multi cloud and data center relationships. What's your perspective on this phenomenon? OK, we have tohave scale, so we have a little bit on Prem or a lot of fun. Prem, We'll have cloud and Amazon maybe cloud over Microsoft, so it's really gonna be multiple clouds. But is it simply the answer of multiple clouds just for the sake of being multi cloud? Or is there a reason for Multi Cloud is reason for one cloud. You sure? Your perspective on the >> sure it's it it's the thought might be that it's kind of most important have one overarching strategy that you adapt to everything, and that's sort of true, right? We'd say, Okay, well, we're going to standardize something like you, Bernetti. So we're gonna have one Cuban, these cluster and that Cubans cluster is going to run in desert. It's got running. Google is going to run in, you know, on Prem and all that. It's actually less important that you have one fabric or one cluster, one unified way to manage things. What's more important is that you standardize on a tool set and you standardize on a methodology. And so you say, Okay, I need to have an orchestration later. Find that's communities. You have a run time environment for my container ization. Sure, that's Dr or whatever other solutions you wantto have. And then you have a P structures that used to program these things. It's much more important that all those things they're standardized that then they're unified, right? You say I have Cooper Natives control, and I'm gonna control it the same way, whether it's a desert, whether it's in Google Cloud or whether or not it's on Prem. That's the more important part. Rather than say, I have one big thing and I try to manage so to your point, >> by having that control point that's standard with all the guys allows for. The micro services camp allows for all these new agile and capabilities. Then it becomes the cloud for the job. Things are exactly Office three sixty five. Why not use Azure? >> Yeah, I mean, that's the whole problem with doing like technology. Pick technology sake. Technology doesn't solve problems. Old is maybe a, you know, piece technologies to peace technology. And I think it's why you look at like, cloud native communities and doctor and and you know why Dr initially had a lot more struggle and widely more successful after you, Seymour, that cloud that have come out there because cloud native put a process around how you could go ahead and ensure these things. We deployed in a way that was easily managed, right? You have C I. D for I want my container. But out there, I have a way to manage it with communities in this particular pipeline and have a way to get it deployed. Without that structure, you're going to be just doing technology for technology sake. >> Yeah, and this is modernizing, too. So it's a great point about the control point. I want to just take it the next level, which is, you know, back when I was breaking into the business, the word multi vendor was a word that everyone tossed around every multi vendor. Why we need choice choices good. While choice down streams always, it was always something. There's an option. More optionality, less of a reality, so obvious is good. No one wants the vendor locking unless you It's affordable and spine, right? So intel chips a lock in, but no one ever cares, processes stuff and moves on. Um, so the notion of multi vendor multi cloud How do you guys think about that? As you look at the architectural changes of a modern compute, modern stories modern network facility, >> I think it's really important. Tio, go back to what you said before about office three sixty five, right? Like why would you run that? Other places other than deserve rights, got all the tools. Lt's. It's really, really critical that you don't allow yourself to get boxed into a corner where you're going to the lowest common denominator across all the platforms, right? So so when you're looking at multi cloud or hybrid cloud solution, use what's best for what you're doing. But make sure that you've got your two or three points that you won't waver on right like communities like AP Integration like whatever service abstraction layers that you want right? Focus on those, but then be flexible to allow yourself to put the workloads where they make sense. And having mobile workloads is the whole point to going into the Qatar having a multi cloud strategy anyway. Workload mobility is key >> workloads and the apse of Super Port. You mentioned earlier about ass moving around, and that's the reality, correct. If that becomes the reality and is the norm than the architecture has to wrap around it, how did you advise and how do you view that of unfolding? Because if data becomes now a very key part of a workload data, considerable clouds late and see comes. And now here you go, backto Leighton Sea and laws of physics. So I just start thinking about the network and the realities of moving things around. What do you guys see as a A so directionally correct path for that? >> Sure. So I kind of see if you look if you break down, OK? You have storage, You have network. You have, You know, applications, right? And I heard something that from a while ago actually agree with that. I says, you know, Dad is the new soil, right? And I look at that, OK, That that is new soil. Then guess what network is the water and the applications air seats. And if you have missing one of those, you're not going to end up with a with a, you know, a growing plants. And so if you don't have the construct of having all these things managed in a way that you could actually keep track of all of them and make them work in chorus, you're going to end up where e Yeah, I could move my application to, you know, from point A to point B. But now it's failed. Haven't they? Don't have connectivity. I don't have storage. Or I can go out there and I have storage and, you know, no connectivity or kind. Give me and, you know, missing one. Those competed on there and you don't end up with a fully functioning you know, environment that allows you >> so. The interplay between stories, networking and compute has to be always tightly managed or controlled to be flexible, to manage whatever situation when I was growing >> and you gotta have the metadata, right, like, you've got to be able to get this stuff out of the network. That's why that's why what we're doing it's not proud is so critical for us is because you need to have the data presented in a way, using the telemetry tools of choice that give you the information to be able to move the workloads appropriately. The network can't be a black box, just like in the in the storage side. This storage stuff can't be a black box, either, right? You have to have the data so that you could place the workload is appropriately >> okay. What's your guy's thesis for a snapper out when you guys started the company? What was the the guiding principle or the core thesis? And what core problem did you solve? So answer the question. Core problem. We solve his blank. What is that? >> So I think the core problem we solve is getting applications deployed faster than they ever have been right And having making, doing, making sure it's not a secure way in an efficient way. Operationally mean those air, basically, what the tenants of what we're trying to solve a what we're going for. And, uh the reason for is that today the network is withholding back the business from being able to employ their applications faster, whether it be in a polo sight, whether it be local on data center or whether being, you know, in the cloud from, you know, their perspective connectivity between their local, on prep stuff on whatever might be in, you know, eight of us is ordered >> Google and enabling that happened in seamlessly so that the network is not in the way or >> yeah. So if you could now see what's happened on the network and now you can have control over that aspect of it, you do it in a way. It's familiar to people who are deploying those applications. They now have that ability to place those work clothes intelligently and making sure that they can have the configuration of activity that they need for those applications. >> Okay, so I say I said, You guys, Hey, I'm solvent. Assault, sold. I love this. What do I do next? How doe I engage with you guys, Do I buy software? So I loaded Bokkelen infrastructure. What's the What's the snap route solution? >> So so the first part of the discussions, we talk about hardware. Obviously, we don't make our own hardware. That's the whole point of this allegation. Is that you by the harbor from somebody else? Andi, you buy the software from us, so there's a lot of times of the initial engagements. There's some education that goes on about this is what this aggregation means, and it's very, very similar to what we saw in the computer world, right? You had your classic, you know, environments where people were buying. You know, big iron from HP and Dell and IBM and Sun and everybody else, right? But now they can get it from, you know, ziti and kwon and sort of micro and and whoever else and they wouldn't They would really think of buying software from those same companies. Maybe some management software, but you're not going to buy your licks version from the same people that you're buying your harbor from. So once we explain and kind of educate on that process and some folks that are already learning this, the big cloud providers already figuring this out, then it's a matter of, you know, here's the software solution and here's howto >> be a threat to civilians getting what? My plugging into my connecting to certain systems, how would I just deploy? It will take me through the use case of installing it. What is it? Connect to >> shirt. So you have your white box top Iraq device or, you know, switching my on there. You load our code on there. We used only to initially deploy the stuff on there on. Then you can go. You can go ahead and load all the containers on. They're using things like helm and pulling it from harbor. Whether that be exciting, if you have locally or internally or you Khun bundling altogether and loaded in one particular image and then you can start, you know, interacting with that cabinet is a P I. To go ahead and sort of computing device. Additionally, we'll make sure this is clear to people who are, you know, networking guys going on. Cooper. Netease. God, what is all this? I never heard of this stuff. We supply a full fledged CIA, lied. It looks and feels just like you want a regular network device toe act as a bridge from what you do, those guys are comfortable with today to where the future is going to be a and it sits on top of that same apia. >> So network as we're comfortable with this correct that's going >> and they get to do stuff using cloud native tools without worrying about, you know, understanding micro services or continue ization. They now have the ability to pull contenders off, put new containers on in a way that they would just normally use. Is he alive? >> I want to get you guys thoughts on a trend that we've been reporting on and kind of coming on the Cube. And I certainly have been a lot from past couple years past year. Particular covering this cloud native since the C in C S Koo coupon was starting, were there when that kind of started. Developers, we know that world develops a scene and agile, blah, blah, blah, All that good stuff. Networking guys used to be the keys, have keys thinking they were gods. You're networking engineer. Oh, yeah, I'm the guy saying No, All the time I'm in charge. Come through me. But now the world's flipped around. Applications need the network to do what it wants yet. Right. So you start to see program ability around networks. Let's go live. We saw the trend. The trend there is definite there. Developer programs growing really, really fast. He started. See networking folks turned into developers. So youjust smart ones do. And the networking concepts around provisioning is that you see service measures on top of you. Burnett. He's hot. So you start to see the network. Parent Policy based this policy based that program ability Automation. It's kind of in the wheelhouse of a network person. Yeah, your guys. Thoughts on the evolution of the developer, The network developer. Is it really? Is it hyped up? Is that and where's ago? So >> we're going back to where we're networking originated from right. Developers started networking. I mean, let's not forget that right. It wasn't done by some guy who says I have a sea lion. I'm going now that work's work. Know someone had to write the code. Someone have deployed out there. But eventually you got to those guys where they went to particular vendors and those systems became or closed. And they weren't able to go ahead and have that open ecosystem that we, you know, has been built on the compute side. So that's kind of, um it does say, or, you know, hindered those particular that industry from growing, right. Never going. She's been hindered by this. We have been able to do an open ecosystem to get that operational innovation in there. So as we've moved on further and now as we get that, you know, those people saying no. Hey, you can't do anything. No, no, no. We have the keys to the castle. We're not gonna let you through here. The devil's guys, we're going when we still need to. The player applications are business still needs to move forward, So we're going to go around. And you could see that with some of the early ESPN solutions going on there says, you know what? I figure like that we just exist. Okay. Tunnel we're going to go over you. That day is coming to an end. But we're not going to go do that long termers air going on here because that efficiency there, the overhead there is really, really high. So as we start going on further, we're good. I have to pull back in tow. When we originally started with networking where you have people will use that open ecosystem and develop things on there and start programming the networks to match what's happened with the applications. So I see it. Something just >> clicked in your thoughts. >> Yes. So the smart network engineers, the guys and girls out there that want to be progressive and, you know, really adapt themselves are going to recognize that their value add isn't in being a SEAL I jockey and cutting and pasting from their playbooks in their method. They're forty eight page method of procedures that they've written for how to upgrade this chassis. Right. Um, your your expertise is an operational, you know, run time. Your your expertise is an operational best practice, right? So you need to just translate that. Lookit communities, looking operators, right, operators, existing communities to bake in operational intelligence and best practices into a bundle deployment, Right? So translate that. Right? So what's the best way to take this device out of service and do an upgrade? It's us step. It's a method of procedures translating that new acumen and his operator to put that in your communities bundle Senate in your image. You're good to go like this is. The translation has happened there. There is an interim step right. You know, our friends over at answerable are friends and puppet, insult and chef and all. They've got different ways to control. You know, traditional see allies using, you know, very, very kind of screen scraping, pushing the commands down and verifying getting output in changing that, it's possible to do it that way. It's just really painful. So what we're saying is, why don't you just do it? Natively use the tool like an operator and then put your intelligence into design operational intelligence layout like do that level instead of, you know, cutting and pasting >> for so developers are it's all developers. Now it's emerged together. Now you have open >> infrastructure is code right? >> Infrastructures code? Yeah, everything >> Israel programmer, I mean, but you can't you can't and I want to make sure it's already clear to include was saying that you can't get away from the guys who run networks and what they've seen experienced that they've had so but they need to now take that to his point and making it something that you actually can develop in code against and actually make into a process that can be done over and over again. Not just words on paper. >> That's what I think they were. Developer angles. So really, it's about translating operational efficiencies into the network into code because to move APS around do kind of dynamic provisioning and containing all the services that are coming online. >> And you can only do that if you've actually taking a look at what how the network operating systems architected and adopt a new approach of doing it because the legacy, ways of doing it don't work here >> and getting an operation from like what you guys were approached. Your strategy and thesis is having OS baked as close to the network as possible for the most flexible on high performance. Nice thing. Secure abstraction, layers, first proxies and >> simple it down >> with that great guys. Thanks. And good luck on eventually keep will be following you. Thanks for the conversation. Thank you for your conversation here in Palo Alto. I'm John for you're talking networking cloud native with snap route. Launching a new operating system for networks for cloud native. I'm John Forget. Thanks for watching.

>> 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