Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Architecting for Continuous Delivery

Jez Humble
November 09, 2017

Architecting for Continuous Delivery

DevOps and Continuous Delivery represent a new paradigm for IT service delivery that promises higher quality and stability as well as faster time-to-market. However deploying this new paradigm requires changes to both organizational culture and architecture. In this talk, Jez will present the architectural principles and patterns that enable continuous delivery at internet scale, and discuss how to incrementally evolve existing systems in order to deploy them.

Jez Humble

November 09, 2017
Tweet

More Decks by Jez Humble

Other Decks in Technology

Transcript

  1. @jezhumble | w-jax | 9 november 2017
    architecting for continuous delivery

    View Slide

  2. @jezhumble
    microservices

    View Slide

  3. @jezhumble
    part the first
    continuous delivery

    View Slide

  4. what is continuous delivery?
    The ability to get changes—features, configuration
    changes, bug fixes, experiments—into production or
    into the hands of users safely and quickly in a
    sustainable way.

    View Slide

  5. @jezhumble
    increase software quality and stability
    make releases painless, low risk events
    reduce time to market
    increase customer and employee satisfaction
    reduce cost of ongoing software development
    why continuous delivery?

    View Slide

  6. @jezhumble
    time to restore service
    lead time for changes
    release frequency
    change fail rate
    software delivery performance
    https://devops-research.com/research.html

    View Slide

  7. View Slide

  8. Jon Jenkins, “Velocity Culture, The Unmet Challenge in Ops” | http://bit.ly/1vJo1Ya

    View Slide

  9. why continuous delivery?
    https://arstechnica.com/information-technology/2017/09/massive-equifax-breach-caused-by-
    failure-to-patch-two-month-old-bug/

    View Slide

  10. @jezhumble
    configuration management
    continuous integration
    automated testing
    ingredients

    View Slide

  11. @jezhumble
    deployment pipeline

    View Slide

  12. continuous delivery SEM

    View Slide

  13. @jezhumble
    part the second
    architecture

    View Slide

  14. @jezhumble
    internet architecture
    “Operations at web scale is the
    ability to consistently create and
    deploy reliable software to an
    unreliable platform that scales
    horizontally.”
    Jesse Robbins, “Master of Disaster” @ Amazon| @jesserobbins | http://oreil.ly/1HRKUVE

    View Slide

  15. @jezhumble
    unreliable platform
    resilience, security, scalability,
    deployability, testability are
    architectural concerns

    View Slide

  16. @jezhumble
    make system easier to build and test
    part of your system that could be swapped out for another implementation
    make system more maintainable (better encapsulation, lower coupling)
    enable collaboration
    component / service

    View Slide

  17. @jezhumble
    bind components at run time (μS)
    “Transforming Software Development” | Ken Exner | http://bit.ly/1HxCEZy
    API versioning
    Independent deployment
    Don’t break downstream!
    Monitoring

    View Slide

  18. @jezhumble
    bind components at build time
    “Large Scale Continuous Testing in the Cloud” | John Penix | http://bit.ly/1BYMf70

    View Slide

  19. unit testing at google
    “Resistance to unit testing at Google was largely a matter of developers
    undereducated in unit testing struggling to write new code using old tools that
    were straining heavily under the load of Google's ever-growing operation.
    Adding tests to existing code appeared prohibitively difficult, and given the
    status quo, providing tests for new code appeared futile.”
    — Mike Bland
    https://martinfowler.com/articles/testing-culture.html

    View Slide

  20. @jezhumble
    deploy and release its product or service on demand, independently of other services the
    product or service depends upon?
    make large-scale changes to the design of its system without the permission of somebody
    outside the team or depending on other teams?
    complete its work without needing fine-grained communication and coordination with
    people outside the team?
    perform deployments during normal business hours with negligible downtime?
    do most of its testing on demand, without requiring an integrated test environment?
    architectural outcomes: can my team…

    View Slide

  21. testability
    “debugging problems with someone else's code gets a LOT harder, and is
    basically impossible unless there is a universal standard way to run every
    service in a debuggable sandbox.”
    — Steve Yegge
    Steve Yegge’s Platform Rant | https://bit.ly/yegge-platform-rant

    View Slide

  22. http://www.flickr.com/photos/trustedsource/6132507962/

    View Slide

  23. @jezhumble
    strangler application

    View Slide

  24. @jezhumble
    rules of strangler
    • start by delivering new functionality—at least at first
    • don’t rewrite existing functionality except to simplify
    • deliver something fast
    • design for testability and deployability
    • architect the new software to run on a paas

    View Slide

  25. Steve Yegge’s Platform Rant | https://bit.ly/yegge-platform-rant

    View Slide

  26. @jezhumble
    part the third
    operations

    View Slide

  27. View Slide

  28. Ops
    Dev

    View Slide

  29. IaaS
    Ops
    Dev
    PaaS

    View Slide

  30. @jezhumble
    compliance
    https://18f.gsa.gov/2017/02/02/cloud-gov-is-now-fedramp-authorized/

    View Slide

  31. @jezhumble
    ask: how can we get people better information?
    in a complex, adaptive system failure is inevitable
    when accidents happen, human error is the starting point of a blameless
    post-mortem
    ask: how can we detect and limit failure modes?
    dealing with failure

    View Slide

  32. @beerops | https://beero.ps/2017/06/17/on-failure-and-resilience/
    The immediate response
    from everyone around was to ask, “What help
    do you need?”

    View Slide

  33. @jezhumble
    disaster recovery testing
    “For DiRT-style events to be successful, an organization
    first needs to accept system and process failures as a
    means of learning… We design tests that require
    engineers from several groups who might not normally
    work together to interact with each other. That way,
    should a real large-scale disaster ever strike, these people
    will already have strong working relationships”
    Kripa Krishnan | http://queue.acm.org/detail.cfm?id=2371297
    —Kripa Krishnan, Director, Cloud Operations, Google

    View Slide

  34. @jezhumble
    evolve your architecture incrementally
    continuous delivery increases speed, stability, and quality
    build for testability and deployability
    prepare for — and test for — failure
    create a platform-as-a-service
    summary

    View Slide

  35. thank you!
    © 2016-7 DevOps Research and Assessment LLC
    https://devops-research.com/
    To receive the following:
    • 30% off my new video course: creating high performance organizations
    • 50% off my CD video training, interviews with Eric Ries, and more
    • A copy of this presentation
    • A 100 page excerpt from Lean Enterprise
    • An excerpt from The DevOps Handbook
    • A 20m preview of my Continuous Delivery video workshop
    Just pick up your phone and send an email
    To: [email protected]
    Subject: devops

    View Slide