A Game of Thrones: DevOps Golden Hammers
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Gardner, Craig
DevOps is one of the Industry's great buzz words. You've heard that DevOps (or ITOps, or WhateverOps) will solve all your development-to-deployment problems and how agile processes can increase the velocity of your projects. But you also likely know that it's not a silver bullet that solves all problems. This session will discuss how DevOps helps, what the pitfalls are, and how to avoid failure while squeezing the BEST out of DevOps.
 My name is Craig Gardner and I have listed here two different roles that are significant as it applies to this presentation and to this particular conference. I am an engineering manager at SUSE and in that role I lead a team that produces what's known as SUSE Enterprise Storage based on CEPH, the open source project called CEPH. And the second role that I have listed here is that I am an adjunct instructor of computer science at a university nearby where I work. And in those kinds of experiences my students often tell me that it's great to have an instructor at the university who has real life experience in the things that are being taught. And I value that and I think my students value that. And when I am teaching at university I usually have 40 or 50 students there attending but they're there because they have to be and you're here today because you at least are presumed to want to be here to talk today. I picked up this great screenshot, this what do you call that, background screen. What do you call that, background, yeah it's a background. So I have no idea who's responsible for it. I googled it at one point looking for something interesting and I thought that's beautiful and I need to use that because I've got this Game of Thrones thing going on. There's a nice dragon represented with the SUSE logo here and I just have a few slides that just for, I think I'll just read through all of my slides and that'll be the most interesting way to go through this. And yes Mark I really don't have 413 slides that's a joke so I wanted to make sure you're. The subtitle here that I have is having to do with trying to do the right things. And as an analog to this I come to Nuremberg with some very comfortable frequency. I love coming and visiting Nuremberg to do our SUSE headquarters is here in Nuremberg. So I have the great privilege and opportunity to come and visit here with some regularity. And when I do I also like to explore the city. I like to find different places that are interesting and I like to try to go different routes to the same place from time to time. And as a case study to apply to this as I was getting ready to come here on the first day of the open SUSE conference I got lost. And for the most part on purpose right I wanted to try and find a different way of getting to the place where I was going. I knew where I was going and I chose to take a different route to get there and I ended up getting lost. I could eventually arrive at the right place and I had all the right intentions and all the tools at my disposal to do the right thing and I did it in the wrong way. And of course I did eventually get where I needed to go and that was a good thing. But sometimes we make decisions with good intentions and knowing where it is that we want to go but we make mistakes along the way. And a good team and a good organization learns from those mistakes and improves upon those kinds of things. So my point here is that as I share with you some of my thoughts both applied and academic about DevOps. I hope that you will take what I have as not mean spirited but encouraging and likewise enlightening. So as we talk about DevOps here for a moment I ask myself what does DevOps have to do with an open SUSE conference and maybe it doesn't. But I often in my academic and professional experiences have conversations with a vast amount of people that don't understand open source. Yeah, you too, right? In the classroom I am often trying to teach students about open source, about open source methods, about open source values and yet the questions persist until they get some more practical experience with open source. Their questions are limited to open sources for example just those discrete components of the lamp stack, right? Open source is just Linux and a little Apache and a little database and then some kind of application and it isn't until they start to see beyond those discrete components that there is really a broader, more valuable purpose to open source ideas and open source methodologies. But the same thing happens when I have conversations even with those kinds of customers and those kinds of organizations that deal with SUSE and Red Hat and other open source valuing companies. They don't understand what open source is intended to provide for them. So I want to try to apply this concept about DevOps through these consistent misunderstandings about what open source is intended to provide. As I talked today about DevOps we have a few victims or we have a few things that we want to make sure that we identify here and that is that DevOps is just as widely misunderstood as is the general topic of open source. I even got a recent notification in my email inbox from some group in the LinkedIn community. It happens to be the DevOps group in the LinkedIn community where someone had posted an article about how to become a DevOps. Because if there is some formula or some recipe to follow to become a DevOps, which was actually interesting how that was now known if I did that you become a DevOps by virtue of following this advice that came in this group. So there are many misconceptions about what DevOps is. So I ask you as people consider what DevOps is, is it a magic wand or a silver bullet or a golden hammer? And as we drive down to the purposes of the evolution of DevOps we want to try to economize the collaboration of all the parts involved in delivering a software solution. A textbook would tell us these sorts of things. DevOps is a practice of operations and development engineering participating together in the entire service life cycle, blah, blah, blah, blah, characterized by operations staff making use of many of the same techniques as developers. Well now that's where I think it becomes a more interesting discussion. The union of or at least the combining of the narrowing of the gap between operations and development. And perhaps if you have some experience with DevOps you will have seen a graph, a Venn diagram similar to this. This comes directly from Wikipedia as it tries to describe with great conflict what DevOps really is. It's this union of development and quality assurance and operations that is DevOps. Reality tells us some interesting things about it as people have put DevOps into practice and as people try to squeeze the value out of these principles of DevOps. We start to understand that as much as DevOps has a lot of hype, it's not really anything new. It's a process and though it sounds a little bit derogatory, it's just another process. But it's built upon a variety of very found, sorry, very sound foundational principles that have brought success to a variety of different software endeavors for many, many years. What's important to know is that DevOps as much as there is so much hype about it, it is not a silver bullet that solves all problems. But yes, DevOps surely the principles that are associated with it can work, can be made to be useful in your delivering software solutions when the conditions are right, when you've got the right people with the right attitude, with the right skills, where these people that you have that have the right skills are hardworking and are full of integrity and in lots of cases a lot of coffee. What do I mean when I say that DevOps is not necessarily new? Well, it's really an evolution of a long existing culture of trying to provide value through these principles known as continuous integration and continuous deployment. You've surely heard those before, but those are old antiquated terms. Let's go ahead and slap a new title on it called DevOps and we'll add a few extra things to it that I'll just mention to here as continuous foo, continuous monitoring, continuous updating, continuous bug fixing, continuous testing, right? All of these different continuous things. Does that mean that it's bad? Absolutely not. It's just that it's now a sexy way of trying to put these things together and a sexy way of getting these people together to deliver software values quickly, more agilely, and more effectively. It means simply more efficient collaboration amongst a variety of different entities. Well, what kinds of entities are we talking about? Yeah, it's different for different organizations, which is exactly what some process that implies agility is supposed to be all about, right? If it's an agile process, it should be able to be applied in a variety of different ways under a bunch of different circumstances and that's good. That's a good process. A good process that can accommodate some variability is a good process. You have lots of ways that these sorts of things are implemented. You have people that call it DevOps and ITOps and you even have the folks like at Google that have called this now WebOps. Yeah, that's good stuff, right? If Google says it's good and if Google gives it a title, then it's got to be the best thing ever, right? Well, some of our experts in this world that watch how these kinds of processes develop and watch how the people who are involved in these processes start to come together, you start to now assemble a lot of specialists that know an awful lot about an awful lot. But it becomes a Herculean kind of definition of what a WebOps engineer is supposed to be able to do, right? That WebOps engineer has got to be able to know everything about networking and has to have some knowledge about routing and has to know about all the different flavors of Linux and Unix that are involved and knows about caching and knows about this and knows about that and has to stop speeding trains with his teeth, right? Multi-disciplinary experts that in reality is kind of a Montgomery Scott saying, I got to make change the laws of physics, captain, right? That was terrible, wasn't it? That was a really bad Scottish accent. But you know that this becomes either an impossible task in the realms of the mythical or as you're trying to get people involved in this process who master all of these disciplines, you burn them out and they die and nobody wants that. How do we then make value out of a process that isn't new that continues to allow you to economize the collaboration of a variety of people with different skills, different aptitudes, different abilities? What does DevOps try to control? Well typically we talk about, historically we talk about, Web type applications. But that's not limited to that. In fact, I even had this great presentation from the app image guy, Simon Peter, brilliant who talked about how DevOps is very useful in terms of turning around each of the app images. When there's change, it can go through is DevOps process and validate and test and deploy these new app images on a fairly routine basis, a fairly frequent basis and in a substantial way, automated basis. It is intended to control the agility that's involved in all of the performance, scaling systems up, tearing them down when they're not needed anymore, getting the new code out as quickly as possible, at least the good code out as quickly as possible, and not being afraid to get code out there quickly that might have bugs, because you know you have confidence in your process, you have confidence in DevOps so that you can turn it around even more quickly if you find a problem. But sometimes that becomes a very difficult race condition. You don't want to be afraid to make mistakes, but mistakes look bad, you hurry to get something out as quickly as possible, you feel that your process facilitates that agility, you get something out that has now a new problem and it's a very rapid falling forward. Now I'm not trying to paint that as a bad thing, but it's something that needs to be controlled and managed. The DevOps processes want to control that flow of delivering value to the people that are using your software solution. What does it intend to fix? It's broken that DevOps has to be the sexy thing of today that everybody wants to do because it fixes all problems like a good golden hammer. Well it intends to fix poor communication and particularly that challenged communication that happens between development and deployment. And for the purposes of what it is that we're trying to fix, we typically lump the efforts of testing in with developing. But we know that you have to do testing from an ops perspective as much as you need to do testing in the dev functions. And it's important for us to not lose sight of that universality of testing. What DevOps wants to try to simplify and to enhance the collaboration of the testing efforts between the dev and the ops. So other things that DevOps wants to fix, it wants to fix the inefficiencies of handing the code over from the one side to the other. It wants to handle the inefficiencies of providing a feedback loop, both good and bad, of what's being experienced with the software solution. It wants to handle the conflicts that take place as a result of the inherent inefficiencies of that. And it wants to incorporate some sense of agility into the operations in the same way that developers have attempted to incorporate agile processes into their development practices. It's also a way, it is also an important addressing of inefficiencies that happen in terms of customers and trust. Of there being able to say, I trust what this software service is and I can give my trust as a result of the fact that there's not this conflict that happens between both development and operations. And there are lots of successful companies that do these kinds of things that use DevOps to their advantage that build trust in the teams that are producing these kinds of solutions. If you look at very highly successful people like eBay, they use a very DevOps oriented approach to how they release software. You look at Google, lots and lots of DevOps, web ops. That's their very specialized way of delivering value that everybody relies on. Everybody can count on. Google is never down. Google always gives you what it is that you need to have. And if eBay was ever down, how often would people lose confidence? How often would people start spending their money through eBay? How often would people start selling their stuff on eBay? Well there's some effectiveness that comes out of this, continuous integration and continuous deployment and continuous testing. If you've got the right people and you've got the right culture and if you've got the right product. The real problems that we have is not just an academic one. It's that you have the one side that doesn't trust the other. It's not just the trust that exists between a customer and the solutions provider. It's not just the trust between the customer and the solution itself, the software. There's the trust that has to take place and that is often the problem between what happens between development and deployment of the software solution. That IT manager that's supposed to deploy this software feels like the development process is absolute chaos. I never know what they're going to give me. I don't know if they've even tested the stuff that they're handing to me. I don't have any trust in what it is that they're handing to me on a routine basis. And not just that, I don't have any control over it. I can whine and complain to the dev team all I want. They don't hear me. They don't understand me. And nothing changes. But the same sort of thing happens from the dev side. They look at the operation side of the house and they say, I just write the code. I have no idea what those operations guys are doing with it. I don't even know if they're configuring it right. That's the reality of the kinds of things that are going on that DevOps says, we've got to fix this. We've got to bring those two together so that we don't have this mistrust. So DevOps as an ideology does these things. I'm going to skip over this slide, let you just ruminate on it instead of spending any particular time. But it allows you to collaborate more efficiently and effectively. But does that really mean that the process of DevOps makes your people collaborate better? Makes your people talk together better? No, it doesn't. It tries to facilitate it. It tries to make things easier. It tries to reduce the number of barriers that exist. But at the end of the day, it's the people that are associated with the process that do the collaborating and that do the communicating. So the process is at least trying to get those barriers out of the way and is trying to facilitate the means whereby that collaboration takes place. That's a good process. You have the kinds of things that a development team does listed here at the top. You've got the kinds of things that the operation team does with here at the bottom. And as you start to look at those, you start to understand that there are some inherent similarities. They are really largely the same thing. And so why is it that we can't get together on these things? Well, that's what DevOps wants to do. Because we're really doing the same thing, why can't we just do the same thing? And as you have the formalized definition of what is DevOps in terms of its process flow, you have these specific characteristics that are called out. You're going to code and then build and then test and then package, then release and then configure and then monitor it. And you all want to do this fairly quickly. You want to be able to have a quick pace, an agile pace. You want to be able to make changes quickly. You need to be able to do all of these things that matches the speed at which the demands for the software change. Have the speed of your delivery match the speed of the requested changes. It's not an easy thing to do. It's an interesting observation here as you look at this process flow and as my slide gives away, it looks kind of like a waterfall. And indeed, although DevOps wants very much to say, we hate waterfall, that's an antiquated process, we never want to have anything to do with waterfall, we're going to stick it to those old process guys. We're never going waterfall. The truth of the matter is, is that those waterfallish principles aren't necessarily a bad thing. And you want to make sure that you're doing things in sort of a deliberate flowing way that you can manage and that you can understand and that you can monitor and that you can improve upon. And that's what any good process is about. So instead of DevOps throwing the good of waterfall and the good of old well proven processes out, it's really just trying to refine those well intended and time proven processes like a waterfall process and just call it something cool that people can attach to and call it something that's agile so people can think that it's modern and make it as sexy as possible so that people will want to be associated with it. Again, I'm not trying to say that that means that DevOps is a bad thing, that it's a charlatan, that it's a disappointment. I'm not saying that at all. Let's just recognize what it is for what it is. So one of the really, really important details about DevOps is this principle of automation. Now did DevOps invent automation? Absolutely not. Not at all. But it makes good use of it. It incorporates it in part of its values and it really is important for us to figure out ways to do things in a more automated way. It makes it easier for us to do our work. It frees up our time of the monotonous to do the things that are more creative and useful and improvement oriented. Now you can't automate everything though. As much as we have people that exist that suggest or assert or preach that we're going to automate everything to the point that we don't have jobs anymore. And we had really interesting talk from Mark Seeger just a little while ago where he's talking about how there are some problems that are just complex that until we figure out how to automate it, we still have some smart, hardworking people that have to fix difficult problems that have to do some of the hard work. Automation should be employed both in Dev and in Ops. And it's reliant upon known consistent states. And as long as they're known and consistent, you should automate it. And that frees up our smart, hardworking time to anticipate those things that are unknown, that are unanticipated and work on how to solve those so that at some future time we can automate that particular aspect. In Dev we typically talk about those things in terms of unit tests and a variety of different things. And in configuration management is a particularly useful tool for Ops. What can be automated? Yeah, builds can be automated. That's probably the easiest thing. That's the most common thing that gets automated. But there's lots of automation used and deployed in our testing, both in Dev and in Ops. And automation is particularly useful for deployment of software, both in your test environment and in your production environments. And of course, all of the system administration, all of the servers that are involved, virtual and physical, should all be in some sort of automated mechanism and control management for this particular team. And as you do that, you start to remember that there are similarities in what Dev does and what Ops do, that you can kind of bring them together to do the same way. A quick thought from a manager's point of use. For someone who has managed Dev Ops operations in a variety of different circumstances, what does it take to be a successful Dev Ops organization? You got to have metrics. Manager everything. Knowledge is power. Make sure that, just like I was saying all throughout this, that the purpose of Dev Ops is to overcome the barriers of collaboration and facilitate better communication. You've got to be able to facilitate the dialogue between the members of the team. The ones that are being devs within the team, the ones that are performing the Ops responsibilities, you've got to facilitate that dialogue. Make sure that that kind of opportunity to talk is frequent. It doesn't have to be frequent, but that it can be as frequent as necessary. And that that kind of dialogue is not destructive. As a manager in a particular team, you've got to make sure that your team is collaborating constructively, and that those kinds of communications are well intended. Suddenly misunderstandings take place, but the better the trust that you have amongst the members of this team that are Dev Ops together, the better the communication will be. The activities of the team should be ordinary. Too often we have teams that rely upon the spectacular, the heroic, the staying to work through all hours of the night, the staying to work on weekends, the kind of heroics that burn people out. The more ordinary, the more routine, the more commonplace, the work that's being done in a Dev Ops organization, the more successful that organization will be at delivering value. Now there may be heroic periods of time, but make sure that they are infrequent and make sure that they are short. Another important managerial aspect to making sure that a Dev Ops organization is successful is to invest in the team, invest in the new ideas, have your team asking themselves routinely, what if? What if we did this different? What if we changed this? What if we implemented this? Ah, what if we did this instead of that? What if questions are fabulous in a successful Dev Ops organization? And as I have said and will continue to say repeatedly, trust, build an environment of trust. So we have the Dev Ops lifecycle. It starts with planning. You've got to make, oh, this is a great picture, a representation in Legos of MC Escher's staircase. I love it. It's really great. And it represents planning very well, right? It's a never-ending process. It's always going on. It's a mobius of sorts. This is something that has to happen. The team must make time to plan and don't leave out the operations part of this. Too often, the Devs get together and say, oh, well, we're the first part of the process. We don't need to involve the operations guys. We're just going to do our own planning and they'll figure it out later on or they'll inherit what it is that we have already planned. Bad news. Make sure that you are planning together to be successful in Dev Ops. Next step, execute. Create channels of opportunities to communicate. I mentioned that a little bit earlier in the manager special. Embrace risk. Let people take risks. Don't encourage recklessness, but bring in new innovations and new ideas that might not be incorporated, that might not be espoused, that might not actually be brought into what's being developed or the process, but allow innovation to take place and reward measurable improvements. Say you've got a new bit of automation. Recognize that. Inspire people through recognizing what it is that they're accomplishing while they're executing this complex process. The next step in the flow of the Dev Ops process is post-release. The next one I want to highlight is post-release. Make sure as you're having your Dev Ops team being successful that you make time for a retrospective. That's really important to reflect back upon what it is that you've done and how you got to where you are today. Don't stop with all of your automation at the end of the release. Make sure that you are automating stuff that happens post-release. The last thing I wanted to point out here is this concept of breathing. Allow the team to breathe. I'm going to poke fun at Scrum at the moment. This is my personal opinion and you will disagree. As far as Scrum is concerned and this concept of sprints, this is exhausting. You're constantly sprinting. I don't like that. Your experience may be different, but as I try to encourage successful delivery of software, software solutions with Dev Ops, yes, you want to be agile. Yes, you want to be adapting. Yes, you want to be fast. Yes, you want to get those new fixes and that new functionality out to your users efficiently and fast, but you've got to be able to have some time to step back and reflect and see the forest for the trees. The next I'll point out here is don't lose sight of the item in the flow of the process of Dev Ops of maintaining. I add to that sustaining. Be prepared as part of your planning and as part of your whole process to support and maintain the software after it is released and not just say, oh, I've released it. It's gone. I've got nothing to do with it anymore. Make sure that you're continuing to automate and make sure that you are continuing to monitor and measure what's going on with your software and the experiences that your customers are having, your users are using. I mentioned golden hammers and silver bullets. I also mentioned Game of Thrones earlier and I'm really not a big Game of Thrones guy, but I know a little bit about it. I just want to make sure that you realize that when you talk about a Dev Ops process, because I shared the silly representation of some hippies and stick it to the man, we ate process, we're going to go Dev Ops, we're going to be agile, man. That's kind of a bad, silly representation that makes fun of various aspects of it. But it's important to recognize that even though Dev Ops is intended to improve upon various ancient practices, it's still a process. As such, there are things that you need to do in that process. There are things that are important to accomplish in steps and with some clarity and with some formality. It may not be so rigid and formal as some of the other processes that you've been associated with, but it's still a process. It's not a golden hammer and it's not a silver bullet. It requires smart, caring, hardworking people and it requires management. It can't just happen organically. It has to have some kind of guidance and management and rules and process. So the Game of Thrones representation, and I'll quickly segue then to my Oedipus example instead of Game of Thrones, but it's one of the most popular shows in television land. People don't even necessarily watch it on TV. Everybody watches Game of Thrones on their devices after each episode with Netflix. In Europe, is there a Netflix equivalent or is it Netflix? You just have to be in a specific region. I have no idea. So everybody watches Game of Thrones on Netflix. Thanks very much. So there's Peter Dinklage. Sometimes people say I look like him. I'm short and fat. I had a beard last time I gave this presentation. So I really don't look like him anyway. Okay, well, and you have some of the popular characters, some of the more interesting characters, and then you have Jamie Lannister and you have Jon Snow and you have Daenerys. You've got these guys that are famous for killing people. Jon Snow, at least this was at the end of season five. You had five kills for Jamie. You have four kills for Jon Snow and five kills for Daenerys. So G.R.R. Martin makes these characters out to be heroes, desirable people, appealing in a lot of different ways, smart, organized, deliberate, capable, powerful. And what I don't like about the way in which these powerful people are represented is that they obtain power and manifest their power by killing people. And that doesn't work for me. I don't think that people that kill other people are heroes, right? And I'm not trying to, my point is not really to assassinate the character of the series and of the particular author, but it's just an interesting thought to me as I consider what it is that he is trying to represent through this series, this very popular series about how to be successful. And then that led me to think about something I'm a little more familiar with, and that's the play by Sophocles, Greek playwright of Oedipus, great Greek tragedy where Oedipus ends up killing his father, and in the end, a lot of bad things happen by the time this Greek tragedy is finished. And it's the point I'm trying to make here without making you read Oedipus and not trying to make you become an expert in Greek tragedy. But the takeaway here from this Greek tragedy is Oedipus owes everything to his progenitors, to his parents, to his father. And he only realizes how much he owes to his dad after he's already killed his dad. And so that's the fun. Dear dad, I'm really, really, really, really, really sorry. Oedipus, right? Before we try to assassinate and kill and exert our powerful devops by killing our parent, the waterfall, start to value what it is that we're building upon and what it is from waterfall that really was powerful and really is meaningful in terms of what it is that we want to accomplish in an open source environment, in an environment that's growing, in an environment that's trying to provide greater, greater, and greater value to users in an open way, in a way that changes the way people think, in a way that changes the way people see the world around, in a way that creates new thought and inspires action. And of course, we can sit back and say, well, it's only software. But the ideas and values that are summed up in open source changes the world. And improving upon that and spreading that message becomes a very valuable thing. And it becomes a very desirable thing. The hallmarks of success in a successful open source project, in a successful process, in a successful delivery of a solution that changes the way people do things, that improves the value of what it is that we do on a day-to-day basis, that lifts and edifies and makes the world a better place, has a few of these interesting hallmarks for success that are similar between both the dev and the ops, use configuration management. We know that very well from a dev perspective in terms of using things like a git and how grateful we are for git once we get past of how weird it is. And then all of the operations that take place with configuration management that's salt or ansible or any of a dozen different other solutions. These are the same thing that we can utilize together better in both the dev responsibilities and the operations responsibilities. We have to test. We need to be better about automating those tests. And we need to do it in much the same way between development and operations if we're going to be a successful dev ops approach to delivering software solutions. And make sure that you're doing it together. But you're not just saying, oh, I'm the developer, so I'm going to write unit tests. And you should have nothing to do with it. You QA and ops silly people. I don't have any reason for you to look at my unit tests. Don't do that. Share and collaborate what it is that you're trying to test and how it is that you're testing. And you'll be more successful. More automation, continuous deployment. These are all good hallmarks of a successful dev ops organization. I'm going to share just two examples with you from Suza. I have a good relationship with my friends in the SCC, the SUSE customer center who successfully use dev ops and deliver a valuable product, a valuable solution that customers and users appreciate. In the customer center team, they made a team decision. This wasn't thrust upon them by some evil overlord or poorly intended manager. The team got together and said, if we're going to be successful, we need to be closer together in both the dev and the ops. And we're going to use a dev ops approach to do that, to overcome those barriers of collaboration and to improve the kinds of communication that we have. So they chose to use scrum and the dev ops approach. They decided to minimize the specific roles of Joe, you're a developer, and Anne, you're an operator. It was Joe and Anne, we're doing dev ops together. We're going to have development responsibilities and operations responsibilities with no division between the roles. You might not choose to do that in your dev ops implementation, but that's the decision that the SCC team made and it has contributed to their success. One of the nice things about SCC is that it was basically a new project with new team members. It's perhaps harder to organize a dev ops process if you have a preexisting bit of software with preexisting teams that are already divided between development and operations. That's a little harder to just say, okay, we're going to stop doing what we've been doing for 10 years and we're going to change it all up. It's possible, but it's harder. In their case, it was easy to make this decision as a team because they said, we're new, we're not tied to anything old, we can make these kinds of decisions and we bring everybody together. They in this SCC team have fearless development. They're not afraid to make mistakes. They're not punished for making mistakes. They certainly acknowledge when they make mistakes, but they try very hard to say, okay, we messed up. That was a good try. We tried to be innovative. It fell short. We're going to put that aside and move on. They have as many as 40 developments throughout the day. They're rapidly creating new software on a daily to hourly to minute basis and they're not afraid to throw it out there. They're not afraid to deploy. I think I said developments. I meant deployments. You knew what I said, what I meant when I said it, right? They have 40 deployments in a day. They can push it out and have no fear that something's going to be broken. Something might be broken, but they don't fear the fact that something might be wrong because they know that on that 39th time that they deployed something and something was wrong, they can in a matter of minutes turn around and deploy the 40th time and get it fixed and move on, move beyond the mistakes. They're confident in their ability to be agile. Lastly, they're automating everything. Now do they automate everything? No. They're always trying to improve the number of automations and to improve the number of automations, but it's something that they value and they're constantly automating as much as they can. A second example is the open build service. That's a great example here where this team uses a scrum approach. They involve agile development and in a similar way, the people that are the operators that are in operations are the same people that are the developers. Everybody can push a deployment at any time with appropriate collaboration and approvals, but those kinds of agile details within operations match what's going on in the development aspects of the software and that the team does it together with very little delineation between your developer and your operator. Because not necessarily with the same rapid deployment that the SCC team uses as I indicated in the previous slide, their deployment is a little more deliberate, but they still can deploy as quickly as they want to, as quickly as it makes sense. They do extensive stress testing before any deployment. Then again, lots and lots and lots and lots of automation. Moreover, they have a fairly comprehensive way of rolling back. Here as I wrap things up, this is my takeaway for this OpenSUSA conference. What's my point? I don't know. What did you take away from this is entirely up to you. You get to choose if there is any value to this, but this is what I had hoped to communicate to you as I talk about the good and the bad of DevOps. DevOps is surely just like any other process. It's not a golden hammer. It doesn't solve all your problems. You can't just go in and say, oh, we've had all these other things go wrong with our delivering the software solution, so we're just going to use DevOps because it'll fix everything. It won't. But it can help you to be more successful if, I'll get to that in the next point, make sure that as you're thinking about the value of DevOps or the value of any process that you're thinking about your people and how your people work, it's easy to say, I've got a team of 10 people and they're smart developers and smart operators. I can just throw DevOps at them and that's not true. It doesn't mean that you can have a screw and use a hammer to drive the screw. If you've got a nail, it's darn near impossible to drive a nail with a screwdriver. Make sure that you pick the kinds of processes and the kinds of details that match how your people work. Now that doesn't mean that people can't change. Surely you can change. Surely you can encourage your team members to change and adopt and learn and grow. That's what we're here for. That's the whole reason that we're on this planet is to learn and to grow and become better. Your people can do the same thing. They can learn new processes. They can learn new tools. But don't force a process down the throat of this team of people just because you read that DevOps is the best thing and you believed the hype. The last point is most reliable results. Forget about what the process is, whether it's DevOps or anything else. The most reliable results that you will get will come via hardworking people, smart, dedicated people with high integrity, and the amount of trust and integrity that all of these different players have with each other and the quality of the communication that they have. So with that, I think that Open Source and Open Sousa and Linux espouse these kinds of ideals and that DevOps is a tool that can help make the software solutions better, but only because of the quality of you people and the amount of time and care that you put into what it is that is developed, whether it's software or anything else. Ask your questions. Anyone have any questions? You're all tired. You're worn out. You just want to get on. Where's the beer? I just wanted to say that I think you said one really important thing, which is breathe. And I feel like that's one of the things that everyone misses from talking about DevOps. It's kind of a panic all the time. We have to do so many things. We have to go faster and faster and faster. And my background is in games development before I started at Sousa. The only thing that matters there is performance. And the way you get performance is to slow down and look at what you're doing and identify things that you're doing that you shouldn't be doing and stop doing those things. So measure and optimize. And that's really the process you should be doing. So when I see people talking about, for example, automation and just talking about automating, we have to automate all the things all the time. Just automate. The problem is you're going to end up automating a lot of things that you shouldn't even be doing in the first place. So I feel like that's one aspect of the discussion that's no one really talks about when talking about DevOps and these kind of things. That's an excellent comment. Thank you very much for that supporting comment. Great. Thank you for your time. Thanks for coming to Open Sousa. What a great conference. And it's largely great because of the good people that put it together and you great people who come and support it and participate in these excellent, very well-intended and very world-changing projects. Thanks, everybody.
 My name is Craig Gardner and I have listed here two different roles that are significant  as it applies to this presentation and to this particular conference.  I am an engineering manager at SUSE and in that role I lead a team that produces what's  known as SUSE Enterprise Storage based on CEPH, the open source project called CEPH.  And the second role that I have listed here is that I am an adjunct instructor of computer  science at a university nearby where I work.  And in those kinds of experiences my students often tell me that it's great to have an instructor  at the university who has real life experience in the things that are being taught.  And I value that and I think my students value that.  And when I am teaching at university I usually have 40 or 50 students there attending but  they're there because they have to be and you're here today because you at least are  presumed to want to be here to talk today.  I picked up this great screenshot, this what do you call that, background screen.  What do you call that, background, yeah it's a background.  So I have no idea who's responsible for it.  I googled it at one point looking for something interesting and I thought that's beautiful  and I need to use that because I've got this Game of Thrones thing going on.  There's a nice dragon represented with the SUSE logo here and I just have a few slides  that just for, I think I'll just read through all of my slides and that'll be the most interesting  way to go through this.  And yes Mark I really don't have 413 slides that's a joke so I wanted to make sure you're.  The subtitle here that I have is having to do with trying to do the right things.  And as an analog to this I come to Nuremberg with some very comfortable frequency.  I love coming and visiting Nuremberg to do our SUSE headquarters is here in Nuremberg.  So I have the great privilege and opportunity to come and visit here with some regularity.  And when I do I also like to explore the city.  I like to find different places that are interesting and I like to try to go different  routes to the same place from time to time.  And as a case study to apply to this as I was getting ready to come here on the first  day of the open SUSE conference I got lost.  And for the most part on purpose right I wanted to try and find a different way of getting  to the place where I was going.  I knew where I was going and I chose to take a different route to get there and I ended  up getting lost.  I could eventually arrive at the right place and I had all the right intentions and all  the tools at my disposal to do the right thing and I did it in the wrong way.  And of course I did eventually get where I needed to go and that was a good thing.  But sometimes we make decisions with good intentions and knowing where it is that we  want to go but we make mistakes along the way.  And a good team and a good organization learns from those mistakes and improves upon those  kinds of things.  So my point here is that as I share with you some of my thoughts both applied and academic  about DevOps.  I hope that you will take what I have as not mean spirited but encouraging and likewise  enlightening.  So as we talk about DevOps here for a moment I ask myself what does DevOps have to do with  an open SUSE conference and maybe it doesn't.  But I often in my academic and professional experiences have conversations with a vast  amount of people that don't understand open source.  Yeah, you too, right?  In the classroom I am often trying to teach students about open source, about open source  methods, about open source values and yet the questions persist until they get some more  practical experience with open source.  Their questions are limited to open sources for example just those discrete components  of the lamp stack, right?  Open source is just Linux and a little Apache and a little database and then some kind of  application and it isn't until they start to see beyond those discrete components that  there is really a broader, more valuable purpose to open source ideas and open source methodologies.  But the same thing happens when I have conversations even with those kinds of customers and those  kinds of organizations that deal with SUSE and Red Hat and other open source valuing companies.  They don't understand what open source is intended to provide for them.  So I want to try to apply this concept about DevOps through these consistent misunderstandings  about what open source is intended to provide.  As I talked today about DevOps we have a few victims or we have a few things that we want  to make sure that we identify here and that is that DevOps is just as widely misunderstood  as is the general topic of open source.  I even got a recent notification in my email inbox from some group in the LinkedIn community.  It happens to be the DevOps group in the LinkedIn community where someone had posted an article  about how to become a DevOps.  Because if there is some formula or some recipe to follow to become a DevOps, which was actually  interesting how that was now known if I did that you become a DevOps by virtue of following  this advice that came in this group.  So there are many misconceptions about what DevOps is.  So I ask you as people consider what DevOps is, is it a magic wand or a silver bullet  or a golden hammer?  And as we drive down to the purposes of the evolution of DevOps we want to try to economize  the collaboration of all the parts involved in delivering a software solution.  A textbook would tell us these sorts of things.  DevOps is a practice of operations and development engineering participating together in the  entire service life cycle, blah, blah, blah, blah, characterized by operations staff making  use of many of the same techniques as developers.  Well now that's where I think it becomes a more interesting discussion.  The union of or at least the combining of the narrowing of the gap between operations  and development.  And perhaps if you have some experience with DevOps you will have seen a graph, a Venn  diagram similar to this.  This comes directly from Wikipedia as it tries to describe with great conflict what DevOps  really is.  It's this union of development and quality assurance and operations that is DevOps.  Reality tells us some interesting things about it as people have put DevOps into practice  and as people try to squeeze the value out of these principles of DevOps.  We start to understand that as much as DevOps has a lot of hype, it's not really anything  new.  It's a process and though it sounds a little bit derogatory, it's just another process.  But it's built upon a variety of very found, sorry, very sound foundational principles  that have brought success to a variety of different software endeavors for many, many  years.  What's important to know is that DevOps as much as there is so much hype about it, it  is not a silver bullet that solves all problems.  But yes, DevOps surely the principles that are associated with it can work, can be made  to be useful in your delivering software solutions when the conditions are right, when you've  got the right people with the right attitude, with the right skills, where these people  that you have that have the right skills are hardworking and are full of integrity and  in lots of cases a lot of coffee.  What do I mean when I say that DevOps is not necessarily new?  Well, it's really an evolution of a long existing culture of trying to provide value through  these principles known as continuous integration and continuous deployment.  You've surely heard those before, but those are old antiquated terms.  Let's go ahead and slap a new title on it called DevOps and we'll add a few extra things  to it that I'll just mention to here as continuous foo, continuous monitoring, continuous updating,  continuous bug fixing, continuous testing, right?  All of these different continuous things.  Does that mean that it's bad?  Absolutely not.  It's just that it's now a sexy way of trying to put these things together and a sexy way  of getting these people together to deliver software values quickly, more agilely, and  more effectively.  It means simply more efficient collaboration amongst a variety of different entities.  Well, what kinds of entities are we talking about?  Yeah, it's different for different organizations, which is exactly what some process that implies  agility is supposed to be all about, right?  If it's an agile process, it should be able to be applied in a variety of different ways  under a bunch of different circumstances and that's good.  That's a good process.  A good process that can accommodate some variability is a good process.  You have lots of ways that these sorts of things are implemented.  You have people that call it DevOps and ITOps and you even have the folks like at Google  that have called this now WebOps.  Yeah, that's good stuff, right?  If Google says it's good and if Google gives it a title, then it's got to be the best thing  ever, right?  Well, some of our experts in this world that watch how these kinds of processes develop  and watch how the people who are involved in these processes start to come together,  you start to now assemble a lot of specialists that know an awful lot about an awful lot.  But it becomes a Herculean kind of definition of what a WebOps engineer is supposed to be  able to do, right?  That WebOps engineer has got to be able to know everything about networking and has to  have some knowledge about routing and has to know about all the different flavors of  Linux and Unix that are involved and knows about caching and knows about this and knows  about that and has to stop speeding trains with his teeth, right?  Multi-disciplinary experts that in reality is kind of a Montgomery Scott saying, I got  to make change the laws of physics, captain, right?  That was terrible, wasn't it?  That was a really bad Scottish accent.  But you know that this becomes either an impossible task in the realms of the mythical or as you're  trying to get people involved in this process who master all of these disciplines, you burn  them out and they die and nobody wants that.  How do we then make value out of a process that isn't new that continues to allow you  to economize the collaboration of a variety of people with different skills, different  aptitudes, different abilities?  What does DevOps try to control?  Well typically we talk about, historically we talk about, Web type applications.  But that's not limited to that.  In fact, I even had this great presentation from the app image guy, Simon Peter, brilliant  who talked about how DevOps is very useful in terms of turning around each of the app  images.  When there's change, it can go through is DevOps process and validate and test and deploy  these new app images on a fairly routine basis, a fairly frequent basis and in a substantial  way, automated basis.  It is intended to control the agility that's involved in all of the performance, scaling  systems up, tearing them down when they're not needed anymore, getting the new code out  as quickly as possible, at least the good code out as quickly as possible, and not being  afraid to get code out there quickly that might have bugs, because you know you have  confidence in your process, you have confidence in DevOps so that you can turn it around even  more quickly if you find a problem.  But sometimes that becomes a very difficult race condition.  You don't want to be afraid to make mistakes, but mistakes look bad, you hurry to get something  out as quickly as possible, you feel that your process facilitates that agility, you  get something out that has now a new problem and it's a very rapid falling forward.  Now I'm not trying to paint that as a bad thing, but it's something that needs to be  controlled and managed.  The DevOps processes want to control that flow of delivering value to the people that  are using your software solution.  What does it intend to fix?  It's broken that DevOps has to be the sexy thing of today that everybody wants to do  because it fixes all problems like a good golden hammer.  Well it intends to fix poor communication and particularly that challenged communication  that happens between development and deployment.  And for the purposes of what it is that we're trying to fix, we typically lump the efforts  of testing in with developing.  But we know that you have to do testing from an ops perspective as much as you need to  do testing in the dev functions.  And it's important for us to not lose sight of that universality of testing.  What DevOps wants to try to simplify and to enhance the collaboration of the testing efforts  between the dev and the ops.  So other things that DevOps wants to fix, it wants to fix the inefficiencies of handing  the code over from the one side to the other.  It wants to handle the inefficiencies of providing a feedback loop, both good and bad, of what's  being experienced with the software solution.  It wants to handle the conflicts that take place as a result of the inherent inefficiencies  of that.  And it wants to incorporate some sense of agility into the operations in the same way  that developers have attempted to incorporate agile processes into their development practices.  It's also a way, it is also an important addressing of inefficiencies that happen in terms of customers  and trust.  Of there being able to say, I trust what this software service is and I can give my trust  as a result of the fact that there's not this conflict that happens between both development  and operations.  And there are lots of successful companies that do these kinds of things that use DevOps  to their advantage that build trust in the teams that are producing these kinds of solutions.  If you look at very highly successful people like eBay, they use a very DevOps oriented  approach to how they release software.  You look at Google, lots and lots of DevOps, web ops.  That's their very specialized way of delivering value that everybody relies on.  Everybody can count on.  Google is never down.  Google always gives you what it is that you need to have.  And if eBay was ever down, how often would people lose confidence?  How often would people start spending their money through eBay?  How often would people start selling their stuff on eBay?  Well there's some effectiveness that comes out of this, continuous integration and continuous  deployment and continuous testing.  If you've got the right people and you've got the right culture and if you've got the  right product.  The real problems that we have is not just an academic one.  It's that you have the one side that doesn't trust the other.  It's not just the trust that exists between a customer and the solutions provider.  It's not just the trust between the customer and the solution itself, the software.  There's the trust that has to take place and that is often the problem between what happens  between development and deployment of the software solution.  That IT manager that's supposed to deploy this software feels like the development  process is absolute chaos.  I never know what they're going to give me.  I don't know if they've even tested the stuff that they're handing to me.  I don't have any trust in what it is that they're handing to me on a routine basis.  And not just that, I don't have any control over it.  I can whine and complain to the dev team all I want.  They don't hear me.  They don't understand me.  And nothing changes.  But the same sort of thing happens from the dev side.  They look at the operation side of the house and they say, I just write the code.  I have no idea what those operations guys are doing with it.  I don't even know if they're configuring it right.  That's the reality of the kinds of things that are going on that DevOps says, we've  got to fix this.  We've got to bring those two together so that we don't have this mistrust.  So DevOps as an ideology does these things.  I'm going to skip over this slide, let you just ruminate on it instead of spending any  particular time.  But it allows you to collaborate more efficiently and effectively.  But does that really mean that the process of DevOps makes your people collaborate better?  Makes your people talk together better?  No, it doesn't.  It tries to facilitate it.  It tries to make things easier.  It tries to reduce the number of barriers that exist.  But at the end of the day, it's the people that are associated with the process that  do the collaborating and that do the communicating.  So the process is at least trying to get those barriers out of the way and is trying to facilitate  the means whereby that collaboration takes place.  That's a good process.  You have the kinds of things that a development team does listed here at the top.  You've got the kinds of things that the operation team does with here at the bottom.  And as you start to look at those, you start to understand that there are some inherent  similarities.  They are really largely the same thing.  And so why is it that we can't get together on these things?  Well, that's what DevOps wants to do.  Because we're really doing the same thing, why can't we just do the same thing?  And as you have the formalized definition of what is DevOps in terms of its process  flow, you have these specific characteristics that are called out.  You're going to code and then build and then test and then package, then release and then  configure and then monitor it.  And you all want to do this fairly quickly.  You want to be able to have a quick pace, an agile pace.  You want to be able to make changes quickly.  You need to be able to do all of these things that matches the speed at which the demands  for the software change.  Have the speed of your delivery match the speed of the requested changes.  It's not an easy thing to do.  It's an interesting observation here as you look at this process flow and as my slide  gives away, it looks kind of like a waterfall.  And indeed, although DevOps wants very much to say, we hate waterfall, that's an antiquated  process, we never want to have anything to do with waterfall, we're going to stick it  to those old process guys.  We're never going waterfall.  The truth of the matter is, is that those waterfallish principles aren't necessarily  a bad thing.  And you want to make sure that you're doing things in sort of a deliberate flowing way  that you can manage and that you can understand and that you can monitor and that you can  improve upon.  And that's what any good process is about.  So instead of DevOps throwing the good of waterfall and the good of old well proven processes  out, it's really just trying to refine those well intended and time proven processes like  a waterfall process and just call it something cool that people can attach to and call it  something that's agile so people can think that it's modern and make it as sexy as possible  so that people will want to be associated with it.  Again, I'm not trying to say that that means that DevOps is a bad thing, that it's a charlatan,  that it's a disappointment.  I'm not saying that at all.  Let's just recognize what it is for what it is.  So one of the really, really important details about DevOps is this principle of automation.  Now did DevOps invent automation?  Absolutely not.  Not at all.  But it makes good use of it.  It incorporates it in part of its values and it really is important for us to figure out  ways to do things in a more automated way.  It makes it easier for us to do our work.  It frees up our time of the monotonous to do the things that are more creative and useful  and improvement oriented.  Now you can't automate everything though.  As much as we have people that exist that suggest or assert or preach that we're going  to automate everything to the point that we don't have jobs anymore.  And we had really interesting talk from Mark Seeger just a little while ago where he's  talking about how there are some problems that are just complex that until we figure  out how to automate it, we still have some smart, hardworking people that have to fix  difficult problems that have to do some of the hard work.  Automation should be employed both in Dev and in Ops.  And it's reliant upon known consistent states.  And as long as they're known and consistent, you should automate it.  And that frees up our smart, hardworking time to anticipate those things that are unknown,  that are unanticipated and work on how to solve those so that at some future time we  can automate that particular aspect.  In Dev we typically talk about those things in terms of unit tests and a variety of different  things.  And in configuration management is a particularly useful tool for Ops.  What can be automated?  Yeah, builds can be automated.  That's probably the easiest thing.  That's the most common thing that gets automated.  But there's lots of automation used and deployed in our testing, both in Dev and in Ops.  And automation is particularly useful for deployment of software, both in your test  environment and in your production environments.  And of course, all of the system administration, all of the servers that are involved, virtual  and physical, should all be in some sort of automated mechanism and control management  for this particular team.  And as you do that, you start to remember that there are similarities in what Dev does  and what Ops do, that you can kind of bring them together to do the same way.  A quick thought from a manager's point of use.  For someone who has managed Dev Ops operations in a variety of different circumstances, what  does it take to be a successful Dev Ops organization?  You got to have metrics.  Manager everything.  Knowledge is power.  Make sure that, just like I was saying all throughout this, that the purpose of Dev Ops  is to overcome the barriers of collaboration and facilitate better communication.  You've got to be able to facilitate the dialogue between the members of the team.  The ones that are being devs within the team, the ones that are performing the Ops responsibilities,  you've got to facilitate that dialogue.  Make sure that that kind of opportunity to talk is frequent.  It doesn't have to be frequent, but that it can be as frequent as necessary.  And that that kind of dialogue is not destructive.  As a manager in a particular team, you've got to make sure that your team is collaborating  constructively, and that those kinds of communications are well intended.  Suddenly misunderstandings take place, but the better the trust that you have amongst  the members of this team that are Dev Ops together, the better the communication will  be.  The activities of the team should be ordinary.  Too often we have teams that rely upon the spectacular, the heroic, the staying to work  through all hours of the night, the staying to work on weekends, the kind of heroics that  burn people out.  The more ordinary, the more routine, the more commonplace, the work that's being done in  a Dev Ops organization, the more successful that organization will be at delivering value.  Now there may be heroic periods of time, but make sure that they are infrequent and make  sure that they are short.  Another important managerial aspect to making sure that a Dev Ops organization is successful  is to invest in the team, invest in the new ideas, have your team asking themselves routinely,  what if?  What if we did this different?  What if we changed this?  What if we implemented this?  Ah, what if we did this instead of that?  What if questions are fabulous in a successful Dev Ops organization?  And as I have said and will continue to say repeatedly, trust, build an environment of  trust.  So we have the Dev Ops lifecycle.  It starts with planning.  You've got to make, oh, this is a great picture, a representation in Legos of MC Escher's staircase.  I love it.  It's really great.  And it represents planning very well, right?  It's a never-ending process.  It's always going on.  It's a mobius of sorts.  This is something that has to happen.  The team must make time to plan and don't leave out the operations part of this.  Too often, the Devs get together and say, oh, well, we're the first part of the process.  We don't need to involve the operations guys.  We're just going to do our own planning and they'll figure it out later on or they'll  inherit what it is that we have already planned.  Bad news.  Make sure that you are planning together to be successful in Dev Ops.  Next step, execute.  Create channels of opportunities to communicate.  I mentioned that a little bit earlier in the manager special.  Embrace risk.  Let people take risks.  Don't encourage recklessness, but bring in new innovations and new ideas that might  not be incorporated, that might not be espoused, that might not actually be brought into what's  being developed or the process, but allow innovation to take place and reward measurable  improvements.  Say you've got a new bit of automation.  Recognize that.  Inspire people through recognizing what it is that they're accomplishing while they're  executing this complex process.  The next step in the flow of the Dev Ops process is post-release.  The next one I want to highlight is post-release.  Make sure as you're having your Dev Ops team being successful that you make time for a  retrospective.  That's really important to reflect back upon what it is that you've done and how you got  to where you are today.  Don't stop with all of your automation at the end of the release.  Make sure that you are automating stuff that happens post-release.  The last thing I wanted to point out here is this concept of breathing.  Allow the team to breathe.  I'm going to poke fun at Scrum at the moment.  This is my personal opinion and you will disagree.  As far as Scrum is concerned and this concept of sprints, this is exhausting.  You're constantly sprinting.  I don't like that.  Your experience may be different, but as I try to encourage successful delivery of software,  software solutions with Dev Ops, yes, you want to be agile.  Yes, you want to be adapting.  Yes, you want to be fast.  Yes, you want to get those new fixes and that new functionality out to your users efficiently  and fast, but you've got to be able to have some time to step back and reflect and see  the forest for the trees.  The next I'll point out here is don't lose sight of the item in the flow of the process  of Dev Ops of maintaining.  I add to that sustaining.  Be prepared as part of your planning and as part of your whole process to support and  maintain the software after it is released and not just say, oh, I've released it.  It's gone.  I've got nothing to do with it anymore.  Make sure that you're continuing to automate and make sure that you are continuing to monitor  and measure what's going on with your software and the experiences that your customers are  having, your users are using.  I mentioned golden hammers and silver bullets.  I also mentioned Game of Thrones earlier and I'm really not a big Game of Thrones guy,  but I know a little bit about it.  I just want to make sure that you realize that when you talk about a Dev Ops process,  because I shared the silly representation of some hippies and stick it to the man, we  ate process, we're going to go Dev Ops, we're going to be agile, man.  That's kind of a bad, silly representation that makes fun of various aspects of it.  But it's important to recognize that even though Dev Ops is intended to improve upon  various ancient practices, it's still a process.  As such, there are things that you need to do in that process.  There are things that are important to accomplish in steps and with some clarity and with some  formality.  It may not be so rigid and formal as some of the other processes that you've been associated  with, but it's still a process.  It's not a golden hammer and it's not a silver bullet.  It requires smart, caring, hardworking people and it requires management.  It can't just happen organically.  It has to have some kind of guidance and management and rules and process.  So the Game of Thrones representation, and I'll quickly segue then to my Oedipus example  instead of Game of Thrones, but it's one of the most popular shows in television land.  People don't even necessarily watch it on TV.  Everybody watches Game of Thrones on their devices after each episode with Netflix.  In Europe, is there a Netflix equivalent or is it Netflix?  You just have to be in a specific region.  I have no idea.  So everybody watches Game of Thrones on Netflix.  Thanks very much.  So there's Peter Dinklage.  Sometimes people say I look like him.  I'm short and fat.  I had a beard last time I gave this presentation.  So I really don't look like him anyway.  Okay, well, and you have some of the popular characters, some of the more interesting characters,  and then you have Jamie Lannister and you have Jon Snow and you have Daenerys.  You've got these guys that are famous for killing people.  Jon Snow, at least this was at the end of season five.  You had five kills for Jamie.  You have four kills for Jon Snow and five kills for Daenerys.  So G.R.R. Martin makes these characters out to be heroes, desirable people, appealing  in a lot of different ways, smart, organized, deliberate, capable, powerful.  And what I don't like about the way in which these powerful people are represented is that  they obtain power and manifest their power by killing people.  And that doesn't work for me.  I don't think that people that kill other people are heroes, right?  And I'm not trying to, my point is not really to assassinate the character of the series  and of the particular author, but it's just an interesting thought to me as I consider  what it is that he is trying to represent through this series, this very popular series  about how to be successful.  And then that led me to think about something I'm a little more familiar with, and that's  the play by Sophocles, Greek playwright of Oedipus, great Greek tragedy where Oedipus  ends up killing his father, and in the end, a lot of bad things happen by the time this  Greek tragedy is finished.  And it's the point I'm trying to make here without making you read Oedipus and not trying  to make you become an expert in Greek tragedy.  But the takeaway here from this Greek tragedy is Oedipus owes everything to his progenitors,  to his parents, to his father.  And he only realizes how much he owes to his dad after he's already killed his dad.  And so that's the fun.  Dear dad, I'm really, really, really, really, really sorry.  Oedipus, right?  Before we try to assassinate and kill and exert our powerful devops by killing our parent,  the waterfall, start to value what it is that we're building upon and what it is from waterfall  that really was powerful and really is meaningful in terms of what it is that we want to accomplish  in an open source environment, in an environment that's growing, in an environment that's trying  to provide greater, greater, and greater value to users in an open way, in a way that changes  the way people think, in a way that changes the way people see the world around, in a  way that creates new thought and inspires action.  And of course, we can sit back and say, well, it's only software.  But the ideas and values that are summed up in open source changes the world.  And improving upon that and spreading that message becomes a very valuable thing.  And it becomes a very desirable thing.  The hallmarks of success in a successful open source project, in a successful process, in  a successful delivery of a solution that changes the way people do things, that improves the  value of what it is that we do on a day-to-day basis, that lifts and edifies and makes the  world a better place, has a few of these interesting hallmarks for success that are similar between  both the dev and the ops, use configuration management.  We know that very well from a dev perspective in terms of using things like a git and how  grateful we are for git once we get past of how weird it is.  And then all of the operations that take place with configuration management that's salt  or ansible or any of a dozen different other solutions.  These are the same thing that we can utilize together better in both the dev responsibilities  and the operations responsibilities.  We have to test.  We need to be better about automating those tests.  And we need to do it in much the same way between development and operations if we're  going to be a successful dev ops approach to delivering software solutions.  And make sure that you're doing it together.  But you're not just saying, oh, I'm the developer, so I'm going to write unit tests.  And you should have nothing to do with it.  You QA and ops silly people.  I don't have any reason for you to look at my unit tests.  Don't do that.  Share and collaborate what it is that you're trying to test and how it is that you're testing.  And you'll be more successful.  More automation, continuous deployment.  These are all good hallmarks of a successful dev ops organization.  I'm going to share just two examples with you from Suza.  I have a good relationship with my friends in the SCC, the SUSE customer center who successfully  use dev ops and deliver a valuable product, a valuable solution that customers and users  appreciate.  In the customer center team, they made a team decision.  This wasn't thrust upon them by some evil overlord or poorly intended manager.  The team got together and said, if we're going to be successful, we need to be closer together  in both the dev and the ops.  And we're going to use a dev ops approach to do that, to overcome those barriers of  collaboration and to improve the kinds of communication that we have.  So they chose to use scrum and the dev ops approach.  They decided to minimize the specific roles of Joe, you're a developer, and Anne, you're  an operator.  It was Joe and Anne, we're doing dev ops together.  We're going to have development responsibilities and operations responsibilities with no division  between the roles.  You might not choose to do that in your dev ops implementation, but that's the decision  that the SCC team made and it has contributed to their success.  One of the nice things about SCC is that it was basically a new project with new team  members.  It's perhaps harder to organize a dev ops process if you have a preexisting bit of software  with preexisting teams that are already divided between development and operations.  That's a little harder to just say, okay, we're going to stop doing what we've been doing for  10 years and we're going to change it all up.  It's possible, but it's harder.  In their case, it was easy to make this decision as a team because they said, we're new, we're  not tied to anything old, we can make these kinds of decisions and we bring everybody  together.  They in this SCC team have fearless development.  They're not afraid to make mistakes.  They're not punished for making mistakes.  They certainly acknowledge when they make mistakes, but they try very hard to say, okay, we messed  up.  That was a good try.  We tried to be innovative.  It fell short.  We're going to put that aside and move on.  They have as many as 40 developments throughout the day.  They're rapidly creating new software on a daily to hourly to minute basis and they're  not afraid to throw it out there.  They're not afraid to deploy.  I think I said developments.  I meant deployments.  You knew what I said, what I meant when I said it, right?  They have 40 deployments in a day.  They can push it out and have no fear that something's going to be broken.  Something might be broken, but they don't fear the fact that something might be wrong  because they know that on that 39th time that they deployed something and something was  wrong, they can in a matter of minutes turn around and deploy the 40th time and get it  fixed and move on, move beyond the mistakes.  They're confident in their ability to be agile.  Lastly, they're automating everything.  Now do they automate everything?  No.  They're always trying to improve the number of automations and to improve the number of  automations, but it's something that they value and they're constantly automating as  much as they can.  A second example is the open build service.  That's a great example here where this team uses a scrum approach.  They involve agile development and in a similar way, the people that are the operators that  are in operations are the same people that are the developers.  Everybody can push a deployment at any time with appropriate collaboration and approvals,  but those kinds of agile details within operations match what's going on in the development aspects  of the software and that the team does it together with very little delineation between  your developer and your operator.  Because not necessarily with the same rapid deployment that the SCC team uses as I indicated  in the previous slide, their deployment is a little more deliberate, but they still can  deploy as quickly as they want to, as quickly as it makes sense.  They do extensive stress testing before any deployment.  Then again, lots and lots and lots and lots of automation.  Moreover, they have a fairly comprehensive way of rolling back.  Here as I wrap things up, this is my takeaway for this OpenSUSA conference.  What's my point?  I don't know.  What did you take away from this is entirely up to you.  You get to choose if there is any value to this, but this is what I had hoped to communicate  to you as I talk about the good and the bad of DevOps.  DevOps is surely just like any other process.  It's not a golden hammer.  It doesn't solve all your problems.  You can't just go in and say, oh, we've had all these other things go wrong with our delivering  the software solution, so we're just going to use DevOps because it'll fix everything.  It won't.  But it can help you to be more successful if, I'll get to that in the next point, make  sure that as you're thinking about the value of DevOps or the value of any process that  you're thinking about your people and how your people work, it's easy to say, I've  got a team of 10 people and they're smart developers and smart operators.  I can just throw DevOps at them and that's not true.  It doesn't mean that you can have a screw and use a hammer to drive the screw.  If you've got a nail, it's darn near impossible to drive a nail with a screwdriver.  Make sure that you pick the kinds of processes and the kinds of details that match how your  people work.  Now that doesn't mean that people can't change.  Surely you can change.  Surely you can encourage your team members to change and adopt and learn and grow.  That's what we're here for.  That's the whole reason that we're on this planet is to learn and to grow and become  better.  Your people can do the same thing.  They can learn new processes.  They can learn new tools.  But don't force a process down the throat of this team of people just because you read  that DevOps is the best thing and you believed the hype.  The last point is most reliable results.  Forget about what the process is, whether it's DevOps or anything else.  The most reliable results that you will get will come via hardworking people, smart, dedicated  people with high integrity, and the amount of trust and integrity that all of these different  players have with each other and the quality of the communication that they have.  So with that, I think that Open Source and Open Sousa and Linux espouse these kinds of  ideals and that DevOps is a tool that can help make the software solutions better, but  only because of the quality of you people and the amount of time and care that you put  into what it is that is developed, whether it's software or anything else.  Ask your questions.  Anyone have any questions?  You're all tired.  You're worn out.  You just want to get on.  Where's the beer?  I just wanted to say that I think you said one really important thing, which is breathe.  And I feel like that's one of the things that everyone misses from talking about DevOps.  It's kind of a panic all the time.  We have to do so many things.  We have to go faster and faster and faster.  And my background is in games development before I started at Sousa.  The only thing that matters there is performance.  And the way you get performance is to slow down and look at what you're doing and identify  things that you're doing that you shouldn't be doing and stop doing those things.  So measure and optimize.  And that's really the process you should be doing.  So when I see people talking about, for example, automation and just talking about automating,  we have to automate all the things all the time.  Just automate.  The problem is you're going to end up automating a lot of things that you shouldn't even be  doing in the first place.  So I feel like that's one aspect of the discussion that's no one really talks about when talking  about DevOps and these kind of things.  That's an excellent comment.  Thank you very much for that supporting comment.  Great.  Thank you for your time.  Thanks for coming to Open Sousa.  What a great conference.  And it's largely great because of the good people that put it together and you great  people who come and support it and participate in these excellent, very well-intended and  very world-changing projects.  Thanks, everybody.
openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_0_203.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_204_251.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_252_335.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_336_443.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_444_647.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_648_719.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_720_1283.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_1284_1607.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_1608_1931.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_1932_6179.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_6180_10391.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_10392_11207.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_11208_12059.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_12060_12683.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_12684_14975.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_14976_16979.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_16980_18227.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_18228_19403.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_19404_20699.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_20700_23795.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_23796_25271.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_25272_28955.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_28956_31295.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_31296_32615.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_32616_33539.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_33540_37283.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_37284_40043.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_40044_41195.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_41196_45815.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_45816_47123.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_47124_48263.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_48264_50459.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_50460_51299.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_51300_51515.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_51516_53171.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_53172_53615.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_53616_53759.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_53760_53807.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_53808_54395.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_54396_54635.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_54636_55271.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_55272_56963.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_56964_57431.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_57432_59087.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_59088_59207.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_59208_59363.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_59364_59999.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_60000_60167.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_60168_60275.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_60276_63155.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_63156_63203.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_63204_63323.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_63324_68759.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_68760_70943.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_70944_76079.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_76080_76187.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_76188_76235.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_76236_76283.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_76284_77015.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_77016_77063.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_77064_78179.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_78180_78239.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_78240_78287.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_78288_78383.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_78384_78479.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_78480_78527.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_78528_78611.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_78612_78659.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_78660_78803.png openSUSE_Conference_2017_DevOps__delivering_value__Z1gMalgZBAE_78804_78923.png