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?
   

   View Slide

2. A perspective from Devopsdays Portland 2019
   https://www.darkcoding.net/software/a-developer-goes-to-a-devops-conference/
   

   View Slide

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
   

   View Slide

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
   

   View Slide

5. 01
   Measuring
   software delivery
   performance
   

   View Slide

6. 2019 State of DevOps Report: cloud.google.com/devops
   

   View Slide

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
   

   View Slide

8. 2019 State of DevOps Report: cloud.google.com/devops
   

   View Slide

9. View Slide

10. State of DevOps Report: cloud.google.com/devops
    Continuous delivery
    

    View Slide

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
    

    View Slide

12. 02
    Enterprise cloud
    native platforms
    

    View Slide

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
    

    View Slide

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
    

    View Slide

15. View Slide

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?”
    

    View Slide

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.
    

    View Slide

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/
    

    View Slide

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
    

    View Slide

20. Compliance
    
    https://18f.gsa.gov/2017/02/02/cloud-gov-is-now-fedramp-authorized/
    

    View Slide

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
    

    View Slide

22. 03
    Apps
    
    

    View Slide

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?
    

    View Slide

24. JAM stack
    JavaScript
    APIs
    Markup
    

    View Slide

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
    

    View Slide

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
    

    View Slide

27. building security in
    http://bit.ly/2018-devops-report | https://devops-research.com/research.html
    

    View Slide

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
    

    View Slide