 Turn it up. Okay, there we go. I said, how's everyone doing? Who's got DevOps all figured out? You got this? You got assorted? No? Well, this should be fun. How many working a little company start up? How many working a big company? Big company. Okay, so this should be fun. I got a little something for you, hopefully. All right. I was kind of introduced, but I'm going to talk a little bit about myself just really fast. So, Andrew Clay Schaefer, I've been doing startup stuff since like 10 years now, venture-funded startups. I've been involved in a bunch of open-source projects. Right now I work for Pivotal on Cloud Foundry. I also wrote a book for O'Reilly on web operations, which even though it's almost 10 years old and maybe slightly dated, it's kind of stood the test of time. I think it's one of the best DevOps related books out there. I'm also going to talk about another book today, and if anyone knows what artisanal retrofuturism crossed with team-scale anarchical syndicalism is, come up and explain it to me, and I'll buy you sushi later. And I've been, I've been one of the core organizers of DevOps Day since the early days. I'm not as active as I used to be. Thankfully Bridget has picked up that mental and keeps going with it, but as I'll, as was mentioned, and I'll kind of come back to you, like I've given a bunch of different talks through the years. Some of them have been technical, some of them have been social, and then I want you to realize this is the most important slide because it has my Twitter, and I really need you to engage with my brand. It's very important, so go ahead and do that. And then I also learned last night that for the DevOps Day's organizers, I'm known as the werewolf guy, which will also probably try to solve that problem by the end of the day, but yeah, it's a long story. If you don't know what werewolf is, I'll solve that problem for you as well. And then last but not least, again, engage with my brand as you can through the day. This is to remind you that next time you see me, I might look very different because these are all pictures of me in the last five years. So next time you see little idea in the wild, it might be a completely different creature. And this is a short list of some of my greatest talks. I'm also available for weddings, bar mitzvahs, anything like that. So if you guys have other things you'd like me to show up and reprise some of these talks. And then last but not least is not the last joke, but this is actually hilarious. If you don't know what that means, I'll explain it to you later. It's in some of those other talks. But for today, all you need to know is is a Nash equilibria. So what a Nash equilibria is, and this is he won a prize for this. Has anyone seen the beautiful mind? So this guy's fascinating. His dissertation is 27 pages long. It has two citations. One of them is to himself. So that's pretty awesome. So what a Nash equilibrium is is in a game in a game theoretic mathematical context that at the equilibria, no players of the game will change their strategy. So you reach these points in a game and they're actually path dependent. So some games will have more than one equilibria. But if you reach a point in that game where you're at the Nash equilibria, no one will change their strategy. Does that remind you of work? And then one last little thing because I think it's adorable when people in Denver like to say they live in the mountains because the mountains are like way over there. And that's my hometown. That's where I grew up. And I lived in the mountains. So just just keep it real Salt Lake City represent. All right, keep going. So where are we? And how did we get here? No, you guys aren't in the mountains. It's cool. It's fine. So this is a blog post from O'Reilly Radar in 2007. Okay. Has anyone ever read this post? Operations is the secret sauce. No. Wow. The young kids man coming up. You guys got to go back and learn your history. So this was written by does anyone know who Jesse Robbins is? Yeah. So so Jesse Robbins at the time he wrote this, I believe he was still employed by Amazon. And he was the master of disaster doing opposite Amazon and they call him master of disaster because they did all these kind of like disaster scenarios. And he really liked doing that. And he's also big into firefighting this kind of stuff. So he wrote this blog post and the distilled argument it's worth reading. And I also wrote another follow up to this in 2010 about how you can frame the difference in these two graphs is technical debt, which might be interesting reading for you as well. But basically the argument here is that on one side you have traditional operations on the other side you have whatever this new secret sauce way is and that the area under the graph represents the amount of hours that humans spend doing work to scale up the system. So on the x axis we're talking about scale. So as you go through and build larger and larger systems, if you're building things the traditional way, then the amount of time that humans have to spend, the hours that they have to spend to make those systems work goes up at some curve. And if you've done it this different way, this new way, then that curve is much lower, sublinear. With me? Does anyone believe this is true? Does anyone live this? Who still lives on that side? Don't raise your hand, it's fine. So we've been saying this for ten years, right? And everyone wants this DevOps thing. And to be fair and to go back and kind of reprise some of the things I mentioned about myself, DevOps has been very good to me, right? Like I basically have spent the last ten years traveling around the world trying to help people do this better, trying to help people do this better with better tools and better processes, right? And that's, like there is better things happening. But we've been saying it for ten years and I'm actually, sometimes I'm discouraged by how little progress we've made, to be honest. So are things getting better? Are things more confusing? Are things done changing? So this is actually a blog post summarized. This is a blog post I wrote in 2010. So DevOps is a word when I wrote this and there's a kind of group of people that were sort of writing what it meant to them. And this is sort of my distillation from 2010 of what I believe DevOps is and I still believe this actually. And I'm going to talk about it a little bit more. But to me DevOps is this idea that developers and operations can and should work together. Because there's this old world where they don't for some reason. And there's a bunch of things that contribute to that because for a large number of organizations they evolved where they weren't really delivering services, right? Like CIS admins were the people that kind of kept the mail and the printers and that kind of stuff. And so when you change to get to the value stream actually runs on the servers, that dynamic has to change drastically. Or you've got critical problems with your value stream. And then, you know, this is a big part of some of the stuff I worked on at Puppet. And obviously the tools have evolved a lot since then. And now there's things, you know, there's this there's like this cavering explosion of tools, right? And a lot of them are here to talk to you about their tools. But the general theme is that system administration is evolving to look more like software development, right? So I have this API that I can write to do provisioning. I have API I can write to do configuration. I have API I can write to do monitoring. I can have API to do all these other tasks. I have APIs even to do postmortems now, right? And when you're writing against APIs that looks suspiciously like software development, right? And then last but not least, and I think this is in some ways the most powerful is that in 2010 that I as a person who I lived in Salt Lake at the time, I could I could have conversations online, IRC email, IMs with John Ospa, with, you know, Jesse Robbins, Adam, Luke Kines, all these people that are kind of seminal actors, Mark Burd, it's all of them, you know, Archer Bergman, right? The people that wrote the software that you're using are available to you if you understand how to participate in these global communities, right? And who's in Slack channels or IRC channels for their favorite open source projects? Aren't there like these amazing communities of practice that will share everything they're doing with you pretty much all day every day? That's amazing. So this is another thing that I think I've attached to I like this framing. It's from John Willis and Damon Edwards. But I think it's, I'm going to come back to it at the end, but basically it's a nice way to think about all these kind of interconnected things that we do and we talk about. But to me, and who's ever heard software is eating the world? Who's ever said that? To me, that's kind of the major theme here is that we as a community, we're optimizing human performance and experience operating software with software and humans, right? Does anyone do this? Is anyone trying to do this? Who wants to get better at operating software? Yeah? Who thinks they can do that without software? Yeah? So this is something that I actually had in slides over and over since 2007 I think, 2008 for sure. So you can either manage these kind of systems at scale or you can't. And when I first put this slide up I was talking about puppet, but now both the tools and the scales are just like off the charts, right? I've been using this slide for the better part of a decade and we're still kind of in most cases like a lot of people are running Bash. Who runs some janky Bash scripts from their home directory? Anyone? I have. You don't have to raise your hand. I'm just, you know, protect the guilty. So everyone wants the DevOps and there's a will actually there. What they really want if you ask most organizations is they want scalability. They want availability. They want reliability. They want operability. They want usability. They want every possibleility you can think of. They want it all for free and they want it without changing anything. Right? And when I listen to a lot of people or really like certain things I think there's a lot of missing context and I don't know why this slide's here but I just had to put it in there and I'm not really sure if these are the good guys or the bad guys but it's pandas vomiting rainbows and I just can't deny that. I got to put it in there for you. So I feel like there's a, we add to the confusion of what people are trying to do because there's lots of people giving advice about things that they've never actually done and or they have motives for why they're giving you the advice that you're giving you and just never forget that marketing ruins everything but welcome to DevOps days. So in my blog post in 2010 I talked about evolution like this evolution of software development and operations and so I kind of want to come back to this theme of evolution and I got a bunch of little sub points I want to make about evolution. I actually have a water. Who has back problems? Serious problem. Alright. Has anyone ever studied biology or evolution or any of these things? Is anyone a creationist? Sorry. Close your ears. So there's this notion in biology of punctuated equilibrium and what that means in practice is that in the fossil record you don't see this gradual evolution of species into new species. You don't see that at all. What you see is long periods of stasis where the same species are present for extended periods of time and then completely new species like are present and maybe some of the old species are gone. So evolution in the fossil record comes in sudden jumps and extinction events. So going back to my look because I like to rub game theory on too many things. And it's frustrating also because like most people don't understand game theory or math at all but it's cool. The natural equilibrium of an evolutionary process of a species is basically that you're going to keep playing the game the same way that you thought you should because that was the game that you played. That was the rules of the game but the game actually changed. So you see in the evolutionary record, the fossil record that these punctuated equilibrium, the transitions between stasis at one layer of species to the stasis at the next layer is often accompanied by some sort of geologic event. Something that changes the actual game. The rules of the game change so the strategies that were optimal or stable at a certain point in time have changed. Does that make sense? Let's talk about organisms. What are some organisms? Everyone knows what this is. You guys have high school bio? This is a representation of an animal cell. For the most part, I don't really want to argue this point but there's some evidence to suggest that all things that are alive evolve from one cell or like some single set of cells. And the evidence for that is the mechanisms, the mitochondria. You can see kind of this branching of evolution as it happens. And one of the things I want to, I'm going to come back to this point at several different scales but I want to point out like how there's distinct structures inside of the cell. It's not a homogeneous environment. And each of those structures has some responsibility to the system operating properly. Operating properly. Operating properly. You can't just have this mass that has no distinct roles or structures. There's definitely things happening. And then as you move up in scale, then there's, and we couldn't go through the whole evolutionary tree in the 30 minute time I have but I'm going to go to humans because I have a fondness for them, that humans have identified 11 major organ systems in humans. And there's probably some subtle systems we don't really understand even. Like we're barely starting to understand things about the subtle nuances of electric fields and how they interact with these systems. We're pretty good at structures. Like we've identified these kind of structures and some chemical signaling between all these things. But those things are distinct. They're not the same. And these are systems of systems. So one of the things I keep running into that the mode made me to bring up this point is there's this notion that we need to tear down silos. And I don't think that's wrong in some context. And I understand the point that people are trying to make when they say that. But in reality, you have different functionality. You have different responsibilities. You have different accountability in these systems. And if you think about this from a biological perspective, then an undifferentiated mass of cells without any clear structure, without any clear responsibility, without any clear signaling is actually cancer. So don't think that you just put everyone in one big pile and don't have roles. Don't do that. So another point I want to make, I'm going to go back to organisms, is this scale literally breaks everything. So who's ever seen one of these? These are everywhere on the whole planet. Some variation of these things. So this is an ant. And ants have some very interesting properties. One of the things that ants share with all insects is that their respiratory system is basically pores in their exoskeleton. And they transfer oxygen through the exoskeleton because of the just basically ambient passage of the oxygen in the atmosphere. We'll come back to that in a moment. So these ants have a bunch of other properties and you could list, like, I could spend a whole hour talking about how fascinating ants are and all the things that they could do. But just to kind of frame it so everyone knows that ants can do these things, right? They have exoskeletons. I was reading when I was looking for some facts about this, that you could put up to 5,000 times the weight of an ant on its head before its head will come off. One, that's fascinating. And two, like someone actually did that science. So just put that in your little book of trivia. Now, on the other end of the spectrum or another end, there's obviously a lot of other choices. This is an elephant. Elephants are a different end of the spectrum. They don't have an exoskeleton. They have lungs. They have heart. They have, you know, probably very analogous systems to the human systems. They also, they also spend a lot of time eating, right? They also spend, you know, compared to an ant in the order of time eating. So what about an elephant-sized ant? Could you have an elephant-sized ant? In fact, you can't because you have this little problem that the properties of materials and the strength and the, you know, different characterization of the cross-synchinal strength of muscles versus your skeleton versus exoskeleton is different. So when you have something that has this ratio problem, that the strength of it or the property of it increases at some number and another property of it increases at some other number, then you can't really apply things at one scale to the next scale, right? Does that make sense? So this is the square cube law that dominates many things, but it definitely dominates this evolution of biology, which in the physical sense, if you scale something by some number, so say you're going to make it twice as big, then you made the surface area a square proportional to the square of that scale and you made the, there's no way I've done it in five minutes. That's not when we started. So the other property is the volume, which is going to be scaled or it's going to be the cube, right? So elephants and bones, if you study even the difference in the vertebrates and the mammals, the difference in the size of the bone relative to the mass of the body as you go from a mouse to a bird to a human to an elephant is different to accommodate for this scaling property, right? So an elephant sized ant would require hurricane strength winds to get enough oxygen and would most likely die immediately as the internal organs crust each other on the first attempted movement, right? So maybe ants aren't the best source of advice for elephants, right? And what is the organizational equivalent of the cube square law or the square cube law? It's listed both ways in the literature, right? And there's a bunch of things I could think of in terms of how nodes in a network communicate, right? As you add more nodes, the amount of overhead that is required to coordinate the nodes with each other goes up at a different number than, and this is why sometimes things that seem like a good idea or a good process at one scale totally don't work or they need to be accommodated at a different scale, right? And I don't think we're very good at recognizing that or discussing that in our community. So another thing I want to talk about in terms of evolution is there's all these buzzwords, right? Everyone says these buzzwords. Anyone ever heard any of these buzzwords? Said them? Yeah? So what I believe very strongly from my participation in the observation is that these are actually all one thing. These are a single dominant emergent paradigm for how IT will be, will be delivered. Like the next generation of computational infrastructure and applications will be delivered with this new paradigm. Like that's happening. And this is the game literally changing, right? So continuously devops microservices or die trying. So I want to come back to this notion of sharing. And this is something I've recently read. And I think it's amazing kind of act as a place to start, as a place to see what's going on. And this is the site reliability engineering book from Google, which you can actually read for free online. Has anyone read this? So I'm going to give you a little homework. But basically this is DevOps as she has spoken at Google, right? Google TM. And I'm not going to argue that Google is the best at every possible thing. But where's your book? Right? Like what did you write? The fact that they've taken and distilled and shared this volume of Google's state of the art practice and the evolution that they went through to get there is a gift to the world. So the homework that I have for everyone is to read these three chapters from the SRE book. And you can do it for free, it's going to take you half an hour. So embracing risk, service level objectives and eliminating toil. I think this is one of the best possible framings that you could take and practically think about. But the other thing that comes out from this book, watching Google give the anecdotes and how they evolve to get to the point where they are now is that Google is an organization that changes. So this is from other talks I've given, but I want everyone to always remember that you haven't learned anything until you change your behavior. New information is useless to you if you don't change your behavior. If you're talking about music, you're talking about sports, you're talking about chess, you're talking about anything. If you can't actually change your behavior from the new information, you didn't do anything. You didn't learn anything. You're just collecting trivia. You might as well go read, you know, Hacker News. So these patterns that are proving successful building and operating these systems are highly available with predictable scaling and failure characteristics. They're very common. So Google wrote the book, but you can see very similar patterns in the web operations book that was from 2009. You can see very similar patterns if you talk to people that work at Facebook, Twitter, Amazon, you know, definitely people in the DevOps community. And so I'm kind of fond of this quote from Leon Tolstoy, who is one of the original DevOps people, is that, happy DevOps are all alike, but every unhappy DevOps is unhappy in their own way. And I said I would come back to this notion of calls, but I feel like right now the conversation is sort of stalled because this is too blunt of an object. And we aren't really good at talking about what culture actually means and how to think about changing culture, how to think about changing automation in this meaningful paint by the numbers way. Like I can grandstand and a lot of people can tell you, oh yeah, you got to have culture, you got to change your culture. But it's not practical for the elephant because most of my time in startups I'm an ant. There's a lot of things that you have to be able to do in your context. So there's very much about it depends, it depends, it depends. So we desperately need to be able to understand and act on these different aspects of DevOps, just because it's a nice framing, at different scales in respect to interconnected social technical systems. Because we're all people and we're all technology and it's all mixed together. And right now I feel like there's a lot of confusing conversations also because not everyone has the purist motives. So this is an organizational learning dynamic process that I just had to put in here because I think it's a nice way to frame the scale. So you think about when you build a technical system, a system of computers that there's phase shifts that you go through and that the thing that works when you're one database and one app server doesn't necessarily work when you get to 10 or doesn't necessarily work when you get to 100, doesn't necessarily get when you get to a thousand. And that same type of phase shifting and scaling has to be applied to your organizational dynamics as well. And there's these emerging patterns that we could copy. But you also have to, you also have to take it on yourselves as individuals to bring your level of understanding to the organization. And the organization and the individual are connected, right? So there's the, I didn't put this quote in here, but it's a Rudyard Kipling that the strength of the pack is the wolf and the strength of the wolf is the pack. Like all these things are one. But also as you move through this learning and you institutionalize things, I think it's very important, and this is stuff I put in slides going back to 2007 as well, is this notion of flying by the seat of our pants. When you are building the future, when you are building technology that is the edge of what is possible. There is no school. There's nowhere you can learn how to do that. Right? So you have to do that with your, with your human creative capabilities. And then, you know, sometimes you fail too, right? Because that's the evolutionary pressure. But once that gets codified, the game's actually changing as well. So you never want to stop flying. I don't, right? Maybe, maybe in certain organizations you don't want to live on the bleeding edge, right? Because the problem with the bleeding edge is there's a lot of blood. But some people like that. So my advice that I gave in talks since 2007, depending on who you are and where you work, and you know, if your, if your goal is to bring home a paycheck and like spend time with your family, then you might have a different game that you want to play than, than some people. But if your goal is to build the future, then you need to keep flying by the sea of your pants. And, and, and re, re imagining what is possible and changing your behavior to play the new game. Right? And that will, that will pay off as an individual. The opportunities that you have, stagnating or not, are going to change everything about how you get paid, what you could do. Has it, has anyone got a raise because they learned some DevOps still? No? You guys need to go there. There's this thing called the Internet, which I'll introduce you to right after this, where you can learn a lot of stuff. So coming towards the end, no one originally set out to do DevOps, continuous delivery microservices. These were natural consequences. It's Darwinian pressure that created the, the, the processes that you see emerging at, at these places like Google. Right? Like, they couldn't have built Google some other way and Google stands in existence proof that you could build Google that way. Right? So don't fix it on any of these words. Like, if someone is telling you we have to do DevOps, just tell them, like, we have to win. Like, we're not here, we're not here to be agile, to do DevOps, any of these buzzwords. It doesn't matter. Are you winning? Are you helping your business? Or are you not? And these problems are not about a tool. And it's also not about all people, right? Because I think there's a pendulum between, like, focus too much on tools, focus too much on people. It's all one thing. You have to solve them together. We have to solve them together. So in conclusion, the game is still changing. There are lots of options to change. Extinction is one. Things are not as confusing as some people would make them. You haven't learned anything until you change your behavior. There are good examples. There are people that will share with you. Change is your opportunity. Change is our opportunity. And I believe in us. And then this is a fascinating quote. It is not the strongest of the species that survives, nor the most intelligent that survives, is the one that is the most adaptable to change. And it turns out there's no evidence Darwin ever actually said this, which is also fascinating when you think about how ideas and memes propagate through human culture. So what happens next? Change. And I feel like we have the opportunity to create that. And this is the end of the beginning. And last but not least, I work for Pivotal. We're building a lot of software. We help people do it. If you're looking for a new hobby, you should come talk to me. And that's the end. Thank you very much. The end of the beginning. So I don't know if Jason's coming back. There we go.