 All right, we can move closer. This is a huge space for the amount of people in here. So come close. Welcome to Chef and DevOps for pointy hares. How many people do we have here who are in technical roles? OK, so most of you. And how many pointy-haired bosses? Or people in non-technical roles? OK, awesome. Here's a little overview of what I'm going to be chatting with you about today. We're going to talk about the need for DevOps and how DevOps meets that need. And then go into a little bit on some tips on explaining any technical topic to non-technical individuals. So hopefully I have a little something for everyone. But before we go any further, let me give you a little bit more about me. I'm Victoria Blessing, and I'm an operations engineer for the College of Architecture at Texas A&M University. I graduated from A&M back in 2014 and actually have worked with the College of Architecture since I was a freshman back in 2010, working my way up from the help desk, eventually into the full-time role that I'm in now. And because of that, I got to be a part of our DevOps journey, which started in 2013 and got to be in it from the beginning. And that's been a really great experience for me. I have a passion for cooking and food in general, and I'm a professional yak shaver. So some of you might be familiar with the term, and my gift didn't load, so that was, unfortunately, you're missing out. Some of you might be familiar with the term, but for the rest of you that are wondering what the heck I'm talking about, the term yak shaving was coined by Carlin Vieri at MIT. And it refers to a series of tasks that must be completed in order for you to be able to do what you were trying to do in the first place. So while it can really be applied to any aspect of life, it's something that we in IT constantly fall victim to. Getting caught up in the little details it takes to get things done, and then we're constantly fighting fires. It's a part of the culture problem that we have. Business and IT cultures have evolved to be very siloed. So you have separate business silos, and then you have silos within the IT silo. Itself, so everyone's doing their own thing, and these disjointed pieces are expected to achieve business goals together. Each silo is doing their own piece of the puzzle without seeing the big picture, or knowing what the other pieces look like. And when it comes time to put them together, some of those pieces aren't gonna fit, which will require more time to fix, and you're gonna blow deadlines in order to end up with the finished product that you need. The momentum of business velocity just keeps getting faster and faster. Businesses have to be able to quickly release changes and new products to keep up with the changing market. Your competitors are adapting, and if you're not willing to also adapt, you'll become obsolete. To illustrate this issue, let's bring in Dilbert and Alice. For the purposes of our chat today, Dilbert is an applications developer on the dev team, and Alice is a sysadmin on the operations team. Dilbert the developer and Alice the sysadmin work in a classic IT environment where there's essentially a wall between the dev and ops teams. The dev team is expected to develop their applications and then just toss them over the wall to the ops team, who then has to make them work in production, even though it may have been developed in an entirely different environment than the one it's supposed to run in. The ops team gets backed up because it takes time to build out the systems, and they're constantly having to debug issues in order to get the app to run in production. They're missing deadlines left and right, and they simply aren't meeting customer demand. Alice is mad at Dilbert for always giving her code that won't run on her system, and Dilbert is mad at Alice for her long lead times, and because there's no communication due to this brick wall. So the vicious cycle continues, but what if there was a solution? What if we could break down that wall and encourage cross team communication and collaboration? What if there was something that helped your business adapt quickly with the changing market? And the answer is DevOps. DevOps is a cultural movement at its core. It requires organizational change to be truly successful, and while the name implies a combination of the dev and ops teams, and that's often a big part of what DevOps means to an organization, it's often a cultural change that can be applied to all areas of the business. It's about breaking down walls and getting rid of those silos and having channels of constructive communication throughout your teams. The Phoenix Project, you need to read this book. And if you have read this book, you should be making sure that your boss and all your colleagues have read this book, but if you have read it, then you don't need me to be telling you that because you know. It's a phenomenal book written in an entertaining novel format that explains DevOps and how to implement DevOps culture. It's written in a way that anyone can read it, and in my opinion, everyone should. This book is what was used by our office to help kickstart our DevOps journey. The book takes you through a narrative about an IT manager who has 90 days to fix a majorly over budget and overdue project or has its entire department outsourced. It draws correlations between IT and a finely tuned manufacturing plant. It helps to identify the problems in your organization and the changes that you need to make to solve them. The ways are the lessons imparted by the mentor to the main character in the book. There are ways that you need to change your organization. The first way emphasizes the performance of the entire system. It's about taking ownership of the project as a whole. You need to be concerned with the final outcome. The second way talks about feedback from ops back to dev and vice versa. Communication is critical. You need to have open channels of communication across your teams. And the third way is about creating a culture of continual improvement and experimentation. You need fast moving iterative development. So Dilbert and Alice's organization has decided that they're ready to jump on board and adopt a DevOps culture. So they tear down the wall between their teams and start working together. A critical part of success here is the communication and feedback loops. Dilbert and Alice keep each other informed about the status of their projects and issues. Dilbert isn't just throwing his applications over the wall to Alice and expecting them to work. Alice can talk to Dilbert about systems requirements so that Dilbert can develop the application with the system in mind. Everyone is on the same page. They're not unable to address issues together. They're not hunkered down in their silos and not communicating. They share the same big picture and are both invested in the final project. Having a shared ownership of the project fosters an environment where Dilbert and Alice care about their work and the quality of each other's work. In my office, we have a very small team, so adopting a DevOps culture was easier for us than it might be at a large corporation. It was almost a natural progression for us. I'm managing our web infrastructure and I work closely with our web developer in order to deliver our services. Since we adopted DevOps around the same time that I actually got into systems administration, I haven't really experienced what it's like without it and I can't imagine not having the communication that we do have. It's great to have a constant exchange so that we know that we're delivering the best product the right way. There's a lot of benefits that organizations find often come with adopting a DevOps culture. The bottom line is you're gonna have happier, less stressed employees. It's easier for your employees to focus on what probably excites them the most, developing and building new things rather than constant firefighting, fixing issues and babysitting existing services. You're going to be adding value to your business along with saving time and improving your product. You can ship your product faster and more reliably. There's a lot of different tools in the DevOps toolkit. You'll find that DevOps shares a lot of tools and procedures with the agile business practice. DevOps has kind of done for operations what agile did for development a few years ago and now it brings it all together so that our teams can work together. Other DevOps tools may be used by organizations who have not yet adopted the culture change. So it's possible that many tools that are considered DevOps tools can be used without adopting a DevOps culture but you're not gonna get that full advantage of the DevOps movement without making that culture change. Automate, automate, automate. You can't have DevOps without some automation and a good way to improve workflows and productivity is with a configuration management tool which is essentially used for the automation of systems management and software deployment. Chef is great but I'm biased. Chef is what I use, know and love but there are plenty of good options these days. You just have to evaluate the options and decide what is gonna work for you. They all have pros and cons and I'm depending on what your environment is and I don't know much about many of the others and I'm not going to push any one product but if anyone wants to speak with me about Chef further you can catch me later. Many of these do both provisioning and configuration management allowing you to prepare the server and then set it up and as such I tend to roll these together under the configuration management umbrella so let's talk about the configuration management tool. Dilbert and Alice have implemented the culture changes and they're ready to have a physical tool that will supplement this change. So they choose a configuration management tool. It allows them to develop a code base that orchestrates application deployments and can provide a solution in disaster recovery situations. It provides a unified solution. Dilbert and Alice can use the same tools rather than their own cobbled together tools to try to meet their end goal. Dilbert can use the tools to bring together the pieces of the application and deploy them and Alice can use the tools to manage her infrastructure and allow her to quickly deploy even thousands of servers in a short amount of time. They can quickly iterate through new releases and keep up with market demand. They will have happier customers and can easily scale and grow as needed. Some of the other tools that you may or may not already be using that round out a good DevOps toolkit include version control, a ticketing system, or Kanban, resource monitoring, and metrics gathering. You can't successfully implement configuration management without using a version control system. And you take anything away from this today. If you aren't using version control, it's a simple way to save yourself and your organization a lot of heartache. I'm partial to Git as I help administer the GitHub Enterprise instance at Texas A&M, but there are plenty of good options. You can choose from Subversion, Mercurial, Perforce, and others. Managing projects through a ticketing system and or some other type of Kanban board improves workflows. With the automation of your systems management, you're going to need to make sure that you're monitoring your resources. There are monitoring tools offered through some of the configuration management solutions, or you can use something like Nagio, Sinsu, or Zavix. You also want to be gathering metrics and doing analytics to help figure out how you can improve. I'm not going to lie to you, there will be initial technical debt. That often ends up being a stumbling block or a barrier to entry for many organizations. Oh, we don't have the time to implement that, the right tools. But you have to be willing to take the leap in order to reap the rewards. Yes, there's initial technical debt, but the rewards are exponential. Some other reasons why DevOps doesn't get adopted, the value of DevOps isn't understood. DevOps is often a grassroots movement, but it does happen the other way around sometimes. There's always going to be pushback, no matter what type of idea you're trying to get adopted in your organization. But you have to find the value that it will provide to your organization and talk to the right people that are going to be able to make it happen. You don't have common management between ops and devs. In a large organization, your groups may be extremely siloed and there may be no common management across your teams, making a cross-team change like this difficult. This is where you may have to go all the way to the top in order to instigate change. Your cultural changes may include major organizational changes in order to better align your teams to work together. It's too expensive. Let me tell you, as someone who works in a very small IT shop and one of the smallest colleges at a public university, you can do it. Yes, there's plenty of awesome, flashy, expensive DevOps tools. Yes, they're awesome and I can't afford them either. But there's also plenty of great open source tools that are available to you. And it doesn't cost anything other than that technical debt to set it up upfront. The bottom line is there's no right way to do DevOps. You have to bring DevOps culture in and mix it with your existing culture to find a happy medium that works for you. Everyone's going to use a different mix of tools and because your environment's very greatly. So now that we've talked about DevOps, let me close it up with a little conversation about some of the principles that I use in my explanation that you can apply to explaining any technical topic. So Dilbert and Alice have trouble when it comes to needing to explain things to their pointy-haired boss. I personally have the advantage of having a boss who moved up from a technical role so he at least knows just enough to get him by. But not all of us are that fortunate. We often find ourselves having to explain things that are technical, something that we may hold near and dear to someone who just doesn't get it. So tip number one is don't listen to dog bird. But let me share some dos and don'ts that should help. It's easier to be engaged when you know what to expect. For example, I gave you an outline at the beginning of our chat today and you already know when the session was scheduled so with that knowledge you're able to set reasonable expectations when coming in and it makes it easier for you to pay attention. You don't wanna make assumptions about what people already know. It's better to say something that people already know than to leave something out. It may seem tedious to you but don't gloss over fundamentals. They could be key to your audience understanding anything you say at all. You don't want your listeners to miss out on the rest of what you're saying because you left out the basics. If you're talking to your boss then you're probably already familiar with what he or she does or doesn't know. But if you have an audience that you're less familiar with you can ask questions to help gauge their knowledge. Like back at the beginning when I asked for a show of hands it showed me some audience demographics that helped me know my audience. In a one-on-one or small group setting you have a better opportunity to gain more knowledge about your audience than I can in this setting. Don't rush through what you have to say. This is of course good advice no matter the presentation or audience. And I have been going a little bit fast. No one can grasp what you have to say if you rush through at a hundred miles a minute. Everyone comes into situations with certain expectations. Expectations often get in the way of understanding. A non-technical individual particularly one who hasn't met you before may have extremely stereotypical expectations about you, the technical expert who's coming in to explain something to them. Surprise them. While technical individuals really care about the features non-technical individuals are much more easily sold on benefits. When you're preparing go through the list of features that excite you and think about why. What does this feature do to benefit me, my department or my company as a whole? It's often helpful to use familiar concepts to explain new concepts. I've been using the Dilbert analogy today but it can be as simple as comparing a slow running service to a major highway. Too many users is like too many cars on the road at rush hour. The best way to sell something to someone is to show them why it matters to them. Interest is often directly proportional to personal investment. For management decision drivers are often monetary ones. You're gonna have to show that the benefits outweigh the costs. Ask yourself in what ways does this save us money and in what ways does this make us money? It's critical that you listen to your audience and use their questions to help you adapt your content to make sure that you're getting your point across. Questions often bring up things in a different perspective that will help you see it from their point of view as well as making sure that you can further their understanding. Don't focus on making your audience understand at the level that you do. They're usually only concerned with a higher level big picture. It can be hard to find balance to make sure that you're getting your audience enough information and not over sharing. Don't get caught in the minute details. Avoid jargon that has no meaning to your audience. We love our acronyms and we have lots of phrases and jargon that has no meaning to a lot of people. And then every different technical sector has their own jargon. So do your best to use terminology that requires little or no explanation. Having to explain even the words you're using will make it hard to hold everyone's attention. It can be easy to bring in content that really is irrelevant. Try to keep a clear path. When you're explaining something technical, it's very easy to begin talking about something and then realize that you can't really explain a certain piece of it and then just kind of drop it and move on. And that's gonna cause confusion. Decide ahead of time what is essential. You never wanna sit in a high and mighty position and lower your knowledge over someone. The quickest way to shut down your listeners to talk down to them. So don't insult them. Sometimes people just don't get what you're trying to say. It's easy to be passionate about something and excitedly explain it, only to find that the person you're explaining it to just doesn't get it, but you don't wanna get flustered. With these tips, Dilbert and Alice should have an easier time navigating meetings with the pointy-haired boss. But let's face it. It's still gonna be a minefield. So hopefully you have an easier go. So our problem is ever-increasing business velocity and ever-changing customer demands and keeping our Dev and Ops teams and the rest of your teams on schedule to meet goals. And we've seen how these cultural and practical changes of DevOps can help you keep up and provide the best possible service and product. And then I wrapped up with some tips on explaining any technical topic. So I hope everyone got a little something out of this today. Are there any questions that I can answer? And I apologize, that was much too fast. Oh, okay. I'm sorry, I can't hear you. Absolutely. Well, I mean, it would start with you making sure that you don't do it, but in terms of, you can't control other people's actions, unfortunately. But yeah, starting with you and making sure that you're not talking down to anyone, I guess, did all of you hear what she said? Okay. Making sure that it starts with you and if someone is being really bad about that, just say, hey, why don't you rephrase that? Can be a helpful way to say, no, no, don't do that. Anyone else? Yeah. Yes, because I work for the College of Architecture, which is a small college within the university. There's 13 different colleges. We actually recently went through, we were trying to adopt Chef at the university level rather than just the individual siloed colleges. And so working with some of the other colleges and being able to determine what would be an ROI on a product like Chef. And one of my colleagues actually went through and made a document of, you just have to evaluate, it's basic, listing out costs and listing out your benefits and comparing them and showing that this benefit is going to outweigh the cost. Yay, you get an extra long break.