Successfully reported this slideshow.
Your SlideShare is downloading. ×

DevOps for Humans

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 49 Ad

More Related Content

Recently uploaded (20)

Advertisement

DevOps for Humans

  1. 1. DevOps for Humans Stefano Picozzi spicozzi@redhat.com https://StefanoPicozzi.blog
  2. 2. Agenda 2 DevOps at the Behaviour and Technology Intersection 1. Start with Why 2. Rediscover your Mojo 3. Go to the Dojo
  3. 3. Burrhus Frederic Skinner Frederick Irving Herzberg Millard Fuller Daniel Pink David Rock Aristotle Simon Sinek Jim Whitehurst Mike Meyers Gene Kim Ivar Jacobson Paul Keating Bruce Tuckman … Featuring
  4. 4. Start with Why
  5. 5. THE OPEN ORGANIZATION JIM WHITEHURST, RED HAT CEO CONVENTIONAL ORGANIZATION “TOP DOWN” OPEN ORGANIZATION “BOTTOM UP” WHAT HOW WHY WHAT HOW WHY SETTING DIRECTION GETTING THINGS DONE MOTIVATING AND INSPIRING COMMAND AND CONTROL CENTRAL PLANNING TITLE AND RANK HIERARCHY PROMOTION AND PAY CATALYZING INCLUSIVE DECISION-MAKING MERITOCRAC Y LET THE SPARKS FLY PURPOSE AND PASSION ENGAGEMENT
  6. 6. Open unlocks the world’s potential 6
  7. 7. OPEN SOURCE IS MORE THAN CODE. IT’S CULTURE. OPEN SOURCE CULTURE Engaged communities more rapidly adapt change Transparency forces honesty and authenticity Open standards preserve business agility Shared problems are solved faster Walk fast, walk alone. Walk far, walk together.
  8. 8. Risk averse Managing upwards Gold plated requirements Long phases Succeed slowly Consulting deliverables Detailed documentation Command and control Time bounded project Compliance Control High-touch Waterfall Reward centric Managing outwards Practical experimentation Short sprints Fail fast Collaborative learning Working software Self organizing teams Long lived product Adherence Autonomy Self-service Agile Mind Reset
  9. 9. It is easier to act yourself into a new way of thinking, than it is to think yourself into a new way of acting - Millard Fuller
  10. 10. 1. Concerned with value delivery 2. Professional empathy formed via shared sensibilities 3. Automation as actionable intervention DevOps – The Talent Dividend
  11. 11. The Hard Problems In Software Delivery operatedeployreleasetestbuildcodeplanwhy Adapted from: http://www.continuousautomation.com/wp-content/uploads/2014/08/solution-s-curve.png Lean DevOps Continuous Delivery Continuous Integration Agile Development Collaboration Value Existential Value Delivery
  12. 12. Rediscover your Mojo
  13. 13. Topics PEOPLE PROCESS TECHNOLOGY DEVOPS SEMAT MATURITY MODEL SCARF MOTIVATION CONTAINERS AUTOMATION
  14. 14. W W S D Technology
  15. 15. Nudge. Make the desirable choice easier. Reward adherence. The ABCs of DevOps Teaming Feedback Experimentation Standardization Automation Self-Service Increased velocity Improved quality Reduced waste A B C Negative Positive Reinforcement
  16. 16. VIRTUAL MACHINES AND CONTAINERS Container Host Container Application OS dependencies Dev IT Ops Infrastructure Virtual Machine Application OS dependencies Operating System IT Ops (and Dev, sort of) Infrastructure Clear ownership boundary between Dev and IT Ops drives DevOps adoption and fosters agility Optimized for stability Optimized for agility
  17. 17. Automation Technology Landscape Automation Centricity Infrastructure Application LowHigh Infrastructure as code Containers as code Container primitives Enterprise Management Operational Convenience Opportunistic Productivity Operational Efficiency Organizational Innovation Where should infrastructure automation end and application automation begin? Whatistherightlevelofabstraction? Separation of Concerns Projects Namespaces Registry, ImageStreams Multitenancy plugin SDN Quotas Roles Playbooks ... Self-Service for All Source to Image Templates Storage Classes Console, CLI, REST Pipelines A/B, Canary, Software Catalog Log aggregation ...
  18. 18. Herzberg's OpenShift SERVICE CATALOG LANGUAGE RUNTIMES, MIDDLEWARE, DATABASES .. SELF-SERVICE APPLICATION LIFECYCLE MANAGEMENT (CI / CD) BUILD AUTOMATION DEPLOYMENT AUTOMATION CONTAINER NETWORKING SECURITYSTORAGE REGISTRY LOGS & METRICS CONTAINER ORCHESTRATION & CLUSTER MANAGEMENT (KUBERNETES) RED HAT ENTERPRISE LINUX CONTAINER RUNTIME & PACKAGING (DOCKER) ATOMIC HOST INFRASTRUCTURE AUTOMATION & COCKPIT CONTAINER CONTAINER Motivators Hygiene Factors
  19. 19. "Software is eating the world" Marc Andreesen, August 20, 2011 Virtual machines are eating bare metal Containers are eating virtual machines Kubernetes is eating containers Kubernetes (Istio) will eat microservices Kubernetes (PSA-P) will eat AI/ML Red Hat's OpenShift is eating Kubernetes 
  20. 20. People Self Interest
  21. 21. Motivation 3.0 AUTONOMY PURPOSE MASTERY The urge to get better at something that matters. The desire to do something that has meaning and is important. To be self-directed. Control increases compliance but autonomy increases engagement.
  22. 22. We Are All on a Spectrum 10x Programmer Citizen Developer Opinionated frameworks Not invented here Vendor babble ☺ Fast > Right 80/20 Simplicity Self service Bureaucracy Corporate IT Steering Committees Enterprise Architect Consistency Evaluations Governance Snowflakes Rogue Behaviour Exceptions 1x Programmer Aging Hipster Roll your own Autonomy Edge cases
  23. 23. Motivation 3.0 for DevOps AUTONOMY PURPOSE MASTERY Self-service Automation Service catalogs Immediacy Frictionless Choice Roles based access Enable, get out of the way Accessibility From Novice to Expert Multiple form factors Scale invariance Tooling range Training and enablement Open Innovation Labs Community engagement Collaboration CI/CD integration Image provenance Stateful applications Security and scalability Logging Telemetry Middleware …
  24. 24. The SCARF Model for Collaboration Away Toward Threat Reward Status Certainty Autonomy Relatedness Fairness Perception of control over environment. A sense of choice dramatically reduces stress. Deciding whether others are ‘in’ or ‘out’ of a social group. Empathy response is more active within the tribe or with friends. Brain is a pattern matching machine. More resources are expended processing novel situations. Significant determinant of health and longevity. Challenge to status can generate strong threat response. Equitable outcomes. Sense of unfairness triggers strong threat response.
  25. 25. SCARF on DevOps Away Toward Threat Reward Status Certainty Autonomy Relatedness Fairness Small, long-lived, cross-skilled team Embed Developers into Operations Embed Operators into Development A success exemplar Shared decision making Skills transfer to new model Relevancy via enablement Equity in remuneration KPIs and MBO alignment Career growth outside management Measurement time horizons Executive sponsorship Leadership authenticity Reinforcement of behaviours Role transition clarity
  26. 26. Process
  27. 27. Imagine if you could easily assess the state of an organization’s software development project? 27
  28. 28. Software Engineering Method and Theory
  29. 29. TheKernel SEMAT SoftwareEngineeringMethodandTheory
  30. 30. Programs of work be they sprints, workshops, healthcheck change state. The current state is assessed, target end state agreed to, and then appropriate intervention is designed and applied. Events such as Discovery Workshops advance Reqs and Software System. Red Hat's Open Innovation Lab program advances Team, Way of Working and more.
  31. 31. DevOps Maturity Model
  32. 32. DevOps Maturity Model 1 (Initial) 2 3 (Improved) 4 5 (Optimizing) Culture & Organization Teams organised based on platform/technology. Defined and documented processes. Low cooperation or power- oriented. ⬤ Agile Adoption One backlog per team. Adopt agile methodologies. Remove team boundaries. Share the pain. Modest cooperation or rule-oriented. Scaled Agile Approach (SAFe or other) Extended team collaboration. Remove boundary dev/ops. Common process for all changes. Cross-team continuous improvement. Teams responsible all the way to production. Cross functional teams. High cooperation or performance- oriented. Test & Verification Automated unit tests on every build. Separate test environment. ⬤ Some automatic integration tests. Code analysis. Test coverage analysis. Automatic component tests. Full automatic integration tests. Behaviour-driven development. Full automatic acceptance tests. Manual exploratory testing. Automatic performance tests. Automatic security tests. Verify expected business value. Defects found and fixed immediately (roll forward). Information & Reporting Baseline process metrics. Manual reporting. ⬤ Measure the process. Static code analysis. Automatic reporting. Automatic generation of release notes. Pipeline traceability. Reporting history. Report trend analysis. Real time graphs on deployment pipeline metrics. Dynamic self-service of information. Customizable dashboards. Build & Deploy Centralized version control. Automated scripts for building software. Nightly builds. No management of artifacts. Manual deployment. ⬤ Continuous Integration Polling or triggered builds (commit hook). Fail builds if they do not compile and pass unit tests. Any build can be re-created from source control. Management of build artifacts. Builds are not left broken. Deployment Pipelines Fail builds if more general quality is not met. Automated provisioning of environments. Automated deployments. Standardized environment templates. Standard deployment process for all environments. Team prioritises keeping codebase deployable over doing new work. Orchestrated deployments. Blue/green deployments. Zero touch continuous deployments. Data Management Data migrations unversioned and performed manually. ⬤ Automated and versioned changes to datastores. Changes to datastores automatically performed as part of the deployment process. Automatic datastore changes and rollbacks tested with every deployment. Release Infrequent and unreliable releases. ⬤ Painful infrequent but reliable releases. ⬤ Infrequent but fully automated and reliable releases in any environment. Frequent fully automated releases. Deployment disconnected from release. No rollbacks, always roll forward. Team is roughly at this stage already and is not targeting this area for next phase. Team is targeting these activities as critical for next phase. Team is targeting these activities as potential work for next phase. Cells without status indicate stages the team has not achieved fully and are not being focused on for the next phase.
  33. 33. Go to the Dojo
  34. 34. OPEN INNOVATION LABS OPEN SOURCING OUR DNA TO ACCELERATE APPLICATION DEVELOPMENT MISSION VISION To accelerate the delivery of our customer’s innovative ideas, and create infectious enthusiasm for building applications the Red Hat Way, by leveraging community-powered innovation to deliver an outstanding labs experience. To empower our customers to deliver the most innovative software success stories of the 21st century.
  35. 35. 37 BUILD SOFTWARE THE RED HAT WAY IN OPEN INNOVATION LABS EXPERIMENT Rapidly build prototypes, do DevOps, and be agile. IMMERSE YOUR TEAM Work side-by-side with experts in a residency-style engagement. CATALYZE INNOVATION Bring modern application development back to your team.
  36. 36. OUR PROCESS PRE-WORK "RESIDENCY" RETROSPECTIVE Discovery session Agile, Lean, DevOps Backlog and roadmap PUSH-BUTTON INFRASTRUCTURE DEMO DAY CONTINUOUS LEARNING
  37. 37. Story Slicing Priority Sliders Screen Flow Event Storming DOMAIN-DRIVEN DESIGN OUR METHODS
  38. 38. PUSH BUTTON CONTAINER DEPLOYMENT PIPELINE
  39. 39. 41 DISRUPTION RAPIDLY CO-CREATE AN INNOVATIVE OR DISRUPTIVE PRODUCT
  40. 40. 42 TRANSFORMATION CREATE THE CATALYST TO CHANGE THE CARGO SHIP’S COURSE
  41. 41. 43 THE ROAD TRIP EXPERIENCE STATE-OF-THE-ART APPLICATION DEVELOPMENT AND DEVOPS
  42. 42. CONFIDENTIAL - FOR INTERNAL USE ONLY DISCOVERY SESSION AGENDA RESULTS In a 1-day no cost session, the client and Red Hatter work together to scope Labs and make Red Hat sticky. • Understand business priorities and IT landscape • Identify future state objectives • Define value hypothesis • Define minimum viable product to build in Lab • Well-documented consulting proposal + SOW • Clear understanding of objectives • Established credibility and thought leadership INTERAT E ENABLE 44 CREATING THE SPACE TO INNOVATE “By creating a shared space for testing and developing new open source solutions, I hope that [the Innovation Lab] will spur a culture of innovation within state government and lead the nation in using technology to bring the government closer to the people.” Lt. Gov. Gavin Newsom, 2016 RAYMOND YEE School of Athens https://www.flickr.com/search/?license=4%2C5%2C6%2C9%2C10&ad- vanced=1&text=the%20school%20of%20athens Original image: https://en.wikipedia.org/wiki/File:Sanzio_01.jpg
  43. 43. 45 TAKING A NEW APPROACH TRADITIONAL I.T. VERSUS OPEN INNOVATION TRADITIONAL OPEN INNOVATION LABS Maybe Probably not Slow Months to years Very high Team of teams DANGER Yes, infectiously Definitely Fast 1-3 months None Small team Low CULTURE OF INNOVATION AGILITY SPEED TO VALUE DEV LIFE CYCLE INFRASTRUCTURE COST PEOPLE NEEDED RISK
  44. 44. 46
  45. 45. Insights and Summary Culture as an advantage is defensible. All others are transient or can be neutralised. Technology intervention as nudge towards desirable behaviours. Behaviour in the aggregate then forms patterns observed as culture. Start with small empowered team with Executive blessing. Success becomes exemplar that triggers viral enablement.
  46. 46. DO TRY THIS AT HOME https://www.openshift.org/minishift/ https://www.openshift.com/promotions/for-developers.html https://www.openshift.com/promotions/devops-with-openshift.html https://www.openshift.com/promotions/kubernetes.html https://www.openshift.com/promotions/docker-security.html https://stefanopicozzi.blog/2016/06/21/openshift/
  47. 47. The Beginning Stefano Picozzi spicozzi@redhat.com https://StefanoPicozzi.blog

×