$30 off During Our Annual Pro Sale. View Details »

Is DevOps still relevant in a cloud native worl...

Jez Humble
November 07, 2019

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.

Jez Humble

November 07, 2019
Tweet

More Decks by Jez Humble

Other Decks in Technology

Transcript

  1. DevOps movement a cross-functional community of practice dedicated to the

    study of building, evolving and operating rapidly changing, secure, resilient systems at scale
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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?”
  8. 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.
  9. 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/
  10. 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
  11. 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
  12. 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?
  13. 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
  14. 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
  15. 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