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