Chef and DevOps for Pointy-hairs

Video in TIB AV-Portal: Chef and DevOps for Pointy-hairs

Formal Metadata

Chef and DevOps for Pointy-hairs
Title of Series
CC Attribution - ShareAlike 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 and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this license.
Release Date

Content Metadata

Subject Area
Whether you're a pointy-haired boss or just a technical individual looking to explain Chef and the DevOps movement to the people who hold the purse strings, this session is for you. We'll discuss DevOps, configuration management, and Chef in high-level business terms, and how such low-level topics directly correlate to business value. I want to arm you with the basics of selling your boss on something, not only as it relates to Chef, but to be used as a skill in general.
Operations research Boss Corporation
Online help Student's t-test Architecture Term (mathematics) Operator (mathematics) Cuboid Integrated development environment Office suite Series (mathematics) Computer architecture Task (computing) Area Operations research Boss Corporation Shift operator Bit Hecke operator Mereology Integrated development environment Order (biology) Self-organization Video game Quicksort Sinc function Resultant
Momentum Multiplication sign Mereology Flow separation
Online chat Mathematics Integrated development environment Velocity Operator (mathematics) System administrator Software developer Adaptive behavior Mathematical analysis Cartesian coordinate system
Group action Presentation of a group System administrator Workstation <Musikinstrument> Water vapor Perspective (visual) Expected value Type theory Different (Kate Ryan album) Automation Office suite Information security Error message Physical system Collaborationism Building Software developer Constructor (object-oriented programming) Electronic mailing list Shared memory Sound effect Lattice (order) Wave Data management Arithmetic mean Telecommunication Order (biology) System programming Cycle (graph theory) Programmschleife Web page Point (geometry) Open source Connectivity (graph theory) Device driver Product (business) Number Goodness of fit Energy level Metropolitan area network Computing platform Focus (optics) Information Content (media) Line (geometry) Cartesian coordinate system Word Error message Integrated development environment Software Web-Designer Mixed reality Family Greatest element Building Code Multiplication sign Decision theory View (database) Combinational logic ACID Mereology Computer font Formal language Web 2.0 Mathematics Analogy Cuboid Software framework Process (computing) Position operator Area Boss Corporation Service (economics) File format Data recovery Feedback Entire function Self-organization Normal (geometry) Software testing Right angle Whiteboard Procedural programming Fundamental theorem of algebra Sinc function Implementation Server (computing) Service (economics) Software developer Feedback Data recovery Collaborationism Virtual machine Cross-correlation Telecommunication Operator (mathematics) Software Integrated development environment Software testing Analytic continuation Software development kit Operations research Addition Projective plane Configuration management Voting Logic
so welcome to share and about 4 . 8 years and how many people in the audience here are serving a technical role OK so most of us but how how many are in a but how many you point your bosses do we have and how about people who were in a non-technical but also non-managerial roles we have 1 and OK also here's a usual
overview of organ be chatting about today so I'm going to be talking about the need for the box and how they're lots and chef needs that need in a sort of high-level overview and that's appropriate for appointing here bosses and then I'll give some further general tips on explaining any technical topic and to non-technical individuals but 1st a little bit about me I am an operations engineer for the College of Architecture at Texas a & M University I graduated from a union a back in 2014 and have actually been working with the college architecture since I was a freshman back in 2010 I worked my way up from being a student work on the help desk and worked at 2 different roles until I got into the role in today and as a result of that I've gotten to grow with my environment as we adopt a shift back in 2013 gone to grow with that I love to get to be a chef at home in a shop in the office and I'm a professional Jack Shafer
so and this not quite the so you familiar with the term but the rest of you are wondering what the heck I'm talking about the term yak shaving was coined by calling area at MIT and the 1st of a series of tasks that you need to complete in order to actually complete the the tacit you wanted to do in the 1st place so it they can really be applied to any aspect of life but it's something that we in IT constantly fall victim to getting caught up in the
little details that it takes to get something
done and constantly fighting fires is 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 silos everyone does their own thing and he's disjointed pieces are expected to achieve business goals together each silo is doing their piece of the puzzle without sit without me implicit the real picture or seeing what these other pieces look like until it comes time to put them together and some of those pieces are going to fit so that requires extra time to fix and you end up blowing your deadlines the momentum of business
velocity just keeps getting faster and faster businesses have to be able to quickly release changes to be able to keep up with but to look it up with the changing market the your competitors are adapting and if you're not willing to adapt to you're going to become obsolete for the
purposes of our chat today Dover is applications developer on adapting and Alice a sysadmin on the operations team the where the developer analysis sysadmin work in a classic IT environment where there essentially a wall between the arts and their teams the debt team develops the
applications and then tosses them over the wall to the ob steam isn't expected to make it work and production even though it may have been developed in an environment that's totally different from the 1 it's going to run it so the up steam gets backed up because it takes time to set up a systems and then it takes time to work out the kinks that day in order to make the code run on in the system in production they're missing deadlines left and right and art meeting customer demand houses Manitoba for always giving your code that will run on her systems and over his man Alice long lead times and there's no communication because of this brick wall and so this vicious cycle continues but what if there was a solution what if we could break down this wall and encourage cross-team collaboration and communication what if there was something that helped your business adapt quickly with the changing market and the answer is Dev Ops the box is a cultural movement score it requires organizational change to be truly successful and while the name implies a combination of death and ops and that often becomes a big part of what it means to organization it can really be applied to any area of the business this cultural change can be applied the but it's about it's about breaking down walls and getting rid of these silos we need to have channels the construction can constructed communication throw all your teams so the Phoenix Project you need to read this book and you have read this book then you should be making sure that your boss and all your colleagues have read this book it's a phenomenal book that's written in an entertaining novel format the and it explains that box and how to successfully implement DevOps culture it's written in a way that anyone can read it and in my opinion everyone should this this book is what we use in our office to help kick-start our own DevOps journey the book takes you through a narrative that's a of about an IT manager who has 90 days the fix and over budget overdue project or have his entire department outsourced it draws correlations between IT and a finely tuned manufacturing plant chart it helps you identify the problems that you have in your organization and find ways to solve them the waves are the lessons imparted to the main character by the minotaur in the book and these are ways that you need to effect change in your organization the 1st way emphasizes the performance of the entire system everyone must begin to concerned with the final product you need to take ownership of the whole project the 2nd way talks about feedback from office back to Denver and vise versa so that improvements can be made it's about communication and he needed open channels of communication across your teams the 3rd way is about setting up a culture of continual experimentation improvement you need a fast moving iterative development so don't houses organization is ready to jump on board With the DevOps culture and so they tear down this wall that they have between the teams and start working together a critical part of
this assess here is communication and feedback loops though burden Alice keep each other informed about the status of projects and issues and what isn't just throwing applications over into the abyss over the wall expecting else to work some magic to make them work Alaskan talked adobra about systems requirements and over can develop that application with the system in mind everyone is on the same page and they work together to address issues as they arise rather than being hunker down in their silos and not talking to each other they share the same big picture underinvest in the project as a whole Dillard Alice care about their work and the quality of others work in my office we have a very small team so it may be adopting a DevOps culture easier for us then it might be that a large corporation but I'm managing our Web infrastructure and I work very closely with our web developer to deliver services since we adopted box around the same time that I got into systems administration I this is the norm to me I I don't know I I can imagine being pitted against the web team instead of having constant change to make sure that we're delivering the best product in the right way so there's a lot did a lot of benefits that organizations often find when it comes to adopting I denotes culture and the bottom line is you're gonna have happier less stressed employees it's easier for your employees to focus on what excites the most probably developing and building new things rather than the constant firefighting fixing issues and babysitting existing services happier employees are more productive employees there are a lot of different tools and that OPS toolkit and you'll find the DevOps actually shows a lot of tools and procedures of agile business practice and that has a lot to do with that's something that actually stemmed from other develops tools can be used by organizations that have adopted the cultural change it is possible to use them without adopting the culture but a full at a full adoption of the culture change in addition to using the tools is what gives you the full benefits of the DevOps movement on May order me automate you can have that out of the box about some automation and a good way to improve workflows and productivity is with a configuration management tool which is essentially a way to automate systems management and suffer deployment and since workshop come let's talk about chef don't Alice have implemented the culture changes in are communicating but they need a physical tool to supplement the culture change so inter chef Shep allows them to develop a code base to orchestrate application deployments and can provide a solution and disaster recovery situations it provides a a unified solution Doran Alex Dover and Alice can use the same tool rather then using their own cobbled together tools but to bring the the pieces together those working in a shaft to bring the pieces of this application and deploy them an Alaskan you shaft a major infrastructure and allows it to deploy even thousands of servers in a very short amount of time they can quickly iterate through new releases and keep up with market demand they will have a happier customers and can very easily scale and grow as needed but shot isn't really just 1 tool it's a tool kit depending on how you want to use it the we very mention the automation of systems and suffer development and this can be done with the open-source shut server so as you can see here you have some tools on your workstation and you can send the cookbooks opt into the chef server and these are the chef server can then talk to all your notes other open-source tools are habitat and inspect habitat is a new approach to the automation that focuses on the application rather than the infrastructure that with habitat the acid you build deploy and manage behave consistently on any platform spend less time on the environment and more time building features Inspec allow you to bring your security team in the party it's a testing framework with human and machine readable language that allows you to manage the compliance and security your applications continuously with coded policies so should is both on an open-source platform and has some open-source components but of software is also developed some wonderful commercial products on top of that which is evolved to be the new chef automate which is branded as a DevOps platform and allows you to have a unified workflow into invisibility and automated compliance so you can see on the bottom we have the 3 some open-source tools that share provides and automate provides a on platform on top of that that allow you to pull in things from those those 3 tools and a larger you have visibility across all your nose and logic to control your workflow so you can achieve continuous delivery of applications but 1 of the best components of the shaft family is the chef community because its home in the open source realm a fantastic community has been built around shaft and this community once succeed in whatever you're doing not at all when Alice have begun to you chef and automate their environment they will find themselves freed up to focus on new and exciting the development of perhaps even want to automate next rather than the mundane day-to-day that can be handled with lobotomies chef and because kosher usually automates things that you have to do often it greatly reduces the room for human error you know exactly what it's going to and it's going to do it exactly when you tell it to do it it do the same way every time your services can become more reliable because you can count on chapter manage them and keep them up and these benefits in a world of difference in are changing market so now we share some tips for explaining taken of topic technical topics in non-technical people and some of the principles that I just used to explain their votes and Jeff there it Alice have trouble when it comes to needing to explain things to the pointy haired boss I personally have the advantage of having a boss that moved up from a technical so at least he knows just enough to get by but not all of us so that fortunate we often find ourselves having to explain something technical something that we may hold near and dear to someone who is non-technical and we might have trouble breaking that down to them but at number 1 is don't listen to doctors the another share some do's and don'ts that should help the so it's easier to be engaged when you know what to expect for example at the beginning I gave you an outline of what we're going to talk about and you also already know when the session is scheduled to end so that knowledge you're able to set reasonable expectations coming in and it makes it easier to pay attention you don't make assumptions about what people know it's better to say something that they already know that the leave something out amazing tedious to you but you don't gloss over fundamentals it could be key dear audience understanding anything you say at all you know what 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 probably already familiar with what here she does a doesn't know but if it's a familiar that you let it is all audience that you must similiar with the new 1 asks questions to help gage their knowledge such as what I used to get an audience demographic at the beginning of my talk but in a 1 1 a small group you have a better opportunity to get better information than I think it was just a show of hands don't rush to what you have to say this is of course good advice matter presentation audience no 1 can grasp what you have to say if you rush through at 100 miles of every comes in the situations with certain expectations expectations can often get in the way of understanding a non-technical individual particularly someone who has a met you before maybe may have an extremely stereotypical expectation about you have the technical expertise coming in to explain something to them you want a surprise them there's nothing I like more then define expectations all technical individuals really care about features non-technical individuals are much more easily so long benefits when you're preparing goes through the list of features that excites you and think about why what is this feature due to benefit me my department or my company as a whole it's often helpful to use familiar concepts to explain new concepts I been using billboard analogy today but it can be a simple as comparing us lowering Service to major highways such as I 3 5 out there 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 so you're going to have to show that the benefits outweigh the costs so you can ask yourself in what ways does the same as money and in what ways to that 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 a different perspective and it will help you see from their point of view and further their understanding don't focus on your audience don't don't focus on trying to make your audience understand at the level that you do they usually only concerned with the high-level big picture and it can be hard to find a balance of between making sure that your audience has enough information and over sharing so don't get caught up in the mind you details of avoid using jargon that has no meaning to your audience we love are acronyms and we have a lot of phrases and jargon that have no meaning to other people and then even each different technical sector has all their own jargon so you have to do your best to use terminology the required little or no explanation because having to explain even the words you're using makes a really hard to hold everyone's attention it can be easy to bring content that really is a relevant so try to make cook try to keep a clear path we explain something technical it's very easy to begin talking about something and then realize that you really can explain this 1 OPEC just drop it and move on and that just causes confusion you need to decide ahead of time what is essential never said in a high my position and water knowledge over someone the quickest way to distracted listener down is to talk down to them and sometimes people just don't get what you trying to say it happens it's you to be passionate about something and excitedly explain it to someone who just doesn't get what you're saying but you don't wanna get flustered so what this steps the when Alice should be able to have an easier time navigating meetings with the pointy haired boss but let's face it it's still going to be a minefield so hopefully you have an easier go but to recap we discuss why we need DevOps and we've gone over a high-level overview worship and Dev Ops means are how it meets that need and talked about some principles on explaining any technical topic to non-technical people so I hope everyone learn something are there any questions that I can answer