Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Architectures for Continuous Delivery

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

2350801025b8e8592dbaa8dd98a24cbb?s=128

Eberhard Wolff

May 17, 2018
Tweet

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.