Downloaded 305 times
Uploaded byRobert Sell
DevOps Introduction
The document provides an introduction to DevOps, emphasizing its importance in software development through improved collaboration and automation between developers and operations. It outlines the goals, definitions, and benefits of adopting a DevOps culture, while contrasting it with traditional software development methodologies. Key aspects include fostering cross-functional teams, embracing failure as a learning tool, and striving for continual improvement to enhance productivity and employee engagement.
More Related Content
DevOps Introduction
- 1.
- 2. Robert Sell IT OperationsManager AeroInfo – Boeing Canada @robertesell https://ca.linkedin.com/in/robertsell
- 3.
- 4.
- 5. DevOps Defined A softwaredevelopment method that emphasizes communication, collaboration, integration, automation and cooperation between developers and operations. This method acknowledges the interdependence of groups and aims to rapidly produce software products through improved operational performance.
- 6. Goals of DevOps Thegoals of a DevOps approach span the entire delivery pipeline and include: • Improved deployment frequency • Lower failure rate of new releases • Shorten lead time between fixes • Maximize predictability, efficiency, security (rugged) and maintainability
- 7. Other Definitions Many DevOpsleaders refer to DevOps as a “revolution or movement.” “DevOps is a culture or professional movement.” - Adam Jacob, CTO at Chef “DevOps is more like a philosophical movement.” - Gene Kim, Founder of TripWire, CTO, Author
- 8. CALMS Model Culture Changingthe way we think nd behave in the organization. Becoming one. Grassroots. Cooperation. Automation Configuration items. Infrastructure as Code. Lean A focus on value and customer. Reducing time spent on non-value activities. Metrics Measure everything all the time. Show improvement. Sharing Open sharing. Collaboration. Transparency.
- 9. My Definition I likethe definition in the DevOps Cookbook: We refer to “DevOps” as the outcome of applying Lean principles to the IT value stream. Understand the goal (customer), common and shared KPIs to support that goal, mapped work steams then improve. Allows repeatability, consistency and continual improvement.
- 10. Definition What DevOps isNOT: DevOps is not a product. You can not buy DevOps. DevOps is not a title or department. DevOps isn’t compliance. There is no DevOps certification. DevOps doesn’t just mean you mix Dev and Ops
- 11. Side Effects Now weknow what it is, what its goals are and what it is not. It’s side effects may include: • Higher employee engagement • Improved productivity • Competitive advantage (includes hiring) • Happier customers
- 12.
- 13. Stages Traditional Software DeliveryLife Cycle (SDLC) treat all stages equally and often spends too much time on risk mitigating activities that don’t create value. DevOps focuses on software creation and customer feedback while continually seeking to reduce investment in other stages.
- 14. Release Methods Traditional releasemethods are huge, costly, disruptive, complicated, time consuming, stressful, manual, rare and often don’t work well. DevOps release methods focus on small, cheap, easy, automated, instant, frequent and perfect.
- 15. Teams Traditional skill basedsilos benefit from economies of scale but don’t transfer work. “Thrown over the fence.” DevOps is a dedicated cross functional team focused on one service or application. No handoffs and misunderstandings. Responsibility and ownership for the larger picture.
- 16. Scheduling Traditional software developmentneeds to schedule resources across multiple projects. Ops and Dev hardly communicate let alone schedule. Last minute “urgent” requests are the norm. DevOps allows collaboration and local team scheduling. Small batches and automated process make this much easier.
- 17. Experience Traditional software releasesare terrible experiences full of issues, escalation and fire fighting. War rooms, pizza and all night fiascos. DevOps turns software releases into non-events. Code is through daily (or more) code integration, automated testing, built in security, and environment synchronization.
- 18. Failure Traditionally there isa huge focus on risk aversion. To fail is a bad thing and often results in blame. The fear of failure and blame cause delays and cost. DevOps are okay with failure. In fact, “fail early” is one of the mandates. Instead of investing in failure elimination, they choose when and how they will fail. Small, early and fast failure allow fast recovery and future prevention. Ie Chaos Monkey
- 19. KPIs Traditional measurements havebeen on uptime, cost and capacity. Unfortunately, organizations often ignore the fact that salary is a top cost and employee time is often spent on non-value work. DevOps looks at the element of time in the work flow as an additional metric. This forces us to examine the flow of work from start to finish. Decrease areas of waste, increase productive time and focus on value areas.
- 20. Responsibilities Traditionally we wereall responsible for completing our incoming tasks so we could hand off to the next team. DevOps changes the “I did my task” concept to “it is ready to deploy” with the introduction of cross functional teams.
- 21. Automation Traditionally there hasbeen a focus on manual task specialization. Unfortunately this often results in errors, bottlenecks and poor documentation. DevOps automates as much as possible. Time doing routinized behaviors is freed up for creative and innovative tasks. Instead of outdated documentation we do commenting. We never follow documentation to create an environment!
- 22.
- 23.
- 24. Google Trends Started in2010 and took off from there. 61 points in Jan 2015 and 100 in Sept 2015.
- 25.
- 26. IoT not asPopular “Internet of Things” isn’t even as popular as DevOps. 90 in Jan 2015 and 100 in Sept 2015
- 27.
- 28. Forecast “DevOps will shiftfrom being a niche approach to application development and deployment and move into the mainstream over the next 12 months or so.” – Gartner “So appealing will this grassroots philosophy prove that it will be taken up by a quarter of Global 2000 organizations” – Computer Weekly
- 29.
- 30. Stats For people wholike stats: • Traditional Ops are 41% more time-consuming overall • Traditional Ops spends 21% more time putting out fires • DevOps spends 33% more time on infrastructure improvements • DevOps spends 60% less time handling support cases After DevOps is implemented: • 63% experience improvement in quality of software deployments • 63% release new software more frequently • 55% notice improved cooperation and collaboration • 38% report a higher quality of code production https://www.scriptrock.com/blog/devops-success-stats
- 31.
- 32. Ops IT Operations grewup with BOFH (and enjoyed it) Our KPIs are for stability/uptime. Any change is a risk. Our role is to protect developers from themselves. Viewed by Dev as the Evil Empire
- 33. Dev Developers are creative,happy and care free. If an environment breaks they simply put in a ticket. Can’t understand why Ops makes such a big deal.
- 34. Ops vs Dev Poorrelease management, out of sync environments, different KPIs and cumbersome processes have caused many years of conflict.
- 35.
- 36. Traditional Let’s start withtraditional Operations & Development Chief Information Officer PMO/BAs Dev DBAs Test InfoSec Release Infra Support Head of Development Head of Operations
- 37. Grassroots DevOps begins withanyone. Grassroots. Chief Information Officer Head of Development Head of Operations PMO/BAs Dev DBAs Test InfoSec Release Infra Support Want to cooperate? Oh ya! Coffee?
- 38. Product Focus Sometimes ProductLeads are created. Challenging. Chief Information Officer Head of Development Head of Operations Product A Product B Product C Product D InfoSec Release Infra Support
- 39. Embedded Ops Ops embeddedinto Dev teams for DevOps. Chief Information Officer Head of Development Head of Operations Product A Product B Product C Product D InfoSec Release Infra Support Operations doing DevOps Want some DevOps?
- 40. Dedicated DevOps Sometimes dedicatedDevOps team are created. Chief Information Officer Head of Development Head of Operations Product A Product B Product C Product D InfoSec Release Infra Support DevOps
- 41. Total DevOps One possibleDevOps organizational structure: Chief Information Officer Management Product A Product B Product C Product D Product E Product F Product G Product H I’m focused on Product I’m practicing “Servant Management” I’m building leadership for scalability
- 42.
- 43. Cross Functional Create crossfunctional teams with representatives from each of the functional areas of the software delivery process. Map out the flow of work and look for efficiency opportunities. Reduce time for each step (especially non-value steps). Share the responsibility for building, deploying and maintaining product. Mix Build and Run teams.
- 44. Communications Develop effective communicationsthat promotes collaboration. Remove blame from Post Mortems and Project Reviews. Fail fast and expect it. Stop using email in attempt at collaboration. Treat failure as opportunities. Failure creators own, publish and teach solutions. Continual improvement.
- 45. Share Risk Collaboration allowserror checking and guidance. Same idea as ITIL CAB. Quality, availability, reliability, scalability and security is everyone’s responsibility. Traditional InfoSec does not work because it is after the fact and left to IT to enforce. Must be baked in. Devs responsible for Prod. No “throw over the wall.”
- 46. Align Goals Silos/Empires onlyexist when leaders are allowed to have different goals. Share goals and roll up. Cross functional teams ensure shared goals. Include Ops in planning throughout the software dev lifecycle.
- 47. Innovation We must demandinnovation otherwise it doesn’t occur. Continual improvement now applies to the individual. Training must now occur on a daily basis. Time must be allocated to on the job training and idea exploration. KPIs to measure it. Internal hack days, lunch & learns, mini conferences, awards for innovation, collaboration events, etc.
- 48.
- 49. The Revolution I ambias. I see DevOps as a revolution. Traditional organizations are very inefficient with layers of bureaucracy, silos, empires, red tape, politics and other non-value time wasters. DevOps forces us to not only fix Dev vs Ops but also fixes the PMO, Quality, Security and others.
- 50. Engagement DevOps is employeeengagement and is therefore scalable. Autonomous streams. DevOps corrects the culture. Share. Trust. Learn. Own. DevOps will revolutionize Operations (not just Dev). Infrastructure as Code is our next evolutionary step. Combined with monitoring and automation, it is scary cool.
- 51. Chang(ed) The world haschanged. Traditional disciplines are dead, some people just don’t know that yet.
- 52.
- 53. Sources YouTube (full ofgood videos) Start here: • Docker and DevOps by Gene Kim • DevOps Demystified by Ben Rockwood SlideShare http://www.slideshare.net Loads of good presentations
- 54. Training In the nameof the DevOps spirit, IT is sharing all our training: S:AeroInfoTraining Training materials include: GIT, Docker, etc. Join my local DevOps MeetUp: http://www.meetup.com/DevOps-Vancouver-BC-Canada
- 55. Twitter John Allspaw -@allspaw JesseRobbins - @jesserobbines Gene Kim - @realgenekim Patrick DuBuis - @patrickdubois Andrew Schafer - @littleidea Jez Humble - @jezhumble John Willis - @botchagalupe Damon Edwards - @damonedwards
- 56. BooksThe Phoenix Project: Thisbook by Gene Kim is used by everyone as the modern version of The Goal and is a good starting point for understanding DevOps and the problems it solves. If you don’t have it then talk to your manager and get the audio or written today via Safari, iTunes or Amazon
- 57. BooksContinuous Delivery: This bookby Jez Humble is used by Boeing and is the default starting point for understanding Continuous Delivery. If you don’t have it then talk to your manager and get the audio or written today via Safari, iTunes or Amazon
- 58. BooksThe Goal: This bookis used to better understand Operations Management and kaizen. It is normally part of an MBA program. If you don’t have it then talk to your manager and get the audio or written today via Safari, iTunes or Amazon
- 59. ReferencesReinventing Organizations: The waywe manage organizations seems increasingly out of date. This book was created after 3 years of research and is a key book in DevOps when looking at organizational change.