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

@jezhumble microservices

@jezhumble part the first continuous delivery

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.

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

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

No content

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

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

@jezhumble configuration management continuous integration automated testing ingredients

@jezhumble deployment pipeline

continuous delivery SEM

@jezhumble part the second architecture

@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

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

@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

@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

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

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

@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…

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

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

@jezhumble strangler application

@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

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

@jezhumble part the third operations

No content

Ops Dev

IaaS Ops Dev PaaS

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

@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

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

@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

@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

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