Is DevOps still relevant in a cloud native world (enterprise edition)?

With the increasing trend towards abstracting away infrastructure into platforms, has DevOps become obsolete? Jez thinks not, and in this talk he’ll take an evidence-based approach to the design and implementation of compute platforms and the applications that live in them, based on DevOps principles and practices. He'll also discuss how security changes in the cloud-native paradigm, and effective organizational structures and processes for managing a diverse portfolio of applications.

Transcript

1. @jezhumble #oredev2019 7 November 2019 Is DevOps Still Relevant in a Cloud Native World?
2. A perspective from Devopsdays Portland 2019 https://www.darkcoding.net/software/a-developer-goes-to-a-devops-conference/
3. DevOps movement a cross-functional community of practice dedicated to the study of building, evolving and operating rapidly changing, secure, resilient systems at scale
4. DevOps An organizational and cultural movement that aims to increase software delivery velocity, improve service reliability, and build shared ownership among software stakeholders. cloud.google.com/devops
5. 01 Measuring software delivery performance
6. 2019 State of DevOps Report: cloud.google.com/devops
7. Software delivery as a competitive advantage Elite performers are twice as likely to meet or exceed their organizational performance goals: • Profitability • Productivity • Market share • Number of customers • Quality of products or services • Operating efficiency • Customer satisfaction • Quantity of products or services provided • Achieving organizational and mission goals 2019 State of DevOps Report: cloud.google.com/devops
8. 2019 State of DevOps Report: cloud.google.com/devops
10. State of DevOps Report: cloud.google.com/devops Continuous delivery
11. Cloud is a differentiator Elite performers were 24 times more likely to have met all essential cloud characteristics than low performers*. But only 29% of respondents met all five! 2019 State of DevOps Report: cloud.google.com/devops *Five essential characteristics of cloud computing defined by NIST in Special Publication 800-145 On-demand self-service Broad network access Resource pooling 1 2 3 Rapid elasticity 4 5 Measured service
12. 02 Enterprise cloud native platforms
13. Enterprise Edition • Hundreds / thousands of services • Heterogeneous technology • 70%+ of IT budget is keeping lights on & adding capacity* • Now we’re supposed to support CI/CD Photo: Joshua Heller https://www.flickr.com/photos/joshuaheller/4452150826 CC BY 2.0 * https://www.forrester.com/go?objectid=RES115762
14. Operations “Another flaw in the human character is that everybody wants to build and nobody wants to do maintenance.” — Kurt Vonnegut, Hocus Pocus Photo: By WNET-TV/ PBS - eBayfrontback, Public Domain, https:// commons.wikimedia.org/w/index.php?curid=38530410
16. Designing an enterprise PaaS 01 Garbage collection “Whom should I be billing for this virtual load balancer / db instance?” “What would happen if I deleted this service? Is anybody even using it?” 02 Making changes “This application has a vulnerability: How would I fix and redeploy it?” “I need to update this dependent service: where is the source code? Does anyone who built it still work here?” 04 Managing complexity “How do we make sure we can hire people who know how to work on this?” “How can we make sure the application and stack are up-to-date?” 03 Multi-tenancy “How do we enable developers to self-service deployments or config changes without impacting other services on our platform?”
17. Lead time “How long would it take your organization to deploy a change that involves just one single line of code? Do you do this on a repeatable, reliable basis?” Mary and Tom Popppendieck, Implementing Lean Software Development: From Concept to Cash, p59.
18. Lead time and TTR in the enterprise When you discover a vulnerability in your stack, how long would it take you to find, patch and redeploy all impacted applications? https://arstechnica.com/information-technology/2017/09/massive- equifax-breach-caused-by-failure-to-patch-two-month-old-bug/
19. Key principle for Platform- as-a-service: Separation of Responsibilities 1. Platform team is responsible for the PaaS. 2. Make the application part as small as possible! 3. Self-service API for deployment. Ideally application stacks are part of the platform too (function-as-a-service model) so we can keep them patched easily. Photo: Uwe Kills License: CC-BY-SA https:// commons.wikimedia.org/wiki/File:Iceberg.jpg Apps Platform
20. Compliance https://18f.gsa.gov/2017/02/02/cloud-gov-is-now-fedramp-authorized/
21. Designing an enterprise PaaS 01 Garbage collection Platform should ensure that every virtual resource is assigned either to an app or the platform itself. 02 Making changes It should be possible to redeploy any app at the click of a button. 04 Managing complexity Limit options! For example, all apps must used predefined, approved runtime stacks that PaaS operators can patch and redeploy on demand 03 Multi-tenancy Essential requirement of any enterprise PaaS
22. 03 Apps
23. Architectural outcomes: can my team... 01 ...make large-scale changes to the design of its system without the permission of somebody outside the team, or depending on other teams? 03 ...deploy and release its product or service on demand, independently of other services the product or service depends upon? 04 ...do most of its testing on demand, without requiring an integrated test environment? 05 ...perform deployments during normal business hours with negligible downtime? 02 …complete its work without needing fine-grained communication and coordination with people outside the team?
24. JAM stack JavaScript APIs Markup
25. JAM stack advantages • Extremely cheap, highly scalable • Minimizes attack surface area • Separation of concerns between content and functionality • Super easy to configure and deploy • Decouples presentation and services, easier to develop / test
26. JAM stack disadvantages • You don’t get to put containers / kubernetes on your CV • You have to think about service boundaries and dependencies • You have to rely on your platform for canary / autoscale / cold start
27. building security in http://bit.ly/2018-devops-report | https://devops-research.com/research.html
28. You can’t just install kubernetes & start deploying apps! • Self-service multi-tenant PaaS that minimizes attack surface area • Architect for continuous delivery • Develop the necessary technical skills • Process change For more on cloud and devops, visit cloud.google.com/devops