 So anyway, hi, we're gonna we're gonna talk about how containers not magic not gonna fix your, you know, corporate culture My name is Bridget Krumhout. I came about a little over, you know, 13,000 kilometers I think that's a thing. I had to look that up, but it actually I'm not positive what kilometers are But I came about that far to get here from Minneapolis, Minnesota If you're not super familiar with US geography and some of you are but if you're not super familiar with it Minnesota's in the middle in the north right near Canada by a bunch of big lakes We have one month out of the year July where it's never been known to snow It's possible to snow the rest of the time more on that later. I work at Pivotal doing tech advocacy for the open source cloud Same words is hard for the open source Cloud Foundry platform. I podcast at ArrestedDevOps.com with a couple of fantastic folks and I am part of the shadowy global cabal that Operates DevOps days everywhere. So if some of you know AJ who runs the one here in Bangalore Where we collaborate on these things? Okay, a little bit more about how I got to here I spent 1999 until August on call for production infrastructure. I was not sad to delete the page of duty app for my phone and When you spend that long in ops you get used to having terrible sleep that sleep graph from back when I was actually trying to track These things was I think while H base was having a lot of problems But as it turns out trading that for a lot of conference talking and traveling does not improve your sleep it's just more jet lag so and That's a container. So this is this is not photoshopped except for I mean I did add the word DevOps like that shipping container didn't come with a bunch of DevOps in it But this is actually a picture I took in Minneapolis where it's apparently like cloudy with a chance of DevOps at all times Because we've got we've got containers. We've got silos. We've got some clouds there you know all the all the stuff that you expect and I Confused my partner Joe by stopping while we're biking on our way to our community garden and taking this picture because I thought This kind of typifies all of the things that people think that they need to worry about or think that they need to do and I gotta say like I have actually spent a bunch of time with containers in production My last gig was running DACA in production for a year. So I have actually done that. It was fantastic It was delightful. It did not actually solve all our problems as it turns out. I know, right? I was surprised too and when I joined I was like these people have been running doctor in production since October 2013 Back when the main thing on DACA's website was like under no circumstances You run this in production and they were like yellow and started running it and so when I joined in summer of 2014 I was like hey, this is gonna be fantastic because you know nothing can ever You can never have any problems whatsoever if you have all if you're docking all the doctors, right? Well as it turns out I found out that I was working at a company that was run entirely by humans I know and staffed entirely by humans which meant that even if we had great technology It didn't actually make everything better Um, we were trying to win a buzzword bingo So we were you know because we started in 2009 at this streaming video service Which by the way was it was kind of like Netflix if Netflix were mostly k-dramas and you know much smaller and ran doctor in production So maybe not exactly like Netflix, but um We were we started in 2009 which meant that because we're a python shop We were obviously using Django and you know by like early 2014 We were rewriting things and go because that was a style at the time lots of lots of Tech fashion stuff that goes on there But what we learned in trying to you know break things out into a whole bunch of microservices is that that I mean Microservices make everything better too, right like well, I mean yes They help certain problem sets, but they're not going to magically make everything better either Because if you if you look at like all of these you know tech trends and I thought that this wouldn't work This slide wouldn't work here, but I went and visited two different tech companies the last couple of days and both times at lunch We had pizza, so I was like, okay I mean of course they were they were smaller pizzas and then I'm thinking two pizza team is a really confusing phrase because how big are the pizzas and how hungry are the people I feel like this does not necessarily work in all cases But Amazon has this whole two pizza team thing where you should have really small teams that own an entire service end-to-end Spotify has like their squads You know there's a lot of tech trends like that and I say okay I mean that kind of stuff works to a point But you don't necessarily need two pizza teams to do microservices, right because your microservices are going to increase your complexity They're gonna make it a little bit more Depending on what your telemetry looks like depending on how you have things, you know In terms of visibility microservices might make it a little bit more difficult to solve some problems Until you've got your monitoring telling you which of the end microservices these problems are coming out of So the communication between the groups that are running in the different microservices still matters a lot Even if the groups are small enough to be fed by you know pizza of arbitrary size But when you look at Conway's law and Conway's law by the way if you're not familiar with it is paraphrased here In the paper in which Mel Conway originally wrote it which was published in 1968 called how committees invent He he got to the good stuff. He got to this right near the end of the paper I don't know how anyone got that part of the paper like I wouldn't read something called how committees invent if you like This is exciting. Let's find something similar an important thing here but apparently it was and this rephrasing of it comes from his website now apparently he's still alive and has website and No real way to contact him on it, so I guess we can't get him to come speak at conferences. I don't know but I think the most important word in Conway's law is communication because a lot of people look at Conway's law and they think oh If the structure of our organization is going to dictate the structure of our software That means that if we want to have microservices, we have to break up into these small cross-functional teams Well, maybe I mean kind of like Nicole was saying when I asked her you know possibly troublesome question after her wonderful keynote this morning The answer is usually it depends because if you have a lot of separate teams Or maybe even teams who work across continents, but they have good communication between the teams You might be fine You might be better than a bunch of cross-functional teams that don't actually communicate or talk to one another and If they have clean API's between the teams and that's kind of this you know like Amazon esque ideal But then if there's breaking changes and you know unversion changes to the API's the other teams are depending on You've made your problems worse. It's like Technology helps us solve those problems a lot, but it does not actually it doesn't provide a panacea It's going to you know suffice for absolutely every use case And by the way like speaking of you know tech trends tech fashion whatever like I don't know about you But I'm really excited for what's going to be 2019 is the year we're gonna all get really excited about inodes and I say this with all you know I say this with great love very tongue-in-cheek, but like the fact that I'm even putting the word container in a in a talk title and then people are showing up to hear about it They don't really know what they're going to talk about spoiler alert. There's some cat pictures in here, right? but uh We're putting it like you know some of these hot tech buzzwords in talk titles does get people to show up and gets people interested But the tech in and of itself is not what's going to solve all these problems for us It's basically you know where I'm going with that and I think like if we if we look at this and And uh yeah, I don't know. I feel like sis calls is gonna just get ignored. We're gonna go right from Threads Dinos I'm pretty sure But if we look at the the hype cycle This is a Gartner hype cycle and we think about like how people make tech decisions I'm pretty sure no one here makes their tech decisions by like running a Markov bot against the front page of hacker news I mean maybe like I'm pretty sure I've seen some organizations that have probably no one here, but like People who are trying to make tech decisions like I work in a vendor now for the first time in my career I go in and I talk to other companies and I hear a lot of people say who like us is having success doing this People want to see a reference customer in their industry in their vertical, you know, maybe with their kind of market cap Maybe even in their country who's having success with this particular technology And I think that's very narrow and segmented But it's also a very human thing to want to look at people who have some sort of commonality with you and see what kind of success They're having trying to make these choices And I think the reason is because there's a lot of choices out there There's a lot of complexity out there and you can shortcut some of the decision-making by saying well other people like me with Along whatever axis have had success doing that. So maybe I'll have success too and That works to a point, but then when you try to have that intersect with the hype cycle, you're like I think I want to use containers, but nobody like me is using containers successfully in production yet And then everybody starts looking at analyst reports and it's like again, this is where We're at an agile conference So I think I feel safe in saying that everybody here probably agrees that taking small steps and iterating and trying things is a lot More successful than waiting around until someone else who's exactly like you has finished an end-to-end successful story It's like that you know as well as I do that that's not the best way for you to get ahead in the market so And at the same time it like we are obviously at a point of great change like we're obviously at a point of you know Just like you know the the idea of like when virtualizations first started happening Like the the fact that we have you know containerization is something that is a big deal to a lot of people right now is Different than it was before like we are at some we are at a time where things are changing significantly changing pretty quickly This is a this is a quote from a science fiction TV show from the 90s that I'm sure some people remember But there's this very profound line that a character who otherwise is rather forgettable says where he says nothing's the same anymore And I'm like yep, you can apply that in so many cases, especially in tech right now At the same time again, I go in and I talk to a lot of these companies and they're very excited about their Greenfield projects and they want to put them on Cloud Foundry our platform and They kind of say sheepishly and then we have all this legacy stuff as if it's a bad thing Like as if you know the fact that there are these startups coming nipping at their heels We're gonna disrupt everything Who are gonna cause trouble who don't have all that legacy to worry about and just have a greenfield app to deploy as if those people Have the significant advantage that the companies that have been established don't have and what I would say to that is well again back to the back to the Nicole's point it depends because if That legacy data that legacy system didn't matter you just turn it off like obviously there's something really important there Probably your customers you your revenue stream Like there's usually a reason that the legacy system is important enough for you to be working on trying to migrate it now The reality is that sometimes if you hang on to a legacy legacy system long enough You're probably gonna have to do some massive like rewriting replatforming I went to the science museum here actually and I was super excited to see in the museum and IBM 14-01 The reason I was super excited is because I don't know if anyone here happens to recognize it The font that I'm using here is a font that is based it was made by Jeff Callum And it was based on the font from the that was produced on the IBM 14-03 So it's like yeah, that's kind of awesome. I got I had never seen an IBM 14-03 Which is the the printer right there I had never seen it in person so because I guess they have one at the computer history museum in Mountain View And I've always been upstairs at the Dev Ops days events and need to go down and actually see the machine But the thing I thought was really interesting about this is that they had a sign Saying that this was you know getting donated to the museum from the government and it was in use until 1989 And it was producing money orders with the post office or something and I thought you know what? They kept that system until it was no longer useful Like impossibly longer than it was you know useful or whatever But I bet you anything when they first started using this, you know a really long time ago It was probably useful for a lot of things including perhaps money orders But probably not limited to money orders and I would say there was probably a very smart pattern here where one piece of Functionality at a time was migrated off of this main frame until finally it was able to be retired and shipped to the museum And that's actually when you're trying to move to microservices. That's and you know You can't necessarily take your entirely legacy your entire legacy application off of the 14-01 Shove it into a container and be like we're done pray. It's like that's probably not going to work super well So there is going to be a certain amount of redesign refactoring Figuring out which pieces of the application you can rewrite and then maybe have something proxy back to the old data store Until you've you know kind of that strangler pattern which sounds sort of murderous and terrible But I guess it's related to like vines or whatever and until it's possible to actually move away from the old but Trying to do this, you know kind of second system second system syndrome as a Astrodactycin and Google called it her keynote at Qcon Doesn't really make a ton of sense like this. We've built an entirely new perfect thing two years later We're going to cut over to it. Let's hope it's ready It's like even though agile obviously started in software development as an IT apps person I can tell you like we have to think about this, you know iterative change in operations, too And if we don't I gotta tell you this by the way, I took this picture I think it was April in Minnesota that was still snow not a lot of snow, but there was still snow and That's that snow man is definitely not long for this world And it reminds me of this Deming quote where he says that I mean you don't have to change like it's not necessary to change However survival is not mandatory. So like at some point you need to make the decision to go ahead and change and deciding what the right path for change is for you and Exactly how to implement it and which things need to go first is a completely localized decision And that's kind of one of those things where you know People will sometimes pay consultants to come in and tell them exactly how to do this and it's like that's cool But get you know get somebody like you know Thoughtworks or pivotal or whomever to come in and help you with your agile IT transformation There's a whole bunch of great sponsors here that will come in and help you with that transformation But you're gonna have to make the decisions yourself about what's right for you because nobody else is gonna understand your use case as well as you are And you definitely should be aware of anyone who tries to sell you devops in a box So like just like that shipping container earlier definitely didn't contain 200 units of devops There are not you know a couple of dozen delicious devops chocolates in this box Well, actually there are but this was at devops days Belgium in Ghent in 2014 our badges were a certificate of devops And they gave us devops chocolate and which is just kind of the tongue-and-shake well I mean yes, you can get devops in a box. It will be it will be delicious It's still not going to dev any of your ops like it's it's not going to actually make the transformative changes You need to make in your organization That's a question of your internal will and the leadership coming from your organization like um, for example all state insurance Has a very forward-thinking CTO Andy Zittany who spoke at Cloud Foundry Summit last year And was talking about how when all state decided that they wanted to make changes They had leadership, you know at the top saying this is important This is something we're going to prioritize and they also had people, you know throughout the ranks saying yes We want to do this like you do need both But it's not something that you can just buy And these tweets entertain me a lot because like if we consider that devops is empathy Then I mean are we selling enterprise empathy automation tools? I mean like probably not So it's not that it's it's not necessarily a drop-in one-to-one replacement, but it does make us think a little about If we're using this concept of devops to have to move more effectively Oh, and we actually we also have a from Patrick de Bois who started the first devops days It was actually an agile conference. I don't know if you've heard this story It stopped me if you've heard this one before I make sure actually don't stop me There's video, you know other people who haven't heard it before who aren't in this room with us I might hear this later, but in 2008 at the at the agile conference one of the agile conferences I Andrew Clay Schaefer put up a birds with a feather session that he wanted to have about agile systems administration And then he thought nobody's gonna come to this And so he didn't show up at his own birds of a feather session one person showed up It was Patrick de Bois who had to go track Andrew down later and talk to him because Andrew wasn't at his own session and their discussion eventually led to Patrick going back to Belgium and starting the first devops days in Ghent in 2009 and When we asked him about okay, so if it came out of agile like why is it called devops days? He said agile systems administration was too long for a conference name I'm like, okay. I can see that that would be a pretty long hashtag That would be a little bit harder to fit on a badge than even any of this stuff so I can see that point but like this idea of Moving towards thinking of devops as you know, not just tooling But also this human cooperation between the different parts of the business is not just touchy-feely stuff as Nicole was saying this morning If there's data that shows that this makes us more effective. It's like we're gonna be more successful If we're focusing on this team stuff, there's an effective devops book that's coming out soon It's a pre-release from a Riley right now. That's very much worth reading I was fortunate enough to be an early reader for it Jennifer Davis and Catherine Daniels are writing this and What one of the things John Davis said in a blog post for sysadvent this year Just focused on we don't want tooling that makes it impossible for the humans to understand what's happening At the same point, you know, like we like we just heard we don't want to have tooling that Requires human intervention, you know unnecessary gating where we don't actually want to stop the process We don't want human intervention But choosing and creating tooling that's comprehensible to the humans involved in the process is super important and Like the idea of you know, the secret herb bunker like please do not touch this the separation You can get between dev and ops where you know, okay Op stuff is checked in but it's in a private repo and like the devs can't have access to that I think that's an anti-pattern because that's not going to make it easier to have transparency and visibility throughout the Organization as to what's actually going on I a couple of startups ago. I worked somewhere where we had, you know graphs we had a Graphs on you know coming out of graphite Like, you know displayed on TVs that showed things about like, you know things hitting our API endpoints and whatnot And one time a customer success person came in in the morning before me I mostly rolled in like just in time for stand-up but she came in she saw on the TVs that our normal pattern had turned to and everything was flat and She looked at that and she could tell from which graph it was that that was clearly one of our major customers And we were no longer we there was no way we were still appearing on their website if That was the traffic pattern coming off of their site because we were we were the dreaded third-party cookie ad tech Ooh, I used to be evil. I might still be evil except I report up through marketing now But What she found was that when she went look to the customer site indeed our which it was missing She was able to diagnose that talk to the customer They had had a botched deploy that had accidentally taken our stuff off the site early in the morning hours And she had it fixed in the graph back up to normal like before I even came into work It was fantastic and like when you have you know visibility rating out to the radiating out to the rest of the organization And you aren't keeping all the information into the you know the ops priesthood like you can have much better success for everyone and this idea of like choosing both, you know, you're monitoring your tooling your architectural patterns and Just making the right thing making the thing you want everyone to do the easy thing I think it's really profound like that's that's the direction. We're trying to go and We have shall I say we have the technology like we can with technology Gait people towards the behaviors that are going to be the best for everyone Things like exactly which get workflow you choose like hey if you choose a get workflow that is no kind of Anti-continuous integration with long continuous deployment that is going to cause problems for you So I also think that we have to consider the complexity in the systems that we're building and the systems that were you know Making visible to the consumers maybe inside our company of the stuff that we're automating like for example If you're a platform team and you're making services available to other teams inside the org like if those services are such that They are You're you have very leaky abstractions and they have to comprehend absolutely every single bit of complexity in your system And yes, I'm looking at you storage system in Azure So confusing if you've tried to use EBS and then you've tried to use the storage in Azure and compared them Like you'll know what I'm talking about. It's like why are you? Exposing these particular limitations and the abstractions to the end user like if you can have really clean APIs that Exposes you know leak as few abstractions as possible, you know when you're cooperating between your teams and your organization it's like way more helpful and Containers are back to containers. They were in the title. So I got to talk about them from time to time Containers I think are a really useful boundary object because if for example some developers have dependencies and that they really care about and They can package those up and build the container through their CI system There isn't going to be any of that Docker build Docker push from somebody's laptop And you're like the Docker file has add a bunch of stuff wonder where that is is it checked in So like obviously any images that you're going to actually run in production are being generated by your CI pipeline but for the for people who are Very concerned about moving to something more modern than what they have because maybe what they have now They at least know that like they've got their version of Java and their dependencies under control And then they realize that hey if I move to something that's more containerized whether the containers are being Generated inside the platform or out like via a build pack or via a Docker image like that stuff Those are implementation details, but if people are going to move to a more containerized runtime The dependencies that are necessary for an application go with the application and The application developers don't have to worry about whether or not somebody's going to upgrade the underlying OS and render their You know super essential. What's it like inoperable? So I think that's kind of valuable Yeah, that is if any of you are from Portland This picture is from the carpet replacement at the airport apparently some people were very I'm not from Portland But I visited there when they're in the middle of replacing the airport carpet apparently the I think the the one closer to me is the old carpet and one for their ways the new one and people were very Very concerned about slash attached to the old airport carpet like I don't even know But I kind of had this visual in my mind of like, you know clean distinction between Worrying about the concerns of the underlying OS and worrying about like the concerns of your specific application Because we don't want the classic wall of confusion, right? Like you've you've seen these a million times. I feel like you know You could change you could replace the I want change and I want stability with like YOLO and nope I mean this is the The classic tension between development and operations that I think we don't need to have Because we have decent tooling now to make it Unnecessary to have all of the manual friction and handoffs that cause a lot of this tension And because Nicole referenced it this morning I took that had taken the slide out and then I decided to you know drop it back in because she mentioned it this morning So pop quiz does anyone actually know when this was said I know Nicole does But does anybody else know when this uh, you know in the last week there were 67 deploys of 496 changes by 18 people Jez knows if you actually know or are you guessing? All right, let's hear it Yes, you know when Almost you're right. This was from a flicker dev blog in 2008 It was quoted in the talk at velocity that tend to ploys a day at flicker talk of velocity that Nicole talked about in her keynote this morning and the reason that I want to bring this one up is because So many of us today are not at a place where we can say this and if the people are looking around in the room and saying Oh, no, no, I deployed 10 times a minute and you're like, okay You do put a lot of large organizations. I talked to do not and we have to think to ourselves Why could flicker do this in 2008 if a lot of us can't do it today? And yeah, the tooling is better now for a lot of this but They were operating with the tools that they had in 2008 and they could do it So I think that's a pretty good and that's pretty good evidence that tools are not the only part of this that matter Having the culture of cooperation between dev and ops and cooperation across the action the entire organization Like it seems pretty clear that at least at least in this particular case that made a big difference for them and I think when we're talking about cooperation between Organizations and you know across teams, I think it's really important to remember especially since I'm standing here in Bangalore still sort of jet lag talking to folks that There's a there's cap theorem which some of you probably are familiar with this It's a concept out of distributed systems and it's about basically when we are looking at it Say a distributed system. Maybe it's distributed data store or whatever you can have Consistency availability partition tolerance you like pick two you can't have all three at a given time and I think it's really interesting that Eric Brewer who came up with this concept went back He revisited it like 12 years later wrote an interesting article that I think is on info queue or something somewhere Where you talked about how for a partition what you really are saying is well, it's a time bound, right? I mean like okay, you're partitioned, but Until how long it's really a question of how long you're going to wait for that partition to come back together Before you're going to say all right, we're just operating in split brain And we're trying to decide we're trying to design a lot of our distributed systems today such that it's possible to operate in a state of continuous partial failure as they like to call it because Realistically whether you're in public private cloud, whatever you're going to be operating in a state of continuous partial failure pretty much all the time I mean, oh, come on that was the queue for the projector to go out. Why is the power still on? but seriously the Looking at this and thinking about a partition as being, you know time-bounded just immediately makes me think of Yeah, like here in Bangalore if you're cooperating with people in Minneapolis Are you gonna wait ten and a half hours every day before you make any decision like I'm gonna go with no I don't know to shout it out. Yes. No, you want to wait ten and a half hours. Oh Absolutely not. I got to the tour of the target's agile dojo on Wednesday and it was I knew it she's actually sitting right here And invited me to come and see it and what I was impressed by was that it had many similarities to the target agile dojo In Minneapolis, but it was also being run completely independently There were no callbacks to and then when Minneapolis does this then we do that and I'm like excellent because Just like if you look at something like console from Hashi Corp The nodes are all talked to each other via a gossip protocol There's no like waiting for the you know, the lead node to kind of give it kind of some kind of information And it's like you can't have this just like in our distributed systems We don't design them to be blocking on some sort of central sources of truth at all times And we can't do that with our human interactions either So I think that these are the kind of patterns that again using a lot of the modern Or perhaps not so modern. I mean containers have been around since 70s at least but using a lot of the you know Tooling that we have today. We can enhance the kind of cultural practices that make us more effective. I Also think that there's no substitute for actually talking to people and and yes when I When Nourish asked this morning, like what's your favorite part of a conference? I said hallway track because like I like to come to conferences and Hear what other people are saying get to know other people because you get a hundred and forty character snippets on Twitter here And there maybe from time to time you're going to read a blog post but the Real-time high bandwidth interactions of in-person communication definitely, you know the value of that definitely can't be denied and I'm a remote employee. I've been one for a couple years now And I enjoy that a lot, but the face time that you get to spend with people is also super valuable so That said like especially for people who are remote employees or collaborating across teams We do a lot of pair programming at pivotal which is fantastic We also do pair ops work which I find unusual but interesting and I just came back from a two-week rotation with our cloud ops team That runs our hosted Pivotal web services where I got to work on that team for two weeks Which was pretty great and one of the things that we did was you know day-to-day when we're swapping pairs people would orally Pass on context, you know one person would stay with the problem And you know the other person go work on something else and then the person with context would like stay in the problem And another pair would swap in and that works for you know Like moving forward with high velocity there there's can't deny that pair programming is very useful for that And it's at the same time like you have to still write things down because at some point Someone's gonna go on vacation or go to a conference on the other side of the planet and not be available to you for real-time querying whether it's because they got a promotion or another job or whatever so on the other hand I'm not a huge fan of Documentation and runbooks and giant checklists and the reason I'm not a huge fan of those is because I feel like they get outdated the second You make them But at the same time saying well this code is self-documenting also doesn't necessarily solve the problem Because what I end up doing is looking at the code that I wrote like six months later and saying pass you What were you thinking like why does this you know? Why does this code commit? Just tell me what this code does that is not helpful. I can read the code. I know what the code does I don't know why so I think that the kind of documentation that's actually useful is just a Detailed commit at the moment that you make that decision and commit it that says why you did this as opposed to the myriad other things You could have done because I mean of course like you can add more information than that But to me that's like the minimum viable if we're gonna be all agile and say like MVP like the minimum viable commit should say Why this is going in? because that way people can they don't need to go try to consult a giant checklist or a Giant, you know design document that's probably wrong to figure out why a little bit more about devops's culture, so I feel like Point I was I think I tweeted this into August 2014. I was very You know set on this devops's culture. It's only culture. It's not tools tools are definitely not part of devops and When I tweeted this Andrew Clay shaker answered me and said everyone is selling and just kind of his like you know mysterious Oracle Adelphi sort of way and what I think Is actually true here like is that devops is culture, but the tools enable the culture So the tooling and the practices all the stuff that we're doing To make you know our cooperation possible is how we practice devops together Which means that we have a lot of choices that we need to make to try to figure out how to do this I'm like, okay. That's great. Was there a lot of ideas? Well, like how should we actually do this? Like is there you know, is there a 14-point, you know devops thing I'm like well while there are people like say Nicole and Jess who will definitely help you evaluate Whether or not you're deving all your ops and if you're going to be devopsing at the velocity and with the accuracy That's right for you. Like the answer is it's it really depends it depends on where your organization is now What you're trying to accomplish? like this is it's always a very Individualized and self-evaluate Evaluatory But the self-evaluation that you go through is a lot more valuable than Trying to go and get certified by someone else because like again I mean honestly if somebody is going to give you a certificate of devops like they're saying you successfully graduated from kindergarten Like you're not eating crayons and you're sharing with other children. It's like that's fantastic Like you wanted to share that's great But I mean that's I don't think that that's a useful thing to say somebody is certified in But the kind of things that I think it's useful to measure is like say you're trying to evaluate your progress Like how well you are actually doing and improving your culture For example here like we have these squash. I mentioned the community garden earlier That all those containers and silos are on the way to you So maybe squash and they're absolutely enormous way better than those tomatoes So that means that we did a great job of growing squash, right? Well, not exactly because those are patty pan squash and they're supposed to be smaller than my fist So we actually neglected them way too long when we tried to eat them. They were terrible So if if your only measure of progress is like the number of people working on this and how high the budget is and The lines of code produced I mean there's there's so many ways you can measure progress that are probably not actually useful and so looking at the actual value achieved like what are the actual results that we've gotten for our Organization that are useful as opposed to looking at, you know, I mean I like monitoring. I like metrics. I it's You know sorry to the statisticians in the room But you all know the lies damned lies and the stats coming out of your monitoring system, right? It's like It's possible to make your measurements look like anything you want them to and so it's a lot more valuable to at least focus on What has improved in our organization in our culture like and for our business? another thing that I want to want to warn people off from is the idea of Saying we want to implement a lot of changes, but we also want to keep our old processes We want to keep our release management. We want to keep our ito and we want to keep our fill in the blank Okay, so a lot of process is usually in place because something went wrong in the past like for example This is from Amsterdam and I'm I'm a quarter Dutch So I can say like I don't understand those Dutch people man because like I was in Amsterdam and there's a There's a the sticker is in Every bathroom of the hotel that velocity in Amsterdam was in last year And a lot of people started tweeting the picture, which is why I didn't go and visit every bathroom But like a lot of people started tweeting the picture, which is why I realized that this wasn't just in our bathroom This isn't apparently in every bathroom and what it says there if you can't read it is we kindly request you to take your shower in the bathtub and I'm thinking what happened at this hotel enough times that they thought it was important enough that they printed a sticker and put it in every bathtub and I'm thinking like there's so many places where I mean I worked someplace that had really actual heavy process and we had a 42 page change management process And it would go to the change control review board and they would decide whether or not that change could go to production And unless something was horribly wrong at which point we could just put things in production immediately It's shocking. I'm pretty sure the statute of limitations expired on that job because that was like, you know over a decade ago So I'll just tell you it's shocking how many emergencies we had Because pretty much every time I wanted to make a change I only had to fill out like the three-page emergency form and just do it And the thing is if a change being made in that kind of way is okay When everything is on the line when everything is broken when everything is down and when you're you know Like we were hearing earlier It's three in the morning and somebody is trying to make that decision then if your fast-track hot-fix Processes okay, then it's probably okay in the light of day when everybody is there Like but the a lot of organizations that are trying to change do kind of fall into that trap of but we still want to keep and then the giant heavyweight Processes that's like okay. That's not actually going to make things better. That's actually going to make things worse And I think another thing that people run into some trouble with is I warned you there are cat pictures This is this is a cat me more affectionately known as attack kitten He spends a lot of time attacking well everything but lately mostly he's been attacking on Laptops fingers apple branded cables. I guess they're more delicious than any other cable and also learning a lot about everything that you see on that laptop just by Osmosis from the stickers. I'm pretty sure he's become an expert at docker by this point Just by proximity But I think staying on top of all of this stuff that we need to learn that we need to know about all of the Computering stuff is actually kind of tough and then you're thinking like Okay, I was told I need to docker all the dockers I'm definitely doing that and now wait. I also have to have some Platform or orchestration or scheduling like I need to also do all those things That's I just changed this other thing or I was just looking into changing this other thing Or I was just trying to get some configuration management and now you're telling me I also need some containers and I feel like Trying to stay on top of every change and implement every change instantly is a fool's game Like that's not actually what a successful organization is going to do this is back to the you know technology trend stuff It's like you have to pick the stuff that's going to make you more effective not the stuff that everyone else is saying is super because if we're if we're trying to make a good culture for our employees a culture where they get to try and You know new things and learn is great a culture where they feel like they're under constant pressure And they can never catch up. It's horrific. It's like we don't want to do that to people And I think when we were talking about that wall of confusion earlier The little brick wall that was so low you could throw things over it's not what it really looks like right like the wall of confusion between teams It's more like something like this. I took this picture standing on a frozen lake in Minnesota and so like this is my partner Joe just standing right there and I'm way out on the lake and that all that way stuff is like and yes that that is what it looks like a fair amount of time and Imagining trying to see past that wall trying to climb that wall I mean, I assume there's probably like some white walkers or something terrible beyond that wall, you know, like this is this is not the kind of Environment that we want to have people in when they're trying to figure out what to do like when people are trying to be successful and make changes in their organization, but When I when I go into organizations where we have to go and have separate meetings because the head of application development And the head of IT infrastructure are not going to come to the same meeting I'm like you probably shouldn't buy anything like sorry sales people cover your ears but like selling you any kind of tooling is not going to help because You need to first get your culture to a place where people are willing to cooperate and get past You know just kind of blankly staring at something like this to hey like this wall doesn't actually have to be this way You can just walk a little bit further down and you can see under it and through it and just go around Like yeah, you may not be able to tear down every silo You know the whole DevOps trend of like give it to those silos and you're like Again, we can't do it. We're we have thousands of people We can't do a giant reorganization into five-person squads and like have that be our company That's not realistic for us. You don't necessarily have to do that. Why tear it down. Just walk around it you can give yourself permission to ignore the rules that don't make sense for what you're trying to do today and Like that is in a nutshell That's like the DevOps journey like and I think and I took this picture back in 2009 actually in South Africa And I recently gave this talk at Cape Town and someone said I've taken a picture of that tree and I thought wow Okay, that's kind of random. It's like the exact same stretch of road They drive on the left side of the road there as well. I tried to drive I panicked I couldn't I had to leave all the driving to my brother and I got to say though This was a fairly typical road on that particular drive on the Garden Road in South Africa Pretty much every road I've been on here is the exact opposite So I must commend absolutely everyone here who is brave enough to drive a car on the left side of the road With that many cars on the road because it's I'm gonna say everyone here is a better driver than almost anyone I've ever met so but it's a little bit terrifying as a passenger but Imagine if you will that there was a road that was not entirely full of honking auto rickshaws and Imagine that the journey itself was you know a very interesting part not just the destination But the journey itself was part of what you actually were trying to do and I feel like Trying to say oh we have fixed everything ever and now we are DevOps It's like it's ridiculous, right because we're all on this continuum. We're all on this journey We're all progressing towards the goal of having improved But that doesn't mean that you're going to get there and be done like that's not actually how it works And I think the places that you know the places I've worked in the places that I've talked to that are the most successful with This are the people who are using an agile approach to their iterative IT organizational changes To continue to improve all the time with or without containers again The tool while handy is not necessarily the point so with that I want to say thank you, and I'm not sure if we have time for questions But I will be around and I appreciate checking with everyone. Thanks I can I can take one question one brave soul who is not hungry enough for lunch and actually wants to Talk for a moment No one ever no one ever takes me up on that This is the right before lunch time slot. Okay, we're done. Thank you so much You