Maturity model for Microservices: Untangling a Big Ball of Mud, Ankit Sobti, Co-Founder & CTO, Postman

1. Maturity Model for Microservices
Ankit Sobti
Co-Founder & CTO, Postman
PRESENTED BY
April 19, 2019

2. April 19, 2019
About Me
Founder of
Postman
A Builder
Since 2012
Passionate
about APIs
API

3. Postman
API Development Environment
API Workflow
Design & Mock
Design in Postman & use
Postman’s mock service
Debug
Test APIs, examine responses,
add tests and scripts
Automated Testing
Test APIs, examine responses,
add tests and scripts
Document
Create beautiful web-viewable
documentation
Monitor
Create automated tests to monitor
APIs for uptime, responsiveness &
correctness
Publish
Onboard developers to your API
faster with Postman collections
and documentation
Team Library
Collaboration
TeamLibrary
Collaboration
Monitor
Publish
Document
Design & Mock
Debug
Automated Testing

4. April 19, 2019
History of Microservices at Postman
• Postman the company was founded in late 2014
• Already had a really popular product, Postman - 650k users in every single country in the world
• 4 member Engineering team - including the 3 founders
• Microservices were really really popular, started breaking our backend systems down.
• As engineers, who loved abstractions and forward thinking architectures, the benefits just made a lot of sense

5. April 19, 2019
Microservices
• Strong modular boundaries
• Independent Deployment
• Technological Diversity
Benefits
https://martinfowler.com/articles/microservice-trade-offs.html

6. April 19, 2019
Microservices
• Strong modular boundaries
• Independent Deployment
• Technological Diversity
Benefits
• Distribution
• Eventual Consistency
• Operational Complexity
Costs
https://martinfowler.com/articles/microservice-trade-offs.html

7. April 19, 2019
Dependency Hell
• What is it and how does it happen?
• One service fails, all fail
• All services need to be deployed together
• Expensive cross-team collaboration to align
roadmaps around releases
• 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!

8. April 19, 2019
Dependencies

9. April 19, 2019
Principles of Microservices Design

10. April 19, 2019
Domain Driven Design
• Bounded Context: is a semantic contextual
boundary. The components inside a Bounded
Context are context specific and semantically
motivated.
• Ubiquitous Language: A strict, exact, stringent
and tight language that is ubiquitous within the
team, and reflects in communication and code.
• Context Mapping: allows multiple Bounded
Contexts to integrate, defining both team
relationships and the technical mechanisms that
exist between them.
DDD models a Ubiquitous Language in an explicitly Bounded Context.
Image Source: https://martinfowler.com/bliki/BoundedContext.html

11. April 19, 2019
Bounded Context
• Boundaries created based on “business”, not
technical concerns
• Aligned around generating value to the end
consumer
• Concepts are either in-context or out of context
• Value may be delivered through Web, Mobile,
Slack Integration, API etc
Value Delivery Unit

12. Teams
1. Teams are isomorphic with Bounded Contexts.
2. Teams communicate using the Ubiquitous
Language
3. Domain Expert - brings the business nous
4. Teams are not structured by technical know-how,
hire for skills that align to generate end consumer
value
5. Teams are autonomous
1. Reduce cross team collaboration
2. Responsible for End user experience
6. Teams are modeled to become domain, not
technical experts - through an open and
transparent environment that promotes learning
and exploration

13. April 19, 2019
Context Mapping
• Context boundaries are explicit
• Bounded contexts only interact with other
bounded contexts through clearly defined APIs
• Important to preserve conceptual integrity of
context
• Consumer Driven APIs - not a 1:1 reflection of the
domain model

14. Microservices
1. How do you define the boundary of a
Microservice?
2. Microservices often discussed technically -
Polyglot, Independent deployment etc
3. Aligns business concerns with clear code
separation
4. Microservices don’t cross domain boundaries
5. Microservices can be split up within a domain as
per technical concerns - “Deployment Units”

15. April 19, 2019
In Summary
• DDD allows you to focus on Business Value over Technical Strategy
• The problem owned by a single team encourages building out a:
• single long-term vision and roadmap for the problem space,
• enabling broader, more strategic solutions
• DDD enables Cross-functional collaboration
• autonomous teams composed of engineering, data, product, marketing etc
• all aligned to unlocking user value
• Clear business logic separation through Microservices

16. April 19, 2019
Principles of Microservices Design

17. April 19, 2019
SLAs across
Bounded Contexts
• Domain team responsible for end-to-end user
experience
• Dependency chain between Bounded Contexts
• Context mapping - internal domains or external systems
• Mitigate against issues from downstream dependencies
• SLA - Service License Agreement
• SLA violations - mitigation strategy

18. April 19, 2019
Maturity Model & Bounded Contexts
• Acts as a toolkit to quantify and measure these SLAs over time across the pillars of:
• Quality
• Performance
• Availability
• Resilience
• Security
• Agility
• Track Dependencies across Domain Boundaries and quantify end-consumer experience

19. April 19, 2019
Quality
• Derived from the end-user experience
• Sources
• User reported bugs
• Team reported bugs - Quality, Canary
• Quantified to reflect % of users impacted
• 99% score means 1% of the user base is
affected
• aggregate and downstream dependency

20. April 19, 2019
Performance
• Domain team charts out user journeys
during Design process
• Performance indexed against
satisfactory user journey time

21. April 19, 2019
Availability
• Think beyond Pings
• BDD stories are rich in “Ubiquitous
Language”
• Use Postman monitors to write
acceptance tests against user stories
• Availability of these user stories -
quantified against % of users impacted

22. Resilience
• How resilient is your system to the (non)
availability of each of its dependencies?
• Consumer Driven Contracts
• Chaos Testing

23. April 19, 2019
Security
• Sources
• Security Audits
• VAPT
• Security Researchers
• Reported vulnerabilities - node
packages, infrastructure components
• Graded against time - based on CVSS
score

24. Agility
• A yardstick for the Product and Engineering
Managers
• Evaluation of planning, completion rate
and eventual impact
• RICE model - Reach, Impact, Confidence,
Effort - product planning
• A measure of cross-domain interactions
outside of APIs

25. April 19, 2019
Principles of Microservices Design

26. April 19, 2019
Summary
• Feedback loop: Metrics from the maturity model
help take better decisions in building and scaling
microservices to build a resilient stack that
ensures high quality over time
• Maturity Model introduces a system of
accountability, not just shipping new, shiny
things
• DDD works if domain boundaries are well
defined. If a significant amount of cross-team
collaboration still occurs, the boundaries are
porous and need to be redrawn - Maturity
model helps us measure that.

27. Thank You!