Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Generalists and Specialists: Divergent Patterns for DevOps

148 views

Published on

In IT, we sometimes coin terms for things before we know exactly what they are and how they’ll be used. The resulting terms may capture a common set of aspirations and goals—as “cloud” did broadly for on-demand, self-service, and flexible computing. But such a term can also lump together diverse and even competing practices, technologies, and priorities to the point where important distinctions are glossed over and lost.
This is the case with DevOps. On the one hand, many DevOps discussions focus on culture, breaking down silos, making everyone responsible for security, and giving developers operational responsibility for their applications. This is primarily a developer-centric view of DevOps. On the other hand, DevOps (or cloud-native operations if you prefer) can also be approached through the lens of how operations enables developers and relentlessly automates using expert teams--while also managing business risk.
In this session, Red Hat Technology Evangelist Gordon Haff will discuss different patterns for creating next-generation software and provide insight into when particular approaches may be more or less suitable. You’ll leave with a better understanding of optimizing the software delivery pipeline in your organization.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Generalists and Specialists: Divergent Patterns for DevOps

  1. 1. GENERALISTS AND SPECIALISTS: DIVERGENT PATTERNS FOR DEVOPS GORDON HAFF Technology Evangelist, Red Hat @ghaff
  2. 2. THE GENERALIST TEAM
  3. 3. IN THE BEGINNING Source: Cisco
  4. 4. Source: http://www.agilebuddha.com/agile/demystifying-devops/ WIDENING AGILE PRINCIPLES TO CROSS- FUNCTIONAL TEAM
  5. 5. Source: Michael Coté, flickr/CC https://www.flickr.com/photos/cote/5559360372 “TWO PIZZA” TEAMS ● Autonomous ● Cross-functional ● Responsible for a well-defined function/service ● Developing and running
  6. 6. CONWAY’S LAW Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
  7. 7. ONE OPPOSING VIEW "I want to change my job because there is this horrible concept of "pager duty" or "oncall". Where the developer has to be ready for any issues that may occur. Are most software jobs like this? Is this a norm? Where can I find software development positions without such concepts?" Anonymous Quora user
  8. 8. WE ALSO TALK ABOUT CULTURE A LOT ● Empathy ● Trust ● Learning ● Cooperation ● Responsibility
  9. 9. SEPARATING CONCERNS
  10. 10. NO OPS? (OR IS IT EVOLVED DEVOPS?) "We have built tooling that removes many of the operations tasks completely from the developer, and which makes the remaining tasks quick and self service. " Adrian Cockroft, Netflix, 2012
  11. 11. You do not, in fact, want to communicate with a bank teller more efficiently Source: Flickr/cc Ning Ham https://www.flickr.com/photos/ningham/525770546
  12. 12. 12 THE PROCESS Still involves people and communication • The most effective processes have continuous communication - think scrums and kanban • Allows for collaboration that can identify failures before they happen • Allows for feedback to continuously improve and cultivate growth • Provides transparency
  13. 13. SEPARATING CONCERNS: WHAT DEVELOPERS NEED
  14. 14. FOCUS ON IMPROVED APP ARCHITECTURES & DEVELOPER WORKFLOWS ● Cloud-native app development ● Collaboration ● CI/CD ● Issue tracking ● Source code control ● Code review ● IDE ● xPaaS Source: Esti Alvarez cc license
  15. 15. 15 MICROSERVICES
  16. 16. 16 MICROSERVICES ARE NOT SOA. REALLY! Source: PWC Lighter-weight communications protocols Improved understanding of functional separation More open source and vendor-neutral philosophies Scale-out infrastructure standardization and automation
  17. 17. 17 SIGNS YOU MIGHT NEED MICROSERVICES Source: Daniel Pratts CC/flickr https://flic.kr/p/7RE6yc ● Having trouble coordinating function teams like DBAs and UI engineers ● Brittle apps. Minor changes cause major breakage ● Your CICD process is bogged down by big deployments ● Different teams keep reinventing the wheel (in gratuitously different ways) ● Hard to experiment
  18. 18. 18 DESIRABLE ENTERPRISE CI/CD WORKFLOW myRepo Project Repo CI Commit Push Pass/Fail Local Test Build Repo CD Release Repo Monitor Build Test Review/ Appr Deliver Deploy 3rd Party
  19. 19. 19 CONTINUOUS BORING DEPLOYMENTS ● Software (trunk) is always deployable ● Everyone is checking into trunk daily (at least), not feature branches ● If the build breaks it is fixed in 10 minutes (all hands on deck) ● Deployment is a low-risk push button affair ● Blue/Green and Canary deployments
  20. 20. SEPARATING CONCERNS: WHAT OPS NEEDS
  21. 21. FOCUS ON PROVIDING CORE SERVICES AND GETTING OUT OF THE WAY ● Deploy a modern scalable container platform ● Enable automated developer workflows ● Mitigate risk and automate security
  22. 22. COMPREHENSIVE CLOUD-NATIVE INFRASTRUCTURE
  23. 23. OPERATED AT SCALE ACROSS HYBRID CLOUDS ● Different aspects of scale: ○ Large scale workloads ○ Diverse workloads (batch and services) ○ Complex resource management (QoS, latency sensitivity, etc.) ● Focus on lightweight containerized instances ● Orchestration and resource management
  24. 24. 24 THE RIGHT WORKFLOW Repeatably automate for consistency ● Goal is repeatable automation ● Configuration as code ● Monitoring and alerting strategy ● Initially pipelines may be very different for traditional vs. cloud-native ● It’s a journey that evolves
  25. 25. 25 LOGGING WITH EFK STACK ● ElasticSearch, Fluentd, Kibana ● Based on log aggregation ● Event system - all events container, system, kubernetes, captured by EFK and issues or errors ● Good for ad hoc analytics ● Good for post mortem forensics because of extensive log information
  26. 26. 26 MONITOR AND MEASURE AGAINST METRICS Metrics tools tend to make more use of APIs than logs. You need to figure out your organizational needs. Hawkular is ideal for large scale central IT teams with lots of apps Prometheus is ideal for WebScale DevSecOps
  27. 27. MANA Reuse AutomationMicroservices Immutability Pervasive access Speed Rapid tech churn Flexible deploys Containers Software-defined MANAGED RISK Dev Ops
  28. 28. INTEGRATE SECURITY "Our goal as information security architects must be to automatically incorporate security controls without manual configuration throughout this cycle in a way that is as transparent as possible to DevOps teams and doesn't impede DevOps agility, but fulfills our legal and regulatory compliance requirements as well as manages risk. " DevSecOps: How to Seamlessly Integrate Security Into DevOps Gartner. DevSecOps: How to Seamlessly Integrate Security Into DevOps. September 2016. G00315283
  29. 29. MAKING CONTAINERS SECURE AND TRUSTED ISOLATION OF HOSTS ARE SOURCES TRUSTED? WHAT’S INSIDE CONTAINERS TRUST IS TEMPORAL Host OS + SELinux maintained by trusted kernel engineers and frequently updated. A validated supply chain helps ensure use of tested and patched software. Red Hat + Black Duck = secure, trusted model for validating container contents. New vulnerabilities are identified daily and containers become stale over time.
  30. 30. TRACK AND VALIDATE THIRD-PARTY TOOLS AND COMPONENTS
  31. 31. GETTING STARTED
  32. 32. QUESTIONS TO ASK ● What’s the business problem? ● Where am I today? ● How big are my teams? ● What skills do I have (or can hire)? ● On-premise and/or public clouds?
  33. 33. THANK YOU plus.google.com/+RedHat linkedin.com/company/red-hat youtube.com/user/RedHatVideos facebook.com/redhatinc twitter.com/RedHatNews

×