POSTMAN | CDC testing to maintain growing microservices stacks

1. Effective
Consumer-Driven
Contracts
Presented by
Preetham M
Head of Product - Core

2. Agenda
1 API as a product
2 Microservices
3 Problem statement
4 Consumer-driven contract testing
5 How do we do it at Postman?

3. HEAD OF PRODUCT-CORE, POSTMAN
Preetham
M
@getpostman

4. ● APIs drive business
● Consumer-centric design
● Public APIs are nurtured and maintained better
● APIs are products irrespective of the sphere of influence
API as a Product

5. Microservices is an architectural style that structures an application as a
collection of services that are:
● Highly maintainable and testable
● Loosely coupled
● Independently deployable
● Organized around business capabilities
● Owned by a small team
The microservice architecture enables the rapid, frequent, and reliable
delivery of large, complex applications. It also enables an organization to
evolve its technology stack.
Microservices

6. Costs
● Distribution
● Eventual Consistency
● Operational Complexity
Microservices

7. Dependency Hell
Dependency hell is a colloquial term for the frustration of some software
users who have installed software packages which have dependencies on
specific versions of other software packages.

8. Dependency Hell
Signals and symptoms
● One service fails, all fail
● All services need to be deployed
together
● Services can’t evolve because of
shared databases or intertwined
schemas
● Not microservices, but a Distributed
Monolith
● A Monolith with all the costs of
microservices!

9. Costs
● Distribution
● Eventual Consistency
● Operational Complexity
Microservices

10. ● Microservices introduce eventual consistency issues because of the
insistence on decentralized data management.
● Monoliths: Single transaction. Microservices: Multiple resources need
to update.
● Developers need to be aware of consistency issues.
● Maintaining strong consistency is extremely difficult for a distributed
system, which means everyone has to manage eventual consistency.
Eventual Consistency

11. ● Puts additional strain on operations with hundreds of little
microservices.
● Continuous Delivery: Essential in a microservices setup.
● Danger complexity shifts to the interconnection between services.
● You need a mature operations team to manage lots of services, which
are being redeployed regularly.
Operational Complexity

12. Fallacies of distributed computing:
● The network is reliable.
● Latency is zero.
● Bandwidth is infinite.
● The network is secure.
● Topology doesn't change.
● There is one administrator.
● Transport cost is zero.
● The network is homogeneous.
Distribution

13. Distribution
● Developing microservices is easy,
but making sure you build a reliable
system is hard, very hard.
● A distributed system shifts the focus
from the node to the edges.
● It’s hard to:
○ evolve services
independently
○ know which services are
communicating with each
other

14. In a monolithic
world…

15. In a microservices
world…

16. Principles of
Microservices Design

17. Microservice
Communication
● Provider creates a contract to any
consumer that wants to use the API.
● This is how you “can” and “should”
use my API.
● Responsibility of the provider to
ensure any changes to the service
do not breach their own contract.
● But how do we know when there’s a
breaking change?

18. API Versioning
● A new API version per release
● Is that scalable?

19. Consumer-Driven
Contracts
● API consumer writes contracts to
test an API.
● This contract defines expectations
set by the consumer.
● This is how I am using the API.
● The Consumer can test only the
endpoints and properties it needs.

20. Consumer-Driven
Contracts
● Consumer-driven contracts are a
pattern for evolving services.
● Each consumer captures their
expectations of the provider in a
separate contract.
● All of these contracts are shared
with the provider so they gain
insight into the obligations they
must fulfill for each individual
consumer.

21. ● The contract between services needs to be explicit and executable.
● Execute the expectations against multiple consumers and if one of
them breaks, you know exactly which consumer you’ve broken.
● Independent isolated testing of a service that allows you to go to
production without the need for big end-to-end testing.
Consumer First

22. ● A test of business logic. That should be covered by your service’s unit
tests.
● A service-level agreement (SLA) between services.
● A system to validate external APIs service responses.
What a Contract Test Isn’t?

23. ● A consistent format to describe requests and responses between
provider and consumer.
● An easy way to create contracts.
● A way of storing the created contracts.
● A way to test the services against the contracts, in an automated way.
● A way of running these tests locally.
● A way to manage the evolution of these contracts.
Consumer-Driven Contract Tooling:

24. How Do You Stay Agile with
Consumer-Driven Contracts

25. APIs in Postman

26. Collections
● Executable specifications of an API
● Auto-generated documentation
● Collaboratively editable in
Workspaces
● Collections can be run anywhere:
locally, commandline, CI, or cloud

27. ● Simple log retrieval service
● 1 endpoint: Returns list of last 5 log entries
● 2 consumer
Example Use Case

28. API Definition
Can use collections/APIs

29. Documentation

30. Mock Servers

31. Consumer Contracts

32. Consumer Contracts

33. Stages of Implementing
Consumer-Driven Contracts

34. Continuous Testing
● Use Postman API to fetch all the contracts of the a particular API.
● Use Newman to run all consumer contract collections of a service on
each change.
● Use Monitors to keep testing services periodically.

35. API Versioning
● Sometimes you have to break contracts. How do you do that without
impacting consumers?
● API versioning
● Co-existing endpoints
● Co-existing service versions
● Should be clearly communicated to the consumers

36. Next Steps
Download the Economic Benefits Report
https://www.postman.com/postman-economics-report/

37. Thank You
postman.com @getpostman