 So how's the cloud foundry summit treating everyone? Yeah, so far so good People are trickling in so I'll I'll go slow so this is a talk about a lot of things and I Usually give a disclaimer that we're going to go really fast. I have 30 minutes supposedly but I'll probably go long and I'm going to go through about 90 some lines and some of them are Some of them have more bullet points than others, but The main thing I want to do is take you on a little journey tell a little narrative and for some of you I'll relate to things that you've experienced in your career maybe on similar arc or observed from different personas my career so far I've kind of spanned Many different roles inside of IT as a developer as this admin a founder of a company and just thinking Really about how all these things fit together So the alternative title if I can get this thing to change there we go is Systems thinking is the new black Just by any show of hands did anyone come to last year's summit at the at the Hilton? Okay, how many people saw my talk? How many people saw it on video so this is all this is all online, but the Ideas in that talk I think are our key to actualizing some of the things that you're going to see in this talk and also Some of the things you're probably trying to do inside of your organizations I definitely has so it has a bunch of information about organizational learning and I use the stone cutter metaphor so this is another alternative title and this is a stone cutters quest for nice things Do you guys recall the the morning session with Sam we're talking about the I Have a slightly different version, but it's basically this idea of connecting to a higher purpose No, or or not right like there's different levels of understanding of your craft And the lowest level is the stone cutter that he gets paid to cut stones Right. He knows that he can make You know food for his family because he cuts stones. He has a skill And then the second level is the stone cutter that is He's just fascinated with the actual Craft right like if you ask him questions, he'll get excited about how how the stones are laid and the tools and you know How the servers are configured with this one configuration management tool? And then the last one is the one who's connected to this higher purpose of the cathedral so this is our lowly stone cutter and You know my career and I'll just go through this really fast But I've been involved in a lot of startups and we're gonna actually talk through some of that Most people know me from puppet I did a lot of work early days especially on open stack and then my my background we're gonna go through a lot, but I Did some writing for O'Reilly this is a little book I helped write on web operations and there's a lot of great stuff And I'm packing my house to move to Los Angeles from Pittsburgh and I came across this book just this weekend and I read I read this book and it's from 2010 but it's really stood up you know and we're five years out from that and anyone who's Interested in really building like a new future and we're gonna really see a lot of the ideas They're embodying that book, but it's a great reference if you're interested in devops and operations and really managing the stuff at scale And then I've been involved in in the devops movement and we'll talk about that a little bit I've been on the core organizing team for devops since the beginning of devops days and we organize You know dozens of those around the world now and if you've not had the opportunity to participate in the devops days Then I think it will really be eye-opening to see the communities of practice that come together and openly share the information and this This whole thing is very similar like we're trying to build a community of practice around cloud foundry but traditionally a lot of the a lot of the organizations that are quote-unquote enterprise they they tend to They tend to hide information They often hide information from themselves Internally, but they they try to hide information from each other Where one of the things that you saw in the devops communities is even though people are working on you know on face on some somewhat competitive Services that they would often share the the way that they were solving these common undifferentiating problems with their infrastructure And then I work for Pivotal I don't know if anyone needs a job. We're hiring Yeah, and then I try to amuse myself on Twitter and it might amuse you too But I'm little idea and that's probably the fastest way to get my attention Even if you work with me and have my email Which I'm usually about a thousand emails behind on All right, so if you saw my talk last year, this is funny Three stone cutters walk into a Pareto inefficient Nash equilibrium go watch that talk and you can laugh later I'm not going to talk about cloud foundry What I'm actually going to talk about is all the stuff that kind of is around cloud foundry and by by relief by the The way that that silhouette doesn't will kind of have cloud foundry left over that makes sense So I like to do this still let's start with the conclusion So there's a bunch of buzzword bingo crap. They're like Gardener publishes and everyone does and some of the words mean something and some of the times they mean different things and different people And you get into all sorts of strange conversations if you don't start each conversation with the definitions Like for this conversation, this is what we're going to be in this way and that's that's fair. That's fine I'm not gonna argue. This is really just one thing that DevOps continuous delivery microservices like these are all really part of the same phenomena that's happened And these things are enabling these things are dynamic these things are not really finished and What we're able to do today will really evolve rapidly especially as as these communities Cooperate and drive that innovation forward and we can come back and we'll we'll have a little bit more definition around each of these words by the end The first thing I tell you story about me all right, so in the beginning Well, not the real beginning, but I Got a job as a developer. I had a job I was I had a degree in math and I had a Myron CS and I had a Professor he is a theoretical chemist and he wanted to have this project And he's like, well, you can you do this and I was like, I have no idea how to do that. Yes so he gave me like tiny bits of money and and I was really smart and I had Google but I really had no idea what I was doing right, so I Was sort of left to my own devices. There was this half cobbled together idea that this Grad student had sort of implemented for this guy his his his vision was he wanted to build a Way for these theoretical chemists who were redoing a lot of the same calculations over and over To share the these pre-calculated chemical kinetic and thermodynamic From first principles and so this idea was his original idea was he wanted to have this database So you'd have this database, but you were going to ship these like kind of synchronized databases Across the community, but that's a terrible idea when you could build Online system and this is right around it's like 2001 so you're starting to see like the internet stuff come online And I was like well, how about we build it as a web service and I convinced him We should do that and I learned how to do a bunch of stuff With my my little red JSP book and my Google like I was able to build a bunch of stuff. So I did this With a no experience and really no one teaching me how to do it. I didn't know anything about testing. I Didn't know anything about back if I didn't really know anything about service So I was like learning how to configure, you know a patchy to do the Whatever things to set up the the Tomcat thing to set up this other thing And then I'd go write the little bit of code and I just kind of make this thing work And it was just me and my server that like served the website off of my desk literally and and it was just like I made it work it mostly worked and It worked enough that the guy got five million dollar grant to like make it real like more real and at the time He is paying me like nothing right so and and everyone's make a ridiculous amount of money doing like the same exact kind of Technology so I had a conversation where I was like I think you should pay me more than nothing and and he is like well you know and and I think in In academics like people are really used to slave labor for some reason so So he's like well, you know maybe and then there's all this stuff going on and there's all these jobs And I was like well I think I should go do is go work for someone else because they'll pay me more money You know I'm looking at the job postings and in between that conversation and the date that I set to leave They have September 11th and Then and then no one would talk to you after that like it just basically like evaporated So there's no there's no work and every job that was posted had you know hundreds of resumes and You just you know I it was it was ridiculous though because you you get in these conversations with the hiring manager And I was trying to I was always trying to be proactive or you know I'm getting better or worse at that depending on how you look at it as my career goes along But I rode out to this guy. It's like hey, you know, I'm trying to try to make my way Like can you give me some advice on how to do this better? What about my resume? He's like well, we had all these things, you know hundreds of them And we're only gonna interview a dozen people and and so we decided to interview people that only had you know People anyone who didn't have a 10 years experience in Java. We didn't interview them It's like hmm. It's 2001 Java came out in 1995 Good luck So then I went to hide I Went to hide from the economy. So this is around 2002 And I went to grad school and I did a program at University of Utah called computational science So it's basically envisioned as this bridge between the computer scientists who didn't know how to do math and the math people who didn't know how to do computers and What I specialize or what I focus a lot on is building these bioelectric fields models of bioelectric fields And so we build the these torso models with like the tissue and the anastatropic You know resistance and conductance across the tissue and then we would do these visualizations So I t a this class to do visualization of the bioelectric fields in in that lots of stuff. Anyways, it's pretty fun Did anyone go to grad school? Did they wish you were perpetually in grad school? If you could make money doing that back to that slave labor thing But what I learned there which was formative is this idea of technical debt because this Thing called ski run, which is you could go see it. It's how you would you'd be able to make these types of visualizations It was a project that had a five-year grant for like millions of dollars But the way that it was architected was this where Conway's law comes in which is does anyone know Conway's law? I use it like every talk So I start to assume people know it is so Conway's law is this idea that organizations will build Systems that mirror the communication structures of the organization Right, so if you communicate in a certain way like often this is this is true in almost every product I see if you see API level problems Then if this group doesn't talk to this group very well Then you're going to have that problem like all the time so in in this project Although I did learn to use a source control you had a project that was this long-standing Grant where the majority of the code was written by a grad student Who was only there maybe working on it for a year? Right, and so like over a five-year period You can imagine that all their incentives and all that communication was perfectly aligned with building great software It's what I like to euphemistically refer to as academic see And maybe some of you have seen or written some of this code before But there was really really no what I would consider very mature process and in most cases There's very little regard for the future It's like you have some little bit and the parts that I worked on were mostly about Doing algebra so that people had implemented a bunch of naive ways to do matrix multiplication and so I basically replaced it all with the The Fortran Lee pack libraries and did a bunch of stuff with that So I was mostly focused on the math part, but it's super fun and Then I graduated my wife started medical school, and we had our first son in about two months span So that was the end of the rock-and-roll lifestyle clearly and and she decided that I should get a job and and try to feed us and I sent I sent out some Resumes and put one on dice.com and then a recruiter called me and he's like will you go to this interview? And I was like sure he's like on your resume. It says is BTK which stands for visualization toolkit And they need someone or they're looking for someone who knows GTK So that's that's pretty close So so go talk to him. This is a true story so So I go to this this group and I spent I Was there probably 40 minutes and I talked to two people and one guy was in charge of marketing And what they were advertising for what they were looking for at the time was someone to come and work on user interfaces for this device I'm gonna show you a second and they had a bunch of ideas about how that should work and they had someone who didn't know how to code that was trying to work on them and They're just kind of desperate at that point And then I I'd been working on user interfaces and usability with respect to visualization and I started I have a I don't know character flaw But I get really fixated on little things and I want to go like find out all this stuff And so I got onto this stuff about usability and Jacob Nielsen and all these people are like right about usability and UX You know going back decade and so I was you know way into like all these ideas about how to do this And so they got excited about that and then I went across the hall and I talked to the VP of engineering and the VP of engineering is like Looking at my stuff, and then he's like so you've been doing math models of bioelectric fields in the torso of a human and then Aren't gonna be bored working on user interfaces for like our crappy little device And I said I am pretty good at entertaining myself He said come back on Monday, so So I joined this adventure where we we spent 26 million dollars Had really nothing to show for it at the end Except for this Wikipedia article which you can go read if you look up black dog and realm systems So we had this little thing we've made the boards We made the we had like a custom kernel that ran on this thing all the way up through this operating system this is some of the specs for the device and we had this big vision about solving identity and We were actually doing some things that are very Much the same problems that everyone's trying to solve with the kind of IOT It was like you had a provision this thing and what we did was build a on the fly Debian packaging of the policy So your administrator could configure all these things that you're supposed to have access to in the back end And then it would make an on-demand Debian package of that and then when your key got online It would download just the things for you and it was like it was fun And it was one of the best It's one of the best engineering teams I ever worked on and it was really formative for me So I worked with this guy who wrote the book on make like he literally wrote this book on On GNU make and he taught me a bunch of things about how to think about problems and it wasn't so much like do this Do this do this it's like you should not implement something until you thought about three ways to do it, right? You should you know like you should test these things and he had I had a One time I was because we were cross-compiling these things for this little chip on our Linux machine So you and it's funny now because everyone's all excited about containers But we were have these like charude environments to go build this stuff and like put it on to these devices And he and he's like you're not testing your code for this interface for this other thing And I was like it's impossible He's like no, it's not and it was like it's impossible. I tried. It's like, okay, okay I'm gonna come and we're gonna pair and we're gonna make it work. I was like, okay so he came over to my desk and After like literally two hours one day of like trying to get all this testing Like anywhere is boost and C++ to like do this thing and and test it and he had like these high aspirations And finally he's like he just tapped out. He's like fine. You don't have to test that. I was like, I wanted to I really wanted to couldn't do it but the thing that was interesting here is it was like perfect display of call always log in and There are all these little kind of Game of Thrones ideas about the different teams and everyone on this thing And I kind of broke it accidentally because I was working on this like C code and like platform code on this one side and then there's this Java side where they did the actual server stuff to do the configuration and I'd implemented a bunch of stuff that needed to have the server put together those configs and then push them to the Devices and I wouldn't talk to this guy, you know for weeks or whatever and he's like You know, oh, that's awesome. That's awesome I was like, well, when do you think we're gonna see this system work and 10 and he's like, well, it's not in my sprint It's not in my stories. It's like what the fucking talking about Why do you think I spent all this time explain how this work? Like don't you get this like we sit and we hear the vision for what this proc supposed to do like why aren't you connected to this cathedral we're trying to build and then So my solution was basically to just go implement it on the on the Java server Which made everyone mad Well, not everyone it made some people very happy because now this thing worked But it made the people who thought that that was their code very unhappy and then as a result the The vice president of engineering decided it was it's better for everyone to get work done and I have this ownership So he dissolved all the teams and everyone just became one pool and then then it was like a free-for-all for me I was like, I'm gonna learn how the kernel works and like I could go do that stuff And then the next week I just grab a story from you know, whatever part of the system I wanted to so that was a Really rapid iteration of my leveling up on how computers work and and there's you know stuff that I wouldn't have been able to do inside of another Organization, but one of the things this did for me is like I disassociated my identity From any aspect of anything right like I don't care if you're a sys admin or you're a developer or your Java guy or a C++ guy like it's just it's just something you just do Like you want to make it work you make it work right and like if you attach your identity to things I think that's limiting and it's and it's bad and that kind of comes back to play in the in the DevOps story so then The next thing that happens is that company runs out of money and they go from basically a hundred people Down to 15 people in six months and I was in the layoffs between my friends who were Getting two weeks severance and my friends who miss paychecks. So like my group was just hey don't come back and then but I didn't ever miss a paychecks and Well, here's another aside because we we developed all this expertise on flash and the team that we worked on there is They eventually built a fusion IO I don't know if there's anyone know who Fusion IO is So that so I would have been to pay on when I signed I would have been like the fifth to the ninth employee of Fusion IO and But the deal was they're like hey We know you just unraveled and like you didn't get paychecks and like your friends didn't get paychecks and then We might be able to pay you in nine months when we raise money Or these guys across town who just raised their five million dollar a round and they're like we'll pay you a six-figure salary So that was a really easy decision for my wife to for my wife to make I'm losing my mic I think oh, no, that's just the card if everyone can still hear me Okay, so then this was kind of the opposite So the the first team I worked on was a dream team from an engineering perspective And we had this deep expertise across a wide bunch of things but we had this pathological understanding of our business and In this other startup we had actually a very clear business mission and we had pathological technology so we had a CTO who had a CS degree and Had never worked for anyone had never had any mentoring who could type a hundred and twenty words a minute And he could fix any problem in the universe with another if or six And so that was that was the code base was like this his specialty was the if else Plinko is that It was it was in three places across JSP's and code the if else Plinko had to magically Construct the the string that got put straight into the JDBC to call the database and then come back out And then you had to have the same if else Plinko to recover the result and then yeah, it was terrible. I had a contest once at a conference about who who saw the worst code ever and You know after about an hour into this this meal everyone was just tapping out. They're like no Lee when and I wasn't even to the good parts yet Like it was it was amazing. So what I learned there is Kind of opposite lessons, but I was I was really empowered It was like one of the first places where I wasn't just a developer like Austin I could do do things that other people couldn't do I was able to I was put in charge of a bunch of stuff because I Proved I could solve these problems really rapidly and then the the CEO kind of He couldn't he couldn't Undermine his CTO, but he kind of knew they were in trouble And so he put me in this position to to act as like a check-in balance and then I learned a bunch of stuff about Team dynamics and and more Conway's law, but what we'd built looked suspiciously like like this rubric Goldberg machine And we had a lot of automation. I mean we're deploying at that time. This is like 2006 ish our our infrastructure was roughly like 50 servers each of those were like a cores like they're they're pretty beefy servers for the day and We were doing about 30 million dollars in revenue or not revenue, but transactions through it And we were taking like a small piece of that So this was kind of how we did stuff like we had I didn't know anything other than what I'd learned And most of what I'd learned wasn't really about doing these large-scale deployments on servers Up to that and those aren't really large-scale in retrospect, but we we shared a bunch of stuff You know, there's the the do it now dot sh Do it now dot essay or do it now five, you know Like you just keep like changing things and you share them and this is kind of what things look like And and so that that story that narrative is really you know every day you go to work And if you did a deployment the night before then you're often Greeted by a bunch of emails from your East Coast clients who hadn't been able to do transactions on their e-commerce store because You've broke the way check-out works or something and this was a pretty common Has anyone ever lived this movie? So as it turns out my roommate from Reed college was Luke and Luke had already sort of thought a little bit about this and I Had been part of the puppet Community and I'd made some commits to it But it wasn't really a business yet and it was you know as I told you bit more of my story It was kind of hard to convince my wife that the the way this should work is I'm going to go with my roommate from college And we're going to make software and we're going to give away for free And it's going to be awesome. It's going to work out Well while she's doing her 80 hour a week medical school stuff, but the thing that that really happened Mentally for me is and a lot of this I'll give you know credit to Luke's perspective and there's a ton of people influenced How I think about this stuff. Some of them are here and I'll get to velocity in a minute But we really wanted to change the relationship between people and computers We wanted to change the way that people thought about their computers. We didn't want to have the do-it-five As the way that people thought about it like we wanted to get it so you could Consistently manage these complex systems at scale in a way that you know, basically very few people outside of some of these other Organization I'm going to talk about in a second. We're able to do But what turns out and this is part of the Cloud Foundry story is you actually need to change the relationship between people and Other people as much or more than you need to change the relationship between people in the computers because going back to Conway's law If you have a bunch of different ideas about how the world works Then you're probably or God forbid different incentives Then you're probably not going to do the greatest job with your computers So this is the this DevOps story Everyone's read the Gardner report on DevOps and how you need to change your culture But I don't think you can really talk about DevOps if you don't talk about velocity and I'm gonna I think I'm gonna bring up some ideas that people haven't thought of it before at least not Articulated and this is a conference that I consider the first DevOps conference This is certainly a slide that was was This is from velocity 2009 John Allspa and Paul Hammond giving the talk about 10 deploys to Tim deploys per day at Flickr and they had they had these slides and For some of us who kind of been around them and been around this conversation. It was just like oh, yeah You know Paul and John they like do this thing and there'd been a bunch of these threads But for people who'd not been in that world who hadn't thought this way hadn't seen this stuff is like And we'll come to more of that This is actually the first recorded use of the word DevOps and these are from that session at velocity And this is my Twitter. So this is a July 3rd 2009 I just cut in pace of that image from Twitter this morning and The you know, we're having the same conversation, but this basically hasn't really changed since then It's just it's propagating through the rest of the the industry but the thing I want to draw attention to with respect to em or a velocity is velocity was started as a Guy from Amazon and a guy from Google as The chairs putting together this program around web operations and performance And what what that represented was as I mentioned earlier these communities of practice coming together and sharing their Ideas sharing their successes sharing their failures You know that some of the most interesting things and this is interesting especially in a culture where it's very Blameful that that you do you share your your failures, right? You let people understand how you failed so they don't fail again. So they don't feel like you But everyone everyone hears about Amazon and this is bookstore. You got has anyone ever ordered anything from this bookstore? My wife gets like three boxes a day from Amazon But this is this is the last public thing I heard them say and this a couple years old now But according to my sources, this is actually in order of magnitude off now So they're they're closer to a deployment every second You know, they might not say that out loud, but that's that's roughly what I would imagine But then you have to understand and we'll get to this in a minute is that's not like monolithic deployment, right? That's like Thousands and thousands of services each being updated independently This is this is a quote from Werner Vogel. She knows who Werner is It tells you on the slide. So hopefully you can figure that And I won't read I won't read all of it But if if you haven't this is from 2006. So this is three years before anyone said the word DevOps He said at Amazon if you build it you run it Right if he this brings developers into contact with the day-to-day operation of their software it also brings them into day-to-day contact with the customer and It will change the dynamic of your organization very very quickly if the person who is Going to feel the pain for a bad decision on their code actually gets paged for that bad decision Like change is thing that I don't think anything changes things faster Right and it's one thing to connect incentives and a bunch of stuff But if you if you move pain to the right places like it goes away right Just a quick aside does anyone know the experiment where they like give the guys the shocker this like a classic California experiment Humans are weird man. What are we doing? It's like you're just gonna shock the guy All right, so everyone looks at Amazon and they rush to copy this. There's like, oh, there's the cloud Amazon's advantage is not the fact that they put an API in front of hypervisors Right like I think that if you look at some of the stuff that's happened with other attempts to make open-source solutions to that problem You realize it's not that's not the hard part these are superficial features and really the big advantage Amazon has is the is the process in the culture that produced that the Artif those are artifacts of this other thing and They're they have a huge advantage against most other people in this space, although You know, there's a short list of people that that could compete with them with respect to operating a massive web infrastructure at scale I don't know what just happened with the The cost of operating that is something that they are able to press down and down and down Which is why they can provide the level of service They can at the prices that they can and that's why you're seeing you know Roughly 30% decrease in the cost of their of their services year to year over the last four or five years This is from O'Reilly radar, which is also kind of related to to velocity And they're arguing here that Operations is the secret sauce and they're talking about startups So what you're seeing on the left is what we'll call you know the do it five sh solution to operations and on the right It's more of you know, the configuration management style like very policy driven collapsing the complexity with Systems that can enforce across your your full infrastructure So and the bottom what they're trying to show is the servers So you have you did a bunch of work you start your deployment that that that peak there is the first deployment to to production and then As you grow servers if you're using kind of traditional IT then the cost of doing that is going to continue to go up linearly where if you've if you've done this work to make the Kind of the configuration and non-issue Then it's still going to go up But your your your linear factor is much much lower And so your your overall total cost of ownership is much lower And the thing that you have to understand if you're building services Which it seems like it takes a lot of people a while to get is that day two matters, right? Like deployment is the price you pay to get to your real problems And if you think about you know, everyone kind of over rotates on developers developers developers If you are going to do the math about what it costs to own something then the on some timeline The cost of ownership if it's high to operate it then that will dwarf Dwarf the development costs Right and if it's high that the time that it takes to equal that is very very short But many whatever for whatever reason many organizations don't internalize that So what I want people understand here is that these are Really things that emerge from from principles Right when you see someone using puppet, that's not dev ops Right if you see someone using any tool cloud foundry doesn't matter. That's not that's not dev ops So the principles are the greatest thing if you understand that then you can flexibly Change to whatever you have to deal with the practices that will naturally emerge as you understand these things are one thing And then the tools are the last artifact that's the lowest level thing About what we're talking about so let's rewind I'm gonna keep going and we're gonna go really fast So let's rewind that so software in the beginning. We had a bunch of stuff We shipped it on CDs. It was hard to change after release. It runs on our people's computers You don't have to really worry about bugs because it's out there on someone else's computer But processes don't run really long right like you you turn off your computer and you come back So it doesn't matter if it has memory leaks so much and there's no real uptime Me memory links who made some memory links before It's right So you don't and this is all really to me like there's this story about and this is what's powerful about software development Is you could take ideas and you can just make stuff right like you manifest ideas as code that's powerful So this is the process in traditional thing you have a good idea you request a server you get a purchase order You wait you wait the server arrives the server gets power network server gets operating system start to configure for the deployment And you have the sys admin and he keeps all the stuff running. He doesn't care about your application. He's not paid to care He's waiting other people need their servers to and he's a cost center anyway So he doesn't carry and he has to worry about not just all these servers But also probably email and maybe God forbid printers So then you shift to servers their services right so like now we're not gonna ship CDs We're gonna have services so the internet changes all this we run things on other computers There are computers we can change those computers at any time we want you still have to worry about bugs and Process is now running a really long time and I'm time becomes everything Right like that's this transition that not everyone in the industry is made but that the the big web lives and dies by and And we'll get to this platform story in a minute So then this is bigger faster. This is a Google data center and you always hear people say we're we can't do this We're the enterprise our ways are different We have this thing Right And it's like what our strategy is is we're gonna just slow everything down and and this is this moving slow is an advantage How I don't know So this is a this is a classic slide from Velocity conference talks I gave and use all over so you have developers and operations what you're gonna do is you're gonna put a wall between them Probably a ticket system And then everyone's unhappy and then this is pretty much what happens So our our misaligned and missing light incentives and advantage That's really not how the web was built Right like no one at Google or Amazon. I mean there's a infosack and there's a bunch of other stuff And so there's definitely still gating and it's not a free-for-all. We'll get to that in a minute but it's not a competitive advantage if you have to go through this this kind of process and What's what's evolved or what we're talking about now is these narratives around? platform DevOps continuous delivery microservices. Who's ready any of these books? So continuous delivery is a great book jazz Humble is a great writer The Phoenix project is really rewrite of the goal Which is the theory of constraints framed with IT and release it is a bunch of patterns for it's kind of the stuff You see in in the goo or a Netflix open source with respect to some of these patterns So then we have this new narrative that's emerging and we have a bunch of new tools and this is definitely part of my Story, so now we have a new process and the process is I have a good idea and I get a server and And I can make cloud API calls right and so I get a server in minutes now And I run my configuration tools and then in minutes everything's up and that's pretty cool Principles practice tools, but then there's this guy who knows who this is Now he's a venture capitalist, so he turned to the dark side, but he used to he used to lead a lot of the cloud stuff in Netflix and These are these are like straight stolen from some of his presentations, so he's like this is what I learned speed wins remove friction from the product Hi high trust low process no handoff between teams I think this is the hardest thing for a lot of the the people who have really ingrained, you know Their identity in these processes to overcome Freedom and responsibility culture, we're not going to cover everything with all these rules What we're going to create is a bunch of highly empowered people that can take responsibility for our success or failure and Then don't redo things that you don't have to do right and use simple patterns automated by tooling This is like word-for-word off of his presentation self-service cloud This is the key self-service cloud makes impossible things instant and this is Something that every kind of DevOps project always aspired to do is like be able to give you self-service Right, but rarely you get to there Because there's all these other things you have to solve It's one thing to configure servers. How are you going to solve the role-based access? How are you going to do the API to do the orchestration to then get the server and then you run your puppet, right? Like there's a bunch of other stuff and everyone aspires to do that But very few people actually get there. I've got there before with those tools I think an integrated solution is a better way to go So here's another thing I want everyone in this room to internalize especially if you work for enterprise But we're an enterprise. We've not had the talent to do this This is a quote from from Adrian as well, but Netflix has a superstar development team and we don't This is what he told them We hired them from you We hired all those people from you And we got out of their way So this is this is this impact of batch size So I want people understand when we start talking about rapid changes to these infrastructures It's actually safer. So if you imagine risk accumulating as you write code and then every time you do a deployment It comes back down Then if you do big batches the amount of risk you're exposing yourself to is higher Your exposure to the risk is less frequent But the actual total risk is higher and just think about it mentally if I do a deployment of something I wrote an hour ago and there's an actual problem Then it's not a big mystery where that code is I can go fix it immediately And so you're minimizing your time to recover and you're not that worried about about the impact because you know You can minimize it very fast. And so what's happening in these web companies is their time to recover goes to almost zero And so they're they're very plus they have continuous delivery is predicated on continuous integration If you don't have culture of testing if you don't have a culture of monitoring then don't do this stuff But as you get those capabilities Then you then you should have started to do this because it's both faster and safer And you want to go faster because John Boyd Well, I don't have time to get to you to loop and I'm way over time and I still have more slides. So It is not necessary to change Survival is not mandatory Edward Deming So Netflix build a platform to enable self-service deployment They build a platform to deploy and operate micro services They build a platform to continuously deliver software. They build a platform that could protect itself from failure What Netflix did not do is build a platform for general ad hoc automation That's another thing people you understand Because the platform makes promises and the constraints are the contract that allows the platform to keep those promises So we start thinking about 12-factor apps and that's that's the contract that Heroku Decided to make with their platform And there's a bunch of other platform contracts. You could imagine But if you if you just allow anything then you didn't really solve anything either Right, and then you're right back to trying to figure out what's wrong when you have a problem if you collapse what you're what you're able to do those constraints are actually enabling because 80-20 rule That you can get 80% of the benefit from 20% of the features most of time So DevOps refers to the practices and tools that emerge from high-performing organizations and continuous delivery is a result as a consequence of that practice and this is not Possible with gating and handoffs Now we could debate continuous because there's like a quantum of delivery, but In reality like you want to shrink your batch size and you want to shrink the cost of delivery Because it's not possible. It's untenable if the fixed cost of deployment is high If you have a high fixed cost of deployment, then you do it all the time. That's expensive right And microservices is just a description of the post cloud post DevOps post continuously deliver post continuous delivery architecture It's not it's a natural evolution. So this baseline operational capability that you get when you can do a deployment on demand and Then the other thing that this is giving you is the team dynamics to leverage Conway's law because you're decoupling the amount of people that need to be involved by by enforcing the contract and the API as your Communication then you can decouple so each of those can be deployed them independently like that's the whole point of microservices is that you have Loose coupling right there if you have to deploy them all together, then you don't really have microservices What you have is a monolith that you broke apart Right, you didn't you didn't actually get to microservice because you're not decoupled And I'm going to argue that continuously delivered microservices are the natural evolution for services that need to run at scale and be changed frequently and That a bunch of people built platforms to do this, but those are one-off platforms And that continuous delivery is a why DevOps is a how and microservices are wet But all of them you basically need a platform You can't until you can take arbitrary code and put on a server and have it run You can't do continuous delivery Right until you can have something that is relatively monitored and and safe and maybe even self-healing You can't really do microservices and and to be able to do that to build all the scaffolding around doing that That looks suspiciously like a platform Do you want to build one by yourself? There's this thing maybe you've heard of it and Maybe maybe you don't want to build one by yourself, but maybe we can build one together And this is the new process you have a good idea push code to the platform It's running in seconds self-service self-healing and we all live happily ever after But here's what I want you this is like the takeaway. No one set out to do microservices continuous delivery Any of this stuff? These were natural consequences So don't fixate on the words like I it's annoying to me when people are like, you know, we're so agile It's like well you guys suck at software like What are you talking about? Like don't tell me how devops you are tell me like how much you're like kicking ass for your company and this is actually not the end because What's happening now with the Internet of Things and big data and everything getting bigger and faster? That means that in the next five years that I say the average if you just start to do math on time series and sensors and all this stuff the average Internet of Things deployment is going to put enterprises on the scale that Google had to be at maybe five ten years ago It's just it's just math, right? And and if you are still stuck in the past with your processes and your thoughts about how to do this stuff You're going to be at a huge disadvantage and someone else is going to build that future for you So I work for Pivotal. I work on cloud foundry I get a little excited about stuff and I'm way over time, but thanks for sharing this time with me I'm happy to answer any questions you might have Thank you