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. 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.
  2. @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?
  3. @jezhumble time to restore service lead time for changes release

    frequency change fail rate software delivery performance https://devops-research.com/research.html
  4. @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
  5. @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
  6. @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
  7. @jezhumble bind components at build time “Large Scale Continuous Testing

    in the Cloud” | John Penix | http://bit.ly/1BYMf70
  8. 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
  9. @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…
  10. 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
  11. @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
  12. @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
  13. @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
  14. @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
  15. 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