 Thank you very much. Yeah, so I actually did I think tweet right after I got accepted that it was accepted based It based on title alone. So hopefully I can hopefully I live up to that just quick show of hands How many people have seen black mirror on Netflix? Okay, that's a good number. It's at least most people I think which is good because otherwise It talk might fall a little flag, but it's okay if you haven't I do highly recommend you do watch it. It's a great show Just don't watch it right before you go to sleep. It's a little creepy What what it does is it examines? technology kind of taken to the next step or to the extreme and And when it does that it shows kind of the negative impacts that that can have But at its core what it's really about is the innate flaws in humanity and how? technology can kind of Exacerbate that if we're not careful And and it uses our screens right these things that we have in front of us our phones That when they're off they provide this very dark image of ourselves right there this black mirror And and it uses those screens and that technology again to shine a light and comment on some of our innate human human flaws That we need to be careful about as we go through technology So for those who may not have seen that I do want to run through a couple of examples But I swear I'll tie it back into DevOps. So first in nose dive We see the idea of ranking each other in social media kind of lead to the loss of our humanity, right? We see this chasing a number in a ranking ranking every interaction with each other As kind of not aligning us to the values that actually make for a good human being and and not You know that don't make for a good person Those are not the same things that make for a great social media presence Hated in the nation takes the problem with the loss of bees and says oh, well we could fix it with Autonomous bee drones right why not that's great And so automation for automation sake can kind of be not a great thing. It could be weaponized easily Even if we have kind of an audacious Braggadocious thought process that and this you know, no one you can ever hack this system and it also shows us people loving to vilify others from behind their computer screens and the anonymity that that provides and Then last you there's a lot of other Episodes that show you know when we institutionalize part of society is bad That can have some serious negative consequences. So this is white bear met against fire white Christmas These all show that when we decide the society that one thing is bad and another thing is good We can really exacerbate that with technology in a way that we don't intend So these kind of seem like horror stories But they also seem to be just a minute away from where we are right now And so in thinking about that, you know, I was thinking about you know this is really about applying technology in the right way and I think that's what we as DevOps practitioners try to do every day and So I said what about our world? What about DevOps? And I said, you know season four just came out a Month or two ago on Netflix and I said well, what if they the Netflix writers? Decided to make season five about DevOps. What would that look at look like? And so I've got six episodes of season five to talk about and the interesting thing is Episodes one through three have actually already been released There are things that have happened already And so we're gonna talk about that. The first is the Equiflax breach Pretty much everyone in the room knows about that if you don't it was a hundred and forty six million people Whose social security number and date of birth were leaked That includes myself my wife And three of my four children The fourth she was safe only because she wasn't born and didn't have a social security number when the breach happened So she's cool, but the rest of us we were part of this breach And how did it happen? Well, Equiflax had a piece of open-source software Apache struts a lot of us use patchy products or I mean assault open-source libraries And there was a major vulnerability released and it was patched by Apache within about three days Of it being released but Equiflax left this in their production environment for over a year and People had you know full rain the hackers that perpetrated this had full rain over their environment for over a year and Then once the light was shine on them crabs on security actually then found that their Argentinean employee site Had admin admin as a log in so So again once once that lights kind of shone on you there's there's lots of places that you can break down And some of us, you know, we can we can look at Equiflax and say well, that's not us You know, we have a plan in place But meltdown inspector takes that plan off the table, right and there's gonna be a talk tomorrow By Barbara who I haven't met but she's here somewhere. She's talking tomorrow about meltdown inspector in detail And she was supposed to we were supposed to go the other order. So I was gonna have all that But just if you don't know what that was a quick summary Basically, you know a processor processors got so fast that we decided Instead of waiting to figure out if a or B is gonna be true We'll just run Trains down both tracks and then whichever one of that ends up being true we take and we throw away the other train The problem with this being it allowed other applications running on the same processor as us To hijack that second train that wasn't going to be used and actually read the memory of our applications Which is really bad thing. That's the one thing we don't think about we think about data at rest and we think about Data in transit, but we don't think about the actual memory of our applications. Most of us That program in a modern programming language And so that's that's that's a really bad thing and this xkcd I think Summarizes it really well. It's probably impossible to read But my favorite part of it says Do we just suck at computers and she says yep, especially shared ones And then the third episode is night capital So if you don't know about night capital, this is talked about on a lot of devop circles night capital lost $440 million in a day And in a day actually I mean in 45 minutes That's two times their quarterly revenue at the time And how did this or 10 million dollars a minute? Um, and so how did this happen? Well When they looked at what happened What happened was there was a manual deployed a production of new trading software And the person that manually deployed that software put it on seven production servers problem is they have eight production servers and So at first when when trading opened to that day Everyone knew something was wrong just because of the volume of trades the night was doing But they didn't have a kill switch. They couldn't kill it And so as they're scrambling to figure out what's going on They actually said well, we just updated. Let's roll back So they roll back the update So that only the broken code was in production none of the working code And actually made it worse. So Yeah, that's it's not great. So again, those are three episodes that have happened already And and do show us, you know, what what can go wrong when we when we are arrogant about Our our pipelines, but there's four other episodes. I want to talk about That I think could be we could just be a minute away from if we're not careful Episode four I call the illusion of safety. So we open on a playground Dad is watching his kids play as I mentioned. I have four. So I'm familiar with this He's watching them. He laughs as they're they're running around suddenly his phone rings He looks at the phone And he sees who it is and he puts it right back down in his pocket But as soon as it touches his pocket it starts ringing again And as he picks up the phone everything around him fades to black We have we see that he's not in the park at all. He's in the office on sunday He's trying to figure out What parts of their infrastructure are impacted by a huge security breach a security issue that was discovered on friday And he doesn't know what's impacted and what's not and his boss is calling him trying to figure out Hey, are we protected from this thing? I'm hearing about in the news Because his boss doesn't want a phone call from congress to come testify Why they left this this vulnerable thing in their system for so long Episode five I call sycophene development which was a dangerous word to put into presentation because I had to say it But that's okay So in this one, you know the fixes and the features that a customer wants they're done They've been coded They've been done for weeks But we keep going back over and over trying to integrate them in meeting after meeting after meeting Trying to figure out what's wrong. Why doesn't integrate why this other code broke the code that this customer needs And molly wakes up every morning Here's her alarm and hits it knowing that You know, she just kind of grunts disapprovingly because she knows it's going to be another groundhog day of scrum meetings That really don't solve the the core problem of being able to integrate this code In the last episode I call episode six superhero or tax collector So in this episode net is awake before his alarm The need for his superpowers awaken him from even the deepest slumber He can he puts on his cape. Uh, he puts on the rest of his suit. He goes into work at work Everyone knows that he's a superhero and he knows it. He's got a tool for every problem Uh, every problem that comes up, you know, Ned knows what tool to put on to that and fix it But in reality, that's not how his colleagues see him They see him as a tax collector. They see him as every time there's a new problem There's some tool that we have to go buy spend money to integrate And and takes actually longer in the end to deliver on software So they don't see him as a superhero. They see him as a tax collector But it's not too late Uh, I do believe that it doesn't have to be this way And that actually we are all uniquely positioned to make it not be this way as dev ops professionals Right, we've been given this gift To see these kinds of problems. We've seen other people have them and fall in their face We've we've we know that innately these things can happen Uh, but that gives us the chance to make a better future for us for our development colleagues and for our customers And so there's some solutions to these problems that I want to talk about next Right, um, I think all of these things boil down to avoiding the dev ops tax We don't want to be seen as just a cost center to the business We want to be seen as a strategic advantage to the business And dev ops when it was first coined was seen as exactly that But in practice it isn't always that way And so and so how do we make it that way? Well, first of all, I think we have to take responsibility for it I think that's the most critical thing We are the dev ops professionals in this room. That's why we're here. That's why we came to this conference We have to be the change that we seek in our organizations To to drive this home And so again, that sounds really great, but the next question I would have if I were you is brennan, what can I do today? So I want to dive into a couple of things that we can go back and do today. Well, not today Not tomorrow I would have said friday, but anyway monday. What can you do monday take the weekend? But then monday. What can you do? to to improve how we deliver software And the first one i'm going to talk about is not interfacing with things like security Security should not be at the end of the pipeline. It shouldn't be something we interface with it should be integrated into the entire pipeline We also don't want to let our organizations think of dev ops as just automated builds Right that is not dev ops and we'll and we'll talk about why dev ops should enable development teams to move as fast as possible From getting ideas all the way from the business concept into production environments And in order to do that well, we've heard a couple talks about it today I think we'll hear more, but we have to orchestrate monitoring In the beginning and into all of our software pipelines So first one was security My wife told me I could not present at a tech conference and not have a star wars reference So I got star wars and a meme in one It's a two for one deal What does this mean? I think it means we need to shift left what we're doing with security Right security cannot be at the end of what we're doing in an afterthought It has to be every commit every time In order to do that it has to be automated And when we do that it becomes not a burden on teams today. It's a burden people say Oh, you know we have we got to do security before the end of the release And we're going to run run the security tests and it's going to come back with 150 things And then we're going to have this horrible choice of well, do we accept the risk of these 150 possible security issues? Some of them are probably probably false positives. Maybe I don't care about them Or do I delay the release to the customer? And so if we're if we're not bringing security into the pipeline in the beginning and shifting it to the left In our pipelines We're we're making it a burden on our teams and high performing teams get this And yes, I'm from git lab and yes, I put a git joke in it Which everyone that works at git lab told me not to keep in but I kept it in so Now you know how hard it I am So but but it's true. There was a survey done And we've got some more data on the next slide That shows that high performing teams spend 50 percent less time remediating security issues than their lower performing counterparts And along with that they have almost 30 more automated tests Uh, and so if we want to build high performing teams, which I think is what we all want to do Uh in this in this industry, we have to embrace this And why is it so important? Well, in the same survey and this graph may be hard to read It's been iterated on a number of times, but I'll I'll tell you what it says. It's okay In a survey of security professionals that had experienced a penetration attack to their environment They were asked how was the attack performed And the top two bars there the top is software vulnerability And the second bar is a web vulnerability Cross-site scripting sequel injection that kind of stuff Uh, so those are the top two ways actual attacks in the wild are being performed And things that we think about or maybe make the news a little bit more like denial of service denial of services See, I can't even read it denial of services fourth And the phishing attack is actually the the second to last and then all others as the last bar So those are the attacks that get a lot of um attention because I think they kind of speak to you know A gloomier worldview of of uh, what an attacker does But how they're really carried out is through software vulnerabilities And and so based on that what should have aquifax looked like right What what why was it possible for them to have this issue in production for almost a year? Well, if we truly automate the entire software development life cycle and shift security left It's so much simpler It's not a hard problem to solve them So instead of a manual alert to someone which someone at aquifax did get and did not tell the right people about Instead of a manual alert about some cve that came out or having to read through every cve myself Your your software Pipeline should know what libraries and open source libraries you're using And based on that it should also then look at what Vulnerabilities come out And if it knows that you use Apache struts 1.2.5 and it sees a vulnerability come out and says, okay, there's now 1.2.6 It should automatically create a merge request for that Put it into testing if we test if we care enough about our tests Then it should be able to test and put that into prod And instead of waking up to an email of 17 cvs that came out over the weekend If we could all go to we could all go to happy hour tonight Go to bed some major Apache thing gets released over overnight It was let's say it was it was a white hat hacker that found it so the patch is immediate to them announcing the vulnerability Instead of waking up to an email about the vulnerability and our boss is calling us Because they saw on cnn this morning this huge vulnerability that exists We wake up to an email that says oh your production system is already patched Right, that's what it should be. That's what it should look like So that's security Next automated builds are not ci cd And I think my fellow speakers have kind of stressed this and not stressed this as well But I also translated it into a number of languages here to make it very clear So The c part of continuous integration and continuous delivery is often lost, right? What's the c standpoint continuous Right, that means we have to integrate code early and often in the process And to do that again, we have to care about our tests and care about test passing Right, it's not okay to have flaky tests because then the human be our human minds will just Write off all the tests we've written And and not care about them And then the d in cd, you know, some people say it's delivery. Some people say it's deployment. I think it's both I think it's critical that we care about delivery and have automated packaging and automated release processes If we don't have that we're not going to be able to release fast enough. We cannot have manual steps in that process And I think again to do continuous deployment Automated deployment is obviously required and we and we saw an example of that in the last talk There's lots of different ways to do that But I think it's a requirement because in order to move at the speed of our developers And and the speed the developers are able to deliver code We have to be able to deploy into production automatically And then last is data is the new testing. So I also had to get a mean girls reference in there. So now you you all fully met me And so I took I took the the old old adage what is What is measured can be improved and I said no, no, no, what is monitored can be improved, right? The stlc right we say stlc a lot. It's a life cycle again Don't lose that life cycle part of it. It does not have an end And and because of that monitoring has to be part of the plan from the beginning And if it's not we've already lost right when monitoring is part of the plan And we have automated deploy and continuous deployment Now we can easily ship canary into production See how something works iterated on it on it much faster See how it operates in an actual production environment with actual customers using our code And that really allows us to ship what we want the way we want to ship which is ship the minimally viable change every time So that we can we can really accelerate delivery into production So, uh, you know again, I I'm Acutely aware because this is the first startup I've worked for a git lab That that sometimes when a git lab person or someone from a startup gets on stage Uh, someone might say yeah, that's great brendan. That's great for startups, but but not in my industry Uh, and and around here. I think that's especially true right the federal government We all think oh, they don't move fast enough. So not in my industry But I think that's that's dangerous And I think time has shown us how dangerous that can be Right, let's think about very traditional industries that that probably felt that way. Oh, we're not right for disruption Right transportation transportation very old industry But it was hugely disrupted by Tesla entering the market and even more so by ride-sharing platforms entering the market Something even more basic like healthcare has been incredibly disrupted by amazon deciding to enter that market and what cvs has done Even more basic than healthcare is groceries right basic human need And again amazon hugely disrupted that market by buying Whole Foods And then just stuff right internet of things means that everything Is ripe for disruption. So just things and stuff and and thus your industry despite what anyone tells you And I just want to look at amazon again for a second. So this to prove the point Are the major healthcare providers in this country with their stock prices rebased To the time that amazon announced they were entering the market with healthcare And so you can see the immediate impact That them just announcing it they don't have even have anything all together yet But amazon announcing their entry And what that did to to shareholder value value For for those healthcare companies And so again your industry is ripe for this no matter what what you say And if you say yeah, brendan, I get it I get it, but my boss doesn't get it You know, I think again It's important to remember that we are the dev ops professionals And we need to make that our problem right we need to be able to explain better To our leadership why this is a problem and why they need to care about it for the business And and again take the responsibility on ourselves And that's just kind of lastly I think it's critical to know that everyone can contribute. I think it's critical To acknowledge that we need to not build silos between different departments, right? That's the original idea behind putting the two words development and operations together into dev ops And it's something that really Hasn't been fully realized yet But we have the ability to realize that if we if we build bridges instead of silos And and that will allow us to put customer value First and allow us not to let perfect get in the way of good or perfect get in the way of shipped right And oh one other thing I had to mention because I said I would mention it on twitter Which is someone came up with a bunch of caveman black mirror episodes, which I loved So this is kind of the opposite thing and my favorite is what a fire but too much So I could go on forever and ever about dev ops, trust me And so feel free to find me at the conference. I'd love to meet as many of you as I can But if I could if if you could take one thing away From this talk, I think it should be shift left Right if we take if we take our pipelines and move everything We're doing at the end and move it a little bit to the left and continue to force things left It will allow us to you know, take control of the process from end to end the original Goal of dev ops and and really allow us to control our own destiny And when you're interacting with your boss your boss's boss your colleagues Your peers you should do that and you should choose to use Your dev ops powers for good And when we do that, I think we build a better future for ourselves A better futures for our teams together and a better future for our world Thank you