Consumer Driven Contracts (DDD Perth 2016)

The API economy is here and it's fueling disruption in many established industries. In response to this. many companies are looking to increase their agility through breaking down legacy monoliths into discrete services focused around specific business capabilities. Whilst this approach has many advantages, there are potential pitfalls awaiting the unwary. The number of integration points between these distributed components is greatly increased. Considering such an architecture, a naïve approach could be to simply continue to apply traditional integration testing techniques as this can lead to spiraling cost of ownership through brittle test suites. What can we do to mitigate this risk while still giving us the confidence that the various services will work cohesively?
In this session we will explore using consumer driven contacts, specifically Pact, to solve this problem and share some lessons learned from the trenches.

Transcript

1. Consumer Driven Contracts
   Say what you mean and mean what you say
   @robdcrowley
   robdcrowley
   

   View Slide

2. Session Goals
   Learn how consumer driven contracts facilitate a low friction
   approach to service evolution
   Explore how Pact enables service providers to know if a change
   would break consumers before deploying
   Consumer driven contracts as a catalyst for cultural change
   Empower you with innovative ideas to bring back to your
   organisation!
   

   View Slide

3. Digital disruption is driving change across established
   industries
   

   View Slide

4. The agility to respond to rapidly changing customer
   needs is vital for remaining competitive
   

   View Slide

5. Software architecture must also become more agile
   

   View Slide

6. Modern Architectures are Complex
   Service
   Service
   Service
   Service Service
   Service
   Service Service
   Service
   Service
   Service
   Client
   Client
   Client
   Service
   Service
   Service
   Service
   

   View Slide

7. Some people, when confronted with a problem, think
   “I know, I'll use system integration tests.” Now their
   problems scale combinatorially.
   

   View Slide

8. Combinatorial Scaling
   2 code paths: 26 = 64
   4 code paths: 46 = 4096
   6 code paths: 66 = 46656
   8 code paths: 86 = 262144
   Service
   Service
   Service
   Service Service
   Service
   Service
   Service
   Service
   Service
   Service
   Service
   Client
   Client
   Client
   

   View Slide

9. “Reliability problems largely occur at
   module boundaries, and most result
   from inconsistencies in both sides
   expectations”
   - Bertrand Meyer, Object Success
   

   View Slide

10. Implicit Interfaces
    No explicit interface between
    collaborators enforced by type
    system or compiler checks
    Service
    Service
    Service
    Service Service
    Service
    Service
    Service
    Service
    Service
    Service
    Service
    Client
    Client
    Client
    

    View Slide

11. Implicit Interfaces
    No explicit interface between
    collaborators enforced by type
    system or compiler checks
    Let’s change and deploy a
    service
    Service
    Service
    Service
    Service Service
    Service
    Service
    Service
    Service
    Service
    Service
    Service
    Client
    Client
    Client
    

    View Slide

12. Implicit Interfaces
    No explicit interface between
    collaborators enforced by type
    system or compiler checks
    Let’s change and deploy a
    service
    Hope we don’t break existing
    collaborators
    Service
    Service
    Service
    Service Service
    Service
    Service
    Service
    Service
    Service
    Service
    Service
    Client
    Client
    Client
    

    View Slide

13. Integration Tests
    Slow (longer feedback cycle)
    Brittle
    Difficult to manage
    Finding the actual issue requires triage
    Scale combinatorially
    Written after the code rather than before
    

    View Slide

14. So if integration tests are not the solution
    then what is?
    

    View Slide

15. So if integration tests are not the solution
    then what is?
    Test Symmetry
    

    View Slide

16. symmetry
    s m tri/
    ˈ ɪ ɪ
    noun
    The correspondence of the form and
    arrangement of elements or parts on opposite
    sides of a dividing line.
    

    View Slide

17. Test Symmetry
    A B
    

    View Slide

18. A B
    Mock
    Test Symmetry
    

    View Slide

19. A B
    Mock
    Trivial
    Test Symmetry
    

    View Slide

20. A B
    Mock
    Trivial Tricky
    Test Symmetry
    

    View Slide

21. Symmetrical tests have the exact opposite properties
    

    View Slide

22. Pact
    www.pact.io
    

    View Slide

23. Know when you break a consumer before deploying
    the change
    

    View Slide

24. Specification by Example
    

    View Slide

25. Pact – Define Expectations
    Consumer Provider
    PACT
    HTTP Request
    HTTP Response
    Record
    

    View Slide

26. Pact – Verify Expectations
    Consumer Provider
    PACT
    HTTP Request
    HTTP Response
    Replay
    

    View Slide

27. Fast (rapid feedback cycle)
    Reliable
    Low ramp up cost
    Straightforward to debug
    Scale linearly
    Contract Tests
    

    View Slide

28. Given ”products exists”
    Upon receiving ”a GET request for product catalogue”
    With “an Accept header of application/hal+json”
    Will respond with ”200 OK”
    And “a Content-Type header of application/hal+json”
    And ”the product catalogue details in the entity body”
    

    View Slide

29. Given ”products exists”
    Upon receiving ”a GET request for product catalogue”
    With “an Accept header of text/plain”
    Will respond with ”406 Not Acceptable”
    

    View Slide

