Architectures for Continuous Delivery

Continuous delivery helps to achieve typical goals of a good software architecture - but continuous delivery must also be support in the architecture. This presentation show the relation between architecture and continuous delivery - and how this makes software development more successful

Transcript

1. Eberhard Wolff Fellow INNOQ @ewolff http://ewolff.com
2. http://continuous-delivery-book.com/
3. http://microservices-book.com/
4. http://microservices-book.com/ primer.html FREE!!!!
5. http://practical-microservices.com/
6. http://practical-microservices.com/ recipes.html FREE!!!!
7. Continuous Delivery – Why Do I Even Care?
8. Faster Feedback Implementation Production Deployment
9. Lower Risk • Each deployment contains less changes • Lower risk of a bug • Easier to fall back • …or add other safeguards Quarterly Release Daily Release
10. Continuous Delivery A Proven Success! • 2017 State of DevOps Reports by DORA based on 27.000 surveys • Failure rate multiple deploys a day: 0-15% • Failure rate once a week to once a month: 31-45% https://puppet.com/resources/whitepaper/state-of-devops-report
11. Higher Reliability • Automated deployment and tests • …easy to reproduce • ...faster • ...executed frequently Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release ❌ ✅ ❌ ✅ ❌ ✅
12. Principles Agile Manifesto Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
13. Continuous Delivery: Why Do I Even Care? • Faster Feedback • Lower Risk • Higher Reliability • Value to the customer
14. Architecture
15. Architecture • Structure • Goal often: Easy changeability
16. Continuous Delivery FTW! • Usually changeability = well-structured software • What is easier to change? • …well-structured software? • …or software with extensive automated tests? ❌ ✅
17. Continuous Delivery FTW! • Usually changeability = well-structured software • What would you rather change? • …well-structured software • …or software that goes in production reliably and fully automated?
18. Architecture Continuous Delivery CD supports architecture goals like changeability
19. Implementing Continuous Delivery
20. Customer Scenario • Quarterly releases • 10 weeks of testing • Release two days over the weekend • Goal: Several deployments a day Development Testing Release Testing + Release + Development Time
21. Customer Scenario: Automation • Development faster – smaller batches • Assumption: Test automation = 100x speedup for test • 4h Tests Development Testing Release Testing
22. Customer Scenario: Automation • Assumption: Deployment automation = 4x speedup • 2h Deployment Release Testing
23. Customer Scenario: Automation • 2h Deployment + 4h tests = 6 hours = 1 deployment per day Need another threefold improvement Release Testing
24. Automation • Automation gives limited speedup • Necessary for reliability • Is automation the only knob?
25. Architecture • What are the modules? • Make modules independently deployable! • …continuous delivery pipelines are much simpler. • …deployment is less risky. • Microservices!
26. Microservices • Another knob to tune deployment • Don’t ignore this option!
27. Architecture Continuous Delivery CD supports architecture goals like changeability Architecture must support Continuous Delivery
28. Microservices
29. Microservices are not a Magic Wand
30. Independent Systems Architecture: ISA 9 Microservices Best Prac:ces Creator: INNOQ | http://isa-principles.org
31. 1 | Modules Creator: INNOQ | h5p://isa-principles.org
32. Creator: INNOQ | h/p://isa-principles.org >Reuse “Module” ideas: >High cohesion, low coupling, >SeparaCon of concerns, >Single Responsibility … 1 | Modules
33. 2 | Container Creator: INNOQ / h3p://isa-principles.org 2 | Container Creator: INNOQ / h3p://isa-principles.org
34. Creator: INNOQ | http://isa-principles.org >Modules = containers (or VMs, processes …) 2 | Container
35. 6 | Independent Con,nuous Delivery Pipeline Creator: INNOQ | h<p://isa-principles.org
36. Creator: INNOQ | h/p://isa-principles.org >Microservices can only be deployed independently … >... if pipelines are independent 6 | Independent ConBnuous Delivery Pipeline
37. Making Microservices Actually Work
38. Interfaces
39. Interfaces • Microservice have interfaces to other microservices • Changing an interface means two microservices need to be changed
40. Invoice Uses Interface Version 42 Order Provides Interface Version 42 Invoice V43 Order V43 Deployment of Order and Invoice
41. Invoice Uses Interface version 42 Order Provides Interface version 42 Invoice V43 Order V43 Deployment of order and invoice Dependent Deployment Pipelines!
42. Invoice Uses V42 Order Provides V42 Invoice Uses V42 Order Provides V43 Backwards Compatible Invoice Uses V43 Order Provides V43 Deployment of Order Deployment of Invoice
43. What about not backwards compatible changes?
44. Invoice Uses V42 Order Provides V42 Invoice Uses V42 Order Provides V43 & V42 Invoice Uses V43 Order Provides V43 & V42 Deployment of Order Deployment of Invoice Invoice Uses V43 Order Provides V43 Deployment of Order
45. But… • …this is hard! • …but otherwise: no independent deployment • Worst case: everything must be deployed in one step. • Deployment monolith
46. Tests
47. Tests • It is not enough to separate microservices • For independent deployment pipelines, tests must be separated, too.
48. Order Continuous Delivery Pipeline Integration Tests Invoice Continuous Delivery Pipeline Search Continuous Delivery Pipeline Production
49. Order Continuous Delivery Pipeline Integration Tests Invoice Continuous Delivery Pipeline Search Continuous Delivery Pipeline Production
50. Integration Test = Bottleneck
51. Invoice (Consumer) Order (Provider) Request Reply
52. Invoice (Consumer) Stub Request Reply
53. Stubs • Does the calling module (invoice) work as expected? • Use stubs to replace called module
54. Order Continuous Delivery Pipeline Integration Tests Invoice Continuous Delivery Pipeline Search Continuous Delivery Pipeline Production
55. Invoice (Consumer) Order (Provider) Request Reply
56. Consumer- Driven Contract Test Order (Provider) Request Reply
57. Consumer-driven Contract Test • Does the called module (order) work as expected? • Use consumer-driven contract test to replace calling module • Easy to test changes to interfaces
58. Consumer-driven Contract Test • A pattern: Invoice provides a test for Order • …might be written with any testing framework • Pact test can be written in one programming language • …recorded as JSON • …and can be executed with a different language • Technology independence • https://github.com/mvitz/pact-example
59. Order Continuous Delivery Pipeline Integration Tests Invoice Continuous Delivery Pipeline Search Continuous Delivery Pipeline Production
60. Database
61. Database Changes Are Hard • Schema changes • Converting existing data • Potential lots of data • Takes long • Might fail • Hard or even impossible to rollback
62. Dealing with Database Changes • Backwards compatible changes only • Support previous version schema • Default value for new columns • Incompatible changes after software changes • Remove column only if not used any more • …
63. Keep Database Schema Stable • Change database before microservices use it • Change database seldom • E.g. once a week • i.e. schema changes not part of deployment • No rollback necessary
64. Invoice Uses Less Columns Invoice Invoice Uses New Columns Database Schema V24 Database Schema V23 Database Schema V24 Weekly Database Deployment Invoice Uses Database Schema V23 Database Schema V23 Deployment of Invoice Deployment of Invoice
65. Domain Architecture
66. Invoice Order • New features need changes to both microservices. • Deployment fully decoupled • …but that is useless • …as both will be deployed anyways • Also: Order too complex
67. Order Shipping address Tracking # Items Item Categories Priority shipping Customs # Account # ... Credit card # Order #
68. Bounded Context • Domain model is only valid for one context • There is no universal data model! • See all failed SOA attempts
69. Order Shipping address Tracking # Items Item Categories Priority shipping Customs # Account # ... Credit card # Order # Customs Order Recommen- dations Order Tracking Order Shipping address Tracking # Item Categories Priority shipping Customs # Invoice Order Account # Credit card #
70. Bounded Context • Decoupled domain architecture • Features need changes to one bounded context only. • Implement bounded contexts as microservices • …to gain independent microservices • …and really independent deployment.
71. Conclusion
72. Architecture Continuous Delivery CD supports architecture goals like changeability Architecture must support Continuous Delivery
73. Architecture for Continuous Delivery • Separately deployable modules • Aka microservices • Decouple deployments for interface changes! • Decouple tests! • Decouple database changes! • Use bounded context for decoupled domain architecture!
74. Architecture and Continuous Delivery • Architecture and continuous delivery • …two battles at the same time? • Split apart a microservice! • Easy to build a continuous delivery pipeline for a new microservice! • So: Synergy when introducing microservices and continuous delivery at the same time.