 All right, good morning, everybody. Thank you very much for attending. I think I've succeeded into tricking you guys to come here with a fancy title. So hopefully, it's worth it. So Alice in Wonderland, networking in DevOps with a splash of OpenStack. I think you'll get the picture here in a little bit. My name is John Willis. I am a VP of Customer Enablement at a startup called Stateless Networks. Botchakaloop is probably the best way to find me. You can attend to just be on Twitter all the time, right? So that's my kind of portal to life these days. And then I try to put, there's a lot of references. I'm going to talk about books. People get really annoyed at me because, like, John, every time you give a presentation, I have to add seven more books to my reading list. So anyway, I put a little bitly there that it's basically just a bunch of presentations, references, and stuff. And I'll add some more, because I usually pretty dynamic here. I'll think of other things along the way, and then talk about some book I didn't even put there. So the overview is we're going to introduction who I am, why am I qualified or not to be here to talk to you guys about something. SDN opportunities, yeah. We'll go around that. We'll kind of talk about what does DevOps really mean and what's driving it, possibly, for the network. And then I'm going to take a little history lesson on DevOps, because one of the things you'll find out I've been doing this thing called DevOps for quite a while. And everybody says that, but I've actually been doing DevOps for quite a while. I was at the first DevOps days in Ghent. And that was only five years ago, but I was playing around with Puppet seven years ago. So you'll get the picture shortly. And then I'll talk about, like, what's the possibilities of networking in DevOps? And hopefully, that will be the real exciting part of this presentation. And so just one quick, I don't do product presentations. I do when I'm with a customer. When I give presentations, I like to talk about information and kind of try to get people thinking deeply. So this is really the only slide I'm going to talk about the company I work for. We stateless networks. We're a web scale for networking. If you think about what Chef and Puppet have done for compute, we're trying to do something very similar for networking. It's a very interesting model. If you want to learn more about it, please ping me. And I'll give you a demo or whatever you want to know about it. We'll have lots of fun there. So who am I? I'm an old dude. I'm actually 55 years old. And I calculated I've been doing this shit for four days. And I do cursal periodically too. So if that offends you, I'll try to do really bad curse words on this one. DevOps days, we curse like this no tomorrow. We're drunken sellers at DevOps days. But I'll try to curl it down here. So I realized I've been doing this like four decades. And I've actually had four careers in the four decades, which is kind of cool. I started out as an IBM mainframe guy. As you wrote a sembler code, if anybody's old enough to remember companies like Candle and Landmark Systems. And then I became a Tivoli guy. And if you're a little younger, you might remember what Tivoli was like. And I still have scars on my body from working with it. But it was fun. And then I got out of the Tivoli business and really started doing, really focusing on the kind of open source version of that, which were originally things like Nagios and stuff like that. But it drove me right into Puppet Chef. And I actually was the ninth person hired in at Ops Code. I think on my resume, John Ospar says, or there's a guy out there that says, he's the guy who didn't hire John Ospar. Mine is going to be, I'm the guy who hired Matt Ray. Where are you Matt? So there you go. That's my claim to fame. So I did a lot of cloud. I actually recently worked for a company called Stratius, which was sold to Dell. It was a CMP cloud management platform. And today I work for Stateless. Network's focusing on the network. It's kind of my fourth career, which is networking. So I'm going to take you down this rabbit hole here. And so if you don't, these pictures are actually from a Salvador Adali collection, which Alice in Wonderland. And actually I own a couple of these prints. So I wanted to tell you kind of a story. And I'm writing a book for O'Reilly called Network Operations. And this is kind of a short, short version of the first chapter. In 2007, I'm at Oskon, and a friend of mine introduces me to Luke Kniece. Luke Kniece, founder of Puppet Labs, has given a presentation. And I just finished doing configuration management for some of the largest companies on the planet. And it was a really bad form of configuration management. But I sit in his presentation. I see this young kid, and I'm thinking, what is this kid going to tell me about? I just got back from B of A. And I've been doing it. And five minutes into it, I'm that annoying student like, Luke, one more question. And I got my pad out. And I realized it was a life-changing event for me, honestly, because I realized everything I had been doing for 10 years prior was wrong. And I realized that this was a generational change in the way we did configuration management, and IT management. I think most of the people in this room probably realized that. And it changed my life. And I worked with Puppet for a while. But my real breakthrough was I got to meet Adam Jacob. He hired me. I was the ninth person in Ops Code. He hadn't had a real blast. But one of the things about, the minute I saw Puppet, I got it. I was totally in the subtraction, infrastructure as code. It all made sense to me immediately. But I sat down with Luke, and we had a cup of coffee. And he was explaining his vision for this. And I was like, Luke, you've got a great practice. Great, this is going to be able to do it. He was like, well, John, let me tell you the real vision. He says, operations is going to become like software engineers. And I'm like, if you have office space as a lumber, I'm like, yeah, I don't think that's going to happen. And he talks about how operations are going to start writing code that they're going to store in source control. And I was like, yeah, I don't see it, Luke. And it took me about a year to actually, it wasn't to a year later, at a velocity conference where Adam Schaefer gave a presentation about agile infrastructure. And I realized, oh my god. I knew he was right about Puppet. I didn't believe he was right about operations becoming more like software engineers. And so that really started me on this journey of what really, I think DevOps is about. It's about collaboration and engineering and software. I've got this kind of elephant in the room thing. So the discussion of SDN, this isn't really about SDN. I think SDN is this overload. I mean, SDN is awesome. Control plane, disaggregation of switches, moving to control plane, all that's cool stuff. But there are a lot of forces in play that I think are driving this opportunity to allow the network engineer to start thinking, going through that transformation that I went, when I sat down with Luke and thought Luke was out of his mind, I think my quote was, that's going to go down like a lead zeppelin. And I think that resource of some shifts, kind of tectonic triffs, shifts that change things for compute and just admins. And I think SDN is the buzzword for that. But this is the blind man in the elephant parable. But what are the shifts? It is SDN, but it's also open stack. Open stack is putting enormous pressure on classic legacy network engineering. Is there anybody in the room that disagrees with that? Network functions, virtualization, open flow, the virtual switching overlays. These are all things that are just kind of driving. We've got to have to move fast and faster in all areas. We can't have these three areas be extremely fast in this area be really slow. Because everything slows down. It's the bottleneck. But what's even more interesting to me, and what was interesting to me seven or eight years ago when I started working in Puppet and in Chef, is the underlay. So we tend to forget the underlay. We say SDN and everything's great. But there's really cool stuff going on with the Linux-based network OSes. Like Arista, I've had this great opportunity to play with Arista in the last six months. And the programmability of that machine is insane. And then you look at what Cisco has done with the new 9K. And you can run all those containers on these things. You're in KVM on Arista. You start putting other things in there. And then you get down to something like Cumulus Networks, which is the complete disaggregation of the software. It's identical to what happened with Sun and AIX, Solaris and AIX. And we went into Linux. Then they started just buying different hardware and different software. And Cumulus Networks is kind of a disrupter for that. They sell you the Switch software. And they give you a list of hardware vendors that you can go to and use. And then you kind of move on. Big Switch, bare metal switching. They were down in the booth. Had a booth the other day. So I think the meta point is our switches are starting to look more like servers. And how we treat servers probably or how we treat switches should actually be the way we treat servers. And I'll give you some data points. So seven to 10 years ago, I used to ask the question of every enterprise I went into is, what is your sysadmin to server ratio? And it's not a great number. And it doesn't tell you everything you need to know. But 95% of the people that I asked, and I got to visit some really big companies, the number was like 1 to 50, maybe 1 to 100. Today in a kind of a company that's adopted DevOps principles, large enterprises that have adopted, it's 1 to 10,000, 1 to 20,000. And I heard a story of a company, a well-known company that is in a classic legacy that's basically about 120,000 to 1 ratio. Now seven or eight years ago, if you want to, I didn't ask this question seven or eight years ago, what the ratio was to network operations or engineers to switches, I know what the number was. It was probably about 1 to 50. And it's kind of interesting enough right now as I talk to people now, if you're not web scale, if you're not a unicorn shop or you really haven't adopted DevOps in networking, you kind of forgot about those people, it's about 1 to 50. In fact, there's a large bank I just recently talked to told me that they have two people managing 40,000 servers, but their switch ratio is still 1 to 50, right? So, I mean, that should just scream at somebody who's in charge of an infrastructure, right? So in summary, you know, in summary, basically, SDN is definitely driving a lot of this stuff. And you know, I'm not down on SDN, I just think the programmability from a guts and underlay and somebody who likes to like really fix the infrastructure, it's not there yet, right? Like there's a really lot of smart people are figuring out how to put abstractions on open flow and flow tables and there's projects called Frenetic and really cool stuff. And at some point for dummies like me, I can go in and have a lot of blast, but right now the underlay is really a lot of fun and what's driving a lot of that is, again, network, open networking, it seems to be the norm that open source is part of, I mean, it's always kind of been part of networking, but now it's in your face, open. Things like cumulus networks. Obviously, network virtualization is changing everything. Everything moves around, nothing static. Clusters become, you know, we get our service chaining as part of the clusters as they move dynamically. And then open stack, right? So, I promised you a history review. The thing is right now, I think Michael, anybody see Michael Cote's presentation yesterday? Two people, yeah, he's pretty awesome. Michael works for a 51 group. So they've recently done a survey on DevOps and I used to say about three years ago that I used to try to convince people to go to DevOps in the enterprise to say there was this 3% club and 97% of people in IT infrastructure are not in this club. And all you have to do is decide to do it and you're part of that club, right? And I think the number now is like more close to the 20% and Michael said they did a survey for 51. They believe that it's about 20% of the people are adopting some form of DevOps. The good news on DevOps, like my work is done because like the memo's out, everybody knows about it. Everybody's gonna be talking about it for compute, right? When I know that the evangelism job for me is done. When I go down the exhibit hall and every vendor says they're a DevOps vendor, right? Score, done. But here's the thing, like seven years ago, like we think, oh, that was easy. No, it was hard. And people tell me, well, John, when you go talk to network and you say, they're not gonna like what you're gonna say. And I'm like, I know exactly what they're gonna say. Like, yeah, but you don't know. I'm like, do you think those CIS admins and legacy were like really kind to me? When I walked into their office and told them that they had to do this subtractions code and they probably should store stuff and get and maybe thought about behavior. Wait a minute, that sounds like those developers. How dare you, right? And like we won that war, but it wasn't easy. So all along the way, I like to make fun of things. And so I make fun of those old legacy CIS admins and I have an archetype, he's called Bob. You gotta have a Bob in every story, right? So Bob is great. Like Bob's got a Bob directory. And there's Bob scripts. And if digital properties could have coffee stains, they'd be on Bob scripts, right? And, oh, that one was funny. Come on guys, all right, all right. So the thing is that, and Bob kept that really tight. And it literally looked, it was like hard code to read too. There was some purpose in that, right? And I would say when Bob dies, everything gets screwed. And Bob was a big parallel SSH, right? And Adam Jacob used to joke, he's like, how many people used to do it, do it five? And everybody chuckles, right? And you know, and then you try to talk to Bob. All right, Bob, I got this idea about how you can change things and it's a chess match. And the first thing he says, well, John, this sounds all sounds good, but I don't trust it. You know, this thing that's gonna go magically do stuff and it might do stuff that I don't want it to do. And oh my God, like, calm down, Bob, really. Like you're gonna tell it what to do. Like there is some DSL and it's not gonna go off and do crazy things that you don't want it to do. And he gets past that and then he goes into the snowflake argument. Well, you just don't understand my application. It's special, right? And then you're like, okay, let me see it, Bob. I'm like, Bob, the last 10 places I've been doing exactly what we do. He's like, no, look at this. Like, that's my sequel, dude. Like, okay, and then you finally get past that and then you get to the, well, all that could be true, but it can never, ever, ever, ever break. My system can never, ever, ever, ever break. Like, okay, let's talk about failure modes. Let's talk about anti-fragile. Let's try to go that route. And in the end of the day, it took about four runs to get, Bob, we used to joke at Ops code that if we walked out with a non-success, we'd be like, they're gonna call us back in a year, because they'll get it. But the end of the day, it was about change. It was about the fear of losing a job. All that good stuff that we all fight for everything we try to do when we try to apply innovation. But what forced Bob to change was, there was this tectonics that just basically came in and changed their life, right? Like, the disaggregation of operating systems like AIX and Solaris, right? You know, Linux became pervasive. And that was one shift, but the second shift was even more important was really ephemeral infrastructure. And that was anywhere from cloud to just self-service on steroids or even virtualization with real high-quality self-service. I mean, the idea that people could go from six weeks to six minutes to get resources. And if Bob's job was, in the six-week scenario, it took Bob two days to do what he had to do to get it done, that was okay, because who cared? But when it turned into six minutes, Bob had to go down to two minutes. Or he was out of a job, or he just, it didn't work, right? So that world changed for Bob. So early observations in the network world, so about six months, I've had this passion of trying to do this evangelism in the network space. I knew I was in the right space when the first five people that I talked to said, you'll never change a network engineer. Never happened. I'm like, okay, I heard that one before, right? And so Brent Salisbury, if you don't know him, you should definitely know him. He has this great side, you know, still being used 15 years, the trombone, right? So what are my early observations of these network folks? And I'm pissing you off, because you're a network folk. Good. All right. The archetype here is Bill, okay? And Bill runs accept scripts, tickle, maybe some pearl. Lot of spreadsheets, actually by the way, there was a lot of spreadsheets for Bob too. He did a lot of cutting and pasting. He just kind of didn't let everybody know. Seems like the network, in my first observation, the network engineers are not ashamed of doing cutting and pasting. The Bob's way, they were like, they hid it like, oh no, I don't have, I don't have Excel up. No, no, no. But Bill has got the same argument. I don't trust this thing, John. And then you don't understand my network. And then, you know, and then the ever, ever, ever break, and I get the break thing, right? I do. Like, you know, router protocols, I've learned a lot in six months, right? Okay, I don't just walk in and say, oh, change this. And you know, this is complicated stuff, no doubt. But I am going to mark my words, be in jail because I'm gonna murder somebody. The next time I hear them say, well John, if you bring down a server, it's no big deal. But you bring down a switch and I say, have you ever heard of Knight Capital? Right? And if you haven't heard of Knight Capital, Knight Capital is a poorly configured server, bad hygiene, no DevOps, that accompanied it in three to $400 million in three hours and was out of business in 24 hours because a server went south. So again, I understand the complexity of networking, but don't, like, the problems we're solving, that Knight Capital, if you read the SEC filing on it, could, in fact, I've talked to friends at work in high trade in those type of businesses and there were all sorts of things that they were doing in quote unquote DevOps that might not have stopped it, but they wouldn't have went out of business. They would have quoted it in 10 minutes. They might, that server might have been rebuilt as an ephemeral infrastructure and it wouldn't have had that bad hygiene that it had. There's three people I want to thank in my last six months for really just being people that have helped me understand a lot and just incredible people. And I'm pointing them out both for you and me. If you don't know Brent Salisbury, he works on ODL for Red Hat. He's just, you know, he's a brilliant young man and just very open for sharing and just, you know, and the thing about these three guys is they really want to drive DevOps in networking. I mean, they're looking for guys like me. They haven't figured out yet that I'm not that smart, so don't tell them, but they're looking for the DevOps folk that the people that have been doing this because they're like, come here, help us understand what you guys did, right? And then Jeremy Shulman over at Juniper, Jeremy wrote the first puppet. He wrote the NetDev Ruby Jam for puppet on Juniper. And by the way, every time a new vendor comes out with their kind of NetDev, they don't even change the name of the VLANs that Jeremy wrote, like the Ansible one, the Chef one. Like they just say, I laugh. I'm like, oh yeah, there's Jeremy's stuff again. And then we've got Colin in the room. Colin is to me an encyclopedia of network knowledge. I mean, when I get to sit down with him and have coffee or a beer, I literally feel like I should be taping him. He gives me so much knowledge. So enough of that. Before we get into the DevOps and networking, if you like anything I'm saying, I got some pointers to all the presentations. Over the last two years, I spent a lot of time talking about culture. I'm a big believer in this man, Edward Deming. I believe Edward Deming created Lean in Japan. Lean became Lean IT. Lean kind of became Agile. You can point right from Deming to DevOps. In fact, I have an article out there called Deming to DevOps. And so the core of what that comes out to is, me and a friend of mine, David Edwards, we created this acronym called CAMS. It's reasonably sticky in the DevOps world. Culture, Automation, Measurement, and Sharing is how we can put somewhat of loose taxonomy around what DevOps is. And what you'll hear most people say, if you don't get the culture right, everything else is just useless or nonsense. And it really is true. I mean, you can't just take great technologies in cloning. I mean, you have to break the bone from the way people think and how you can't just put puppet in front of a network engineer or tell a network engineer to go learn Python and all will be well. It starts with some type of, of cultural behavior shift. And so when I went back and I said, okay, what, if I could come up with one word over the last 10 years, that has, you know, that really kind of manifests what has been the most success in DevOps for compute, if we'll just say it that way. And it's the power of pull. And if you think about pull, there's two modes. There's the pull for change, and there's the pull for flow. And if you talk about pull for change, what are we talking about? We're talking about Git. And Git probably, I think Git might be, when we look back in the next 10 years, more innovation was probably caused because of Git and the concept of the workflow behind Git. And you think about how people collaborate in that model. I mean, right now it's the only game in town. And so like, if I'm gonna go in and try to help network engineers, I'm gonna, the first part, they're not gonna like this, you know, I'm gonna teach you Git. And you used to go in somebody else's home and I'm like, no, no, you can't teach Chef. You can teach people, and now I realize I was stupid arguing against that, right? There's such a power in that workflow and when you see it and you get it. And then the other pull is really the core of this continuous delivery thing that we've got going here. Right, it's that flow. It's a pull going into, you know, I wanna get something into production. What's the classic chain is something like an SVN or it should be SVN, Git or GitHub, and it goes into some Jenkins process or some CI process. Then it goes into some behavior-driven test development. Then it goes into production, maybe driven by something like Chef and Papa or CF Engine, right? So those are the two things that, you know, like I think a lot about like, how can I try to break the bone to heal the second time, knowing what I know now, right? And so I'm working on a book with Gene Kim, Gene Kim, The Phoenix Project. We've got another book that's like ridiculously late, so please don't ask me when it's coming out. It's called The DevOps Cookbook. And so we've compiled a lot of things and hacks and, you know, I think Colin, you know, it's fun for me when I first met Colin, you know, like, even in the DevOps world, a lot of people don't know this is fabulous tool called Value Stream Mapping. It's an amazing tool. It comes out of Lean. ThoughtWorks is a company that really, that's where I learned it from those guys. It really is a flow. If you want to learn more about it, there's a book called Learning to See. Infrastructure is code. I think you, if you understand Puppet and Chef or CF Engine, you should get that. You know, I'm going to run out of time like the last gentleman, so if you want to learn more, there's plenty of ways to learn about that. Continuous delivery, there is the hot button for everybody in application flow. You know, how do I get things from an idea into production and how do I make that bulletproof and, you know, you hear the 100 deploys a day, 1,000 deploys a day. There was an Amazon presentation, if you hadn't heard this a couple of years ago, where I think they were talking about 1,000 deploys in one hour to production. Now Amazon's a weird beast, right? You know, so it's Google, like, so that's not an number you should, like, oh my God, I'm not doing 1,000 deploys an hour, right? But in the production world, people are, like, achieving spectacular things in terms of how they get things in front of customers. And if you read Eric Reese's Lean startup book, right, Eric Reese was originally somebody who was kind of invented the end per deploys per day at a software company, right? And they got famous, wrote a book, now he gets $8,000,000 to speak, right? So another, one of the chapters that I'm working on is this embedded engineer thing, right? So this worked really well in the DevOps transformation from SysAdmins and Dev versus Ops, where the idea was you took somebody from the Ops team and you actually put them their responsibility to live in the Devs team, six months a year or maybe permanent. And it crushed, in case this great situation where there was a change of culture, there were behaviors, there were things that the Devs would say, oh, we're gonna do this and the Ops guy would say, oh, no, no, no, no, don't do that, you know, and they were like, oh, why? And he's like, well, because when you do that, and it really worked well, and I have a whole chapter about this and it will work. So I'm wondering if that's gonna work in the network space, right? Is there this idea of a shift around, and I'm getting an odd from Colin? Yes, a Kanban. Kanban is a fabulous tool for operations or organizations that are interrupt driven. So, and again, Kanban is really another thing that comes right out of lean. Somebody told me the other day, and I was like, oops, I forgot that one. Somebody gave a presentation yesterday when talking about how the network engine is pure. Darn, I should have thought of that one. Right, of course. I'm gonna make some config changes. Hey Joe, what's your schedule? Let's go ahead and peer on these changes. I mean, it's another reason why I like the Git model, because basically a pull request is a collaborative change, right? You know, I'm a big fan of hack days. So if you're not inviting the network engineers to your hackathons, oh, first off, if you're not running hackathons, you probably should be internal hackathons. And if you're not running an engineer, or better yet, your network engineers are having their own hackathons and they're inviting the ops people. And at the end of the day, it's about having fun, right? Like, you know, you've got to break the bone. There's gotta be a sense of, I remember about a year and a half ago, I went into this large credit card company, and it was like just, you know, classically old, you expected the worst. And we got into the war room where all these, the DevOps group worked. There were Nerf pistols all over the place. There were, you know, the soda machines. There was a foosball table. I was like, my heart was like, because you only only see that stuff in the Silicon Valley and startups, right? And I'm thinking like, okay, if you were at an artwork group that's on the fifth floor and a bunch of dirty old cubicles, why don't we put them up on the sixth floor in a war room and put Nerf pistols and see what happens. Maybe somebody at two and a half that you get pissed off about shooting everybody with Nerf pistols, right? And like, it's about having fun. So what are the opportunities in this new world? I mean, there's a debate now. I have this argument, Jeremy Shulman, a lot about do network engineers need to become programmers? You know, I don't know. I've heard some really incredible people over the last five years, six years, that each one of them would tell you they're not programmers. I would probably say they're lying, but the point is they're really not programmers. I had a guy, John Vincent Lucis, I hired him, right? You know, he would say he's not a programmer, but no language, you know, when Go came out, like a day later, he basically had a whole bunch of stuff written in Go. You know, so what I would say this is, I don't know where the argument feels. I do know, I think that the analogy is like languages. If you're a world traveler and you know, you may not have to be fluent in like all the countries that you travel to, but you better have enough language knowledge to ask like how much something costs or where the restrooms are, right? You know, and I think that's my theory on polygons, which is learning multiple languages. There are some purists that would say you should never do operations unless you know five languages and you should be a programmer. I don't agree with that, but I do think you, I think everybody, you know, what is it? Mark Andreessen said software's eating the world, right? And he didn't just mean applications. Like software is a reality in everything we do. It's network security, operations. So we really need to be part of that. And so we might not all have to be programmers, but we probably need to be adaptable enough to know to ask where the restroom is, right? Or how much it costs. So abstraction, so how do you start thinking about flow? Maybe you keep stored configs in GitHub, right? And maybe, you know, you keep source control. Maybe you do some form of unit testing if that's available. You do some type of behavior-driven test. I'm gonna show you something I tried to do at Hackathon where I tried to use this whole flow for stored configs on Arista. Or actually use Cucumber on the back end to do behavior-driven development. Low-hanging fruit in this space. Again, early observations. You know, a lot of stuff on the VLAN stuff. You do a Google on VLAN and kind of Dev Opsin or whatever, you'll shit chef, pop it, you'll get this. VLAN creation, VLAN port mapping, link aggregation. Easy kill. If that's something that's like happening a lot in your shop, then you totally miss the SDN thing. But besides that, you probably should be thinking about automating that, right? Like if there's three people creating VLANs like eight, nine, 10 hours a week, whatever. Like there's really easy ways to fix this. And some of the ways, our stateless, we fixed this. Puppet, I'm not gonna go into, Puppet has a NetDev module. Chef has a NetDev module. We have a Ruby abstraction module to do things like that, to do. Now you can get into more high-order stuff, like for example, like automated bills. Martin Fowler, who was one of the original Agile manifesto authors wrote an article a while back called Immutable Servers. And I was feeling like I'm gonna get punched in the throat when I say immutable switches, but we used to joke in the Dev Ops world, like can your server pass the throw it out to six-floor test? In other words, if you threw the server out, could it go back to the same state? And the truth is, with our products, some other products, you're able to do that now with switches. Like if it's a leaf and a leaf spine, then you can actually field replace it and put it back. And it go back to the state that it is. So we're there, in an hour, not everybody's doing it, rolling software upgrades in that work. So how do I hit a whole bunch of top-of-rack switches? It's the same start of how we did cluster updates. Like we can do blue-green deploys for switches. Like, and if you don't know about blue-green deploys, read Jez Humboldt's continuous delivery book. It's awesome. You know, automation compliance. And here's the one, this is the hard one, right? So there's a company called Etsy, and they used to put these shirts like MTTR is cool, right? And so if you know what MTTR is, it's being time to repair. And one of the things that we learned really hard, and still for it, if there's 20% get Dev Ops, there's probably still 10% to get this concept I'm about to tell you, is that failure is awesome. The more you fail, the more awesome it is. Like, and if you read Antifragile, you'll kind of get it, even though the guy wrote it as a jerk. The... I'm glad everybody got that. He's not the only one he called a shithead on Twitter. Raise your hand if the nice of Talib has basically called you and ended it on Twitter. Come on, please. Oh, come on. I know 15 people that had Dev Ops shop. He's done that. So that's a badge on him, by the way. But meantime to repair, right? It's like, it's not like trying to figure out meantime between failure and trying to figure out how to stop the black swan and how are we gonna, like that's not the world we're going into or we live in. The world we're in now is, shit is going to break. And when it breaks, it's an opportunity. In fact, there's a great story, I'm totally gonna run out of time, but there's a great story with Facebook says that, so they give the story like all these badge on and Dev Ops come and say, our developers pushed the production on the first day of work. Her, you know, and that's this badge on. And I remember one time somebody raised their hand, like, yeah, yeah, but what if they break the system? And it was like so canned for the guy from Facebook, he said, that's awesome. They actually get like a bonus. Because if they can on the first day break our infrastructure, that we've got 30,000 people or whatever, the smartest people on the planet are built. And this guy figured out how to break it. That's awesome. Good job, well done, right? So, I mean, again, that's gonna be a hard sell in the network space. Wham! I wish I could say I planned that, but no. So what else? Of course, the, you know, all the stuff, like, you know, if you've had the opportunity to open up the Commowner on OVSDB, open V-switch and the flow tables and all that stuff, right? Oh my God, give me my recipes, give me my scripting, right? I mean, it's just, you know, I mean, there's so much opportunity and it's early. But like, you know, if you look at the stuff that's going on, open flow, OVSDB, you know, the open daylight, I mean, I think that's gonna happen. I was at one of the early open daylight summits and I was at the first open stacks on it. And to me, the attitudes and the hype and all, and a hype in a positive way, it was identical. It smelled to me like, this is what open stacks gonna look like in a couple of years. So quickly, some case studies. The first one is just an interesting one. It has tones of DevOps all through it. It's a telco that recently worked out. They use a Rista, Leaf Spine Network. They're using Stateless Networks. They use some Puppet Razor, Piston for OpenStack and Cloud Foundry, Service Mesh Boundary, Pum Grade, okay? But here's something that's cool about it, right? So it is really, we're following it on this model, but one of the things that's cool about it is they're kind of doing this two-stage build of these. They're planning big. Like they're expecting that they're gonna basically do lots of clouds. And then what's even cooler is not that they're gonna build lots of clouds for lots of people, but they're gonna actually clouds, instead of just virtual instances being ephemeral, the clouds themselves might be ephemeral. So in other words, they're asking for requests to have a deep provision of cloud. Like this cloud, this one cloud of the many clouds that we have may only exist for a month. And so what's cool is that, so one of the things we're getting involved is, I mean, literally you're rolling a rack. So imagine a world where they got all these things and they've got some trigger at 70% capacity, they roll in more racks. And then the racks get like rolled in, power gets turned on, and they get configured to a network state. And they call it the razor state, right? So which is the, because they're using razor, but basically it's got this base, like I'm available and ready to be used rack. It's done through attestation. It's got, everything's biosting. We kick off the, so Rista has a zero touch provisioning, which is kind of a pixie boot, which then we drive puppet, which then does razor and everything's like ready for the, ready to go, hot available racks for use. And then somebody comes along through an API Crest and says, oh, I wanna turn those four racks into an open stack. And I need the first rack to be the cloud control and the other three to be the compute nodes. And then I need this to be, these three to be a Hadoop cluster. And then I need these. And then, oh, by the way, I want to deprovision that one back to razor state. So I thought that was really interesting and again, really thinking about how kind of ephemeral and thinking beyond just we're building open stack and we've been doing it for four years and we got our first WordPress app up. So that one was funny, right? And then this is the one I did a couple of weeks ago at a hackathon. So I set up this hackathon. It was an SDN hackathon. I volunteered to run it. I wanted to do a dev ops thing. Only about 10 people showed up. There were all a bunch of college kids from Cornell and of course they wanted to work on the control plane and do SDN for WAN. So I had to do it all by myself. So I didn't get to complete it. But the idea was this kind of flow that I've been talking about. And I've gotten this idea for a couple of customers. I can't share what the customers are giving me. But literally they're starting to stir configs using either Ruby templating or Ginger, which is a Python templating mode. And then they're actually storing them in GitHub. When they do the pull request, they're actually running them through kind of a Jenkins build. They're using Vagrant to set up mock environments. If it's just like some of the open stack stuff, MiniNet, but if it's like Juniper or it's Arista, there are virtual appliances. Arista has this VEOS. So imagine a scenario where you're configured an MLag pair with a fake spinus three VEOS's and you made the change in the config in GitHub, you made the pull request, it got built, the images got started, it got configured, and then you ran Cucumber to go ahead and ask a question, is my MLag pair up, right? I mean, that's pretty cool, right? So that's about all I have. Couple of things, I would say Cam's not Am's, right? Don't forget the culture. It's always about the flow. People ask me who this picture is. Since I read the shirt, you know, but it's Edward Deming. I think if you really want to know all the answers, start with Deming, honestly. It all starts to make sense when you go through and you understand everything that's happened from Lean to Agile to... So, and then the last thing I'll say is that, you know, I mean, there are a lot of DevOps people, actually a lot smarter than me that are hanging out there that you just need to, you know, I've been lucky enough for guys like Colin and Brent to tap me on the shoulder and say, hey, can you help us understand this a little bit more? Like there's a lot of us out there and if you're a network engineer or you're somebody who wants to get your network engineers to start understanding this, go tap your network developer. Explain to them not to be cocky, though, because, you know, not on... And I always say that, you know, don't let your enthusiasm look like arrogance. You know, you gotta be real careful there. You know, you don't come in and say, oh, you're idiots. You know, you could be doing that all with configs. Like, well, no, I guess I'm really complex for auto protocol definitions. You know, make sure they understand that. Anyway, I'm done. Thank you very, very much. Thank you.