DevOps
- 1. DevOps What is it? Do we want it all? How are we doing?
- 2. What is DevOps? (according to Wikipedia) • software DEVelopment and information technology OPerationS • “A set practices that emphasize the collaboration and communication of both software developers and information technology professionals while automating the process of software delivery and infrastructure changes” • “Establishing a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably” • Generally agreed to have started around 2008-2009 (devopsdays.org)
- 3. What is DevOps? (my personal definition) • The art and science of identifying and automating the routine parts of managing information, software, and technology for rapid, reliable deployment • A framework/toolset that helps technologists focus on the interesting parts of our work and lets non-technologists focus on their core jobs • By this metric, DevOps in some form has been around as long as there has been systems administration • “Fighting fires” is not interesting in a good way • Unplanned incidents consume resources uncontrollably (wildfire) • Planned, proactive fire management is better • Forestry to manage the forest, plus understanding how fires could start and when controlled burns are needed, is best
- 4. What motivated me to think about DevOps? • The Phoenix Project: a novel about IT, DevOps, and helping your business win by Gene Kim, Kevin Behr, George Spafford (http://itrevolution.com/books/phoenix-project-devops-book/ ) • Our protagonist inherits an IT infrastructure which is badly broken • Catastrophe -> heroic recovery -> maybe learning (repeat) • Incremental improvements to understanding, infrastructure • Ticketing system to make work visible (with actual tickets: KanBan!) • Identify and ameliorate bottlenecks (Brent) • Prioritize IT work by understanding business needs, IT infrastructure • Develop knowledge of and skill in workplace politics
- 5. Real life DevOps example: npm • https://speakerdeck.com/ceejbot/devops-at-npm-scaling-the-registry • CJ Silverio, CTO at npm, describes how they scaled up infrastructure to create a usable global Node.js registry • Moved from best guess predictive scaling to reactive monitoring and scaling to proactive improvements based on reliable metrics • Infrastructure was exciting for several months while trying to meet increasing demand • Sometimes learned what needs to be monitored by having it break • “The goal is to be boring”
- 6. Real life DevOps example: Etsy • https://codeascraft.com/2012/05/22/blameless-postmortems/ • John Allspaw, CTO at Etsy, writes about their culture where failure is expected and used to learn how to make improvements • Human error is inevitable • Equip ourselves to better deal with problems that may arise • Give people the authority to make things better • Just Culture requires understanding personal reactions to failure
- 7. Does Arts need DevOps? (audience participation time) • Why are we here? • Do we develop technology solutions to help Arts work effectively? • Are we solely/primarily a support organization? • Should we be? • Should central IT be where DevOps happens? • How effectively do we work across units?
- 8. What DevOps Isn’t (busting a few myths, 1/n) • A replacement for Agile • The Agile Manifesto http://agilemanifesto.org/principles.html (created in 2001) is about building and maintaining software responsively • In a sense, DevOps is an extension of work flow practices used in Agile/Extreme/Lean/Scrum methods to technology management • Agile is not a prerequisite for DevOps • Flexible IT service delivery can support Agile software development • Our job isn’t over when code is fully tested and in production • Do we use Agile/Lean software development or project management?
- 9. What DevOps Isn’t (2/n) • A replacement for ITIL • ITIL is a set of best practices • ITIL and ITSM describe capabilities needed to support DevOps • Service design is relevant • Problem management is relevant to DevOps, too • Many processes codified in ITIL can be automated • This includes change, configuration, release processes • As with Agile, DevOps can enable ITIL implementation • Do we use ITIL? Has this changed in the past year?
- 10. What DevOps Isn’t (3/n) • NoOps (entirely eliminating IT Operations) • Many IT operations tasks become self service under DevOps • Pushes some operations functionality to groups that don’t have an operations focus, e.g. development • Operations still has responsibility to maintain and develop the environment that makes everyone’s job less frustrating • Are there areas of our work where we use NoOps? Do we consume any NoOps services? Would we like to?
- 11. What DevOps Isn’t (4/n) • Linked primarily to Open Source • Principles are universal • You don’t need a LAMP stack: independent of underlying technology • Some DevOps requirements are common in Open Source environments • automated testing • configuration management • version control • How much of our work relies on vendor solutions? Open source? Home grown software?
- 12. What DevOps Isn’t (5/n) • Infrastructure as code (nothing but automation) • Many patterns require automation • We also need mutual trust, shared goals • Understanding how technology enables the business and how people (technologists and non-techs) get things done • The business of higher education has a lot of moving parts • How much of our work involves knowing academic, administrative work flows?
- 13. What DevOps Isn’t (6/6) • For tech startups and behemoths/unicorns • Google, Amazon, Twitter, LinkedIn, Esty, Facebook started with traditional IT Operations practices • DevOps practices are widespread across industries • Financial services (Bank of America, Paychex, World Bank) • Retailers (REI, Macy’s, GameStop) • Higher education (UBC, Kansas State) • US and UK government agencies • Does DevOps make sense for Arts Computing? For UW?
- 14. What DevOps is: core concepts The three ways The four types of work Monitoring and visibility
- 15. The three ways of DevOps (looks a lot like Toyota Production System) Left to right flow of work Right to left flow of information Creating a culture where errors and feedback are normal
- 16. Left to right flow of work • Work in progress always moves forward • Development -> IT Operations -> end user • Small batch sizes and intervals • Do not pass defects downstream • Constantly optimize for global goals • Continuous build, integration, deployment • Create environments on demand • Limit work in process • Build safe systems • Build infrastructure that is resilient to change in requirements, environment, demand
- 17. Right to left flow of information • Constant, fast feedback at all stages • Amplify information • Identify exceptions • Speed up exception detection and recovery • Prevent problems from recurring • Stop everything when something goes wrong • Improvement of work takes precedence over the work itself • Fast, automated testing • Shared goals among business, development, operations • Pervasive, visible production telemetry
- 18. Creating a resilient culture • Foster continual experimentation • Reward taking risks • Learn from both failure and success • Improve relentlessly • Innovation demands a high level of trust • Understand: repetition and practice are needed for mastery • Develop reliable skills and habits • How can we help each other be comfortable taking risks?
- 19. The four types of work that IT does • Business projects (why we get paid) • The work of the organization, often software development/projects • This includes some client support of various kinds as well • IT projects (how we make it easier to do what we get paid for) • Infrastructure creation/maintenance • Internally generated improvement work • Changes (planned updates because we don’t exist in a bubble) • Feature development, service delivery, patches • Unplanned work (forest fires) • Incidents, problems
- 20. Why track (and visualize) these types of work? • Evaluate our performance • Identify bottlenecks • Identify priorities • Plan use of resources • Avoid resource starvation • People are resources too • http://images.itrevolution.com/images/kanbans/waittime_vs_percentbusy.jpg
- 21. How are we doing? • Following the three ways (workflow, flow of feedback, flow of trust) • How much of each of four types of work we do (Arts, IT, change, fires) • Can we measure this more effectively? • Identifying and fixing bottlenecks • Automating what we can • Figuring out what can be automated • Understanding the business that makes our work necessary • Tell me about the Faculty of Arts; how does it work?
- 22. Where do we go from here? (homework) • Automate something you do by hand • Help a client automate something • Look at what you see in monitoring results • Fix it so it’s actionable or response is automated • Find out what your supported departments and programs are doing/planning and how we can help them • Prepare to take a two week vacation without checking email • Check in with team on your progress in 2-6 months (set deadline)