$30 off During Our Annual Pro Sale. View Details »

Consumer Driven Contracts (DDD Perth 2016)

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.

Rob Crowley

August 27, 2016
Tweet

More Decks by Rob Crowley

Other Decks in Programming

Transcript

  1. 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!
  2. Modern Architectures are Complex Service Service Service Service Service Service

    Service Service Service Service Service Client Client Client Service Service Service Service
  3. Some people, when confronted with a problem, think “I know,

    I'll use system integration tests.” Now their problems scale combinatorially.
  4. 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
  5. “Reliability problems largely occur at module boundaries, and most result

    from inconsistencies in both sides expectations” - Bertrand Meyer, Object Success
  6. 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
  7. 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
  8. 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
  9. 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
  10. symmetry s m tri/ ˈ ɪ ɪ noun The correspondence

    of the form and arrangement of elements or parts on opposite sides of a dividing line.
  11. 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”
  12. Given ”products exists” Upon receiving ”a GET request for product

    catalogue” With “an Accept header of text/plain” Will respond with ”406 Not Acceptable”
  13. Given ”Widget product does not exist” Upon receiving ”a GET

    request for Widget product” Will respond with ”404 Not Found”
  14. 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
  15. “Be liberal in what you accept, and conservative in what

    you send” - Jon Postel, The Robustness Principle
  16. 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
  17. 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
  18. 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
  19. So once contract tests are in place I can throw

    all of my integration tests away?
  20. It depends on the criticality of the business capability the

    service supports and your risk appetite
  21. The business value realized by a service is defined by

    the parts of it’s provider contract being leveraged by consumers
  22. “The biggest cause of failure in software- intensive systems is

    not technical failure; it’s building the wrong thing.” - Mary Poppendieck
  23. 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
  24. “Deploying to production quickly is easy; doing so quickly and

    responsibly however is non trivial” - Rob Crowley
  25. 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
  26. 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