30. Given ”Widget product does not exist”
    Upon receiving ”a GET request for Widget product”
    Will respond with ”404 Not Found”
    

    View Slide

31. Examples
    

    View Slide

32. Joining the dots...
    Product
    Sales
    Service
    Product
    Catalogue
    Service
    Product
    Stock
    Service
    Pact
    Broker
    git clone https://github.com/robcrowley/microservices-pact-demo.git
    JUnit for pact generation
    Gradle pact plugin for provider
    verification
    Pact Broker for pact repository
    Docker integration
    

    View Slide

33. Start with the consumer
    

    View Slide

34. View Slide

35. View Slide

36. View Slide

37. View Slide

38. Then move onto the provider
    

    View Slide

39. View Slide

40. View Slide

41. View Slide

42. View Slide

43. “Be liberal in what you accept, and
    conservative in what you send”
    - Jon Postel, The Robustness Principle
    

    View Slide

44. Implications of Postel’s Law
    An expectation may not be made for a field to be absent from a
    response
    Exception: Request headers that change the behaviour of the
    provider must be specified in expectations
    

    View Slide

45. Sharing Pacts
    

    View Slide

46. Pact Broker
    Consumer Provider
    Pact Broker
    

    View Slide

47. Pact Broker
    Consumer Provider
    Pact Broker
    Publish
    PUT /pacts/provider/{provider}/consumer/{consumer}/versions/{version} HTTP/1.1
    

    View Slide

48. Pact Broker
    Consumer Provider
    Pact Broker
    Publish
    PUT /pacts/provider/{provider}/consumer/{consumer}/versions/{version} HTTP/1.1
    Pull
    GET /pacts/provider/{provider}/consumer/{consumer}/latest HTTP/1.1
    

    View Slide

49. Facilitates the sharing of pacts between consumer
    and provider projects
    Enables service release cycles to be decoupled
    Example driven API documentation
    Visualisations of relationships between services
    Web Hooks to provide integration with CI Builds
    Pact Broker
    

    View Slide

50. View Slide

51. View Slide

52. Backwards Compatibility Testing
    Use Tags to ensure provider is compatible with latest and released versions of consumers
    PUT /participants/{consumer}/versions/{version}/tags/{tag} HTTP/1.1
    GET /pacts/provider/{provider}/consumer/{consumer}/latest/{tag} HTTP/1.1
    Consumer Head
    (Pact Broker)
    Consumer Production
    (Pact Broker)
    Provider Head
    (Source Control)
    Contract Tests
    Contract Tests
    Producer backwards
    compatibility
    Provider Production
    (Source Control)
    Contract Tests
    Consumer backwards
    compatibility
    Already Tested
    

    View Slide

53. So once contract tests are in place I can throw all
    of my integration tests away?
    

    View Slide

54. It depends on the criticality of the business capability
    the service supports and your risk appetite
    

    View Slide

55. View Slide

56. Make production monitoring and alerting a priority
    

    View Slide

57. Other Benefits
    

    View Slide

58. Higher quality services
    

    View Slide

59. “Quality comes from deliberate thought”
    - Michael Feathers, Testing Patience
    

    View Slide

60. Reduced waste in delivery process
    

    View Slide

61. The business value realized by a service is defined
    by the parts of it’s provider contract being leveraged
    by consumers
    

    View Slide

62. “The biggest cause of failure in software-
    intensive systems is not technical failure; it’s
    building the wrong thing.”
    - Mary Poppendieck
    

    View Slide

63. Focusing on delivering the capabilities as defined in
    consumer contracts drives building the right thing
    

    View Slide

64. Takeaways
    Consumer Driven Contracts enable services to evolve gracefully
    Pact combines isolated unit testing with contract testing
    Pact enables delivery at speed by providing rapid feedback on
    potential breakages
    Pact allows test driven development principles to be applied to
    services
    Consumer Driven Contracts can be a catalyst for cultural change by
    fostering collaboration between delivery teams and reducing waste
    

    View Slide

65. “Deploying to production quickly is easy;
    doing so quickly and responsibly
    however is non trivial”
    - Rob Crowley
    

    View Slide

66. Adopting a consumer driven contract testing
    approach can help
    

    View Slide

67. Questions
    

    View Slide

68. More Info
    Gitbook: docs.pact.io
    Github: realestate-com-au/pact and DiUS/pact-jvm
    User group: https://groups.google.com/forum/#!forum/pact-support
    Twitter: pact_up
    Pact to the Rescue!: http://www.slideshare.net/bethesque/pact-44565612
    Deploy with Confidence using Pact Go!: https://www.youtube.com/watch?v=SMadH_ALLII
    Consumer Driven Contracts – A Service Evolution Pattern: http://martinfowler.com/articles/consumerDrivenContracts.html
    

    View Slide

69. Appendices
    

    View Slide

70. Contracts 101
    Provider Consumer Driven
    Consumer
    Closed & Complete
    Singular & Authoritive
    Bounded Stability &
    Immutability
    Open & Incomplete
    Mutable & Non-Authoritive
    Bounded Stability &
    Immutability
    Closed & Complete
    Singular & Non-Authoritive
    Bounded Stability &
    Immutability
    

    View Slide