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.

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: jezhumble@sendyourslides.com
    Subject: devops
    

    View Slide