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
2. @jezhumble microservices
3. @jezhumble part the first continuous delivery
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.
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?
6. @jezhumble time to restore service lead time for changes release frequency change fail rate software delivery performance https://devops-research.com/research.html
8. Jon Jenkins, “Velocity Culture, The Unmet Challenge in Ops” | http://bit.ly/1vJo1Ya
9. why continuous delivery? https://arstechnica.com/information-technology/2017/09/massive-equifax-breach-caused-by- failure-to-patch-two-month-old-bug/
10. @jezhumble configuration management continuous integration automated testing ingredients
11. @jezhumble deployment pipeline
12. continuous delivery SEM
13. @jezhumble part the second architecture
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
15. @jezhumble unreliable platform resilience, security, scalability, deployability, testability are architectural concerns
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
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
18. @jezhumble bind components at build time “Large Scale Continuous Testing in the Cloud” | John Penix | http://bit.ly/1BYMf70
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
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…
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
22. http://www.flickr.com/photos/trustedsource/6132507962/
23. @jezhumble strangler application
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
25. Steve Yegge’s Platform Rant | https://bit.ly/yegge-platform-rant
26. @jezhumble part the third operations
28. Ops Dev
29. IaaS Ops Dev PaaS
30. @jezhumble compliance https://18f.gsa.gov/2017/02/02/cloud-gov-is-now-fedramp-authorized/
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
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?”
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
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
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