When identifying microservice boundaries, it is not enough to consider domains only. Other forces like organisational communication structures, and time, strongly suggest that you also should include other criteria in your considerations. Based on real-world experience of numerous projects, this talk takes a pragmatic walk and explores some of these other heuristics which should also be shaping your microservice decomposition thinking. These considerations may not on the surface seem that obvious, but if ignored, can just as easily lead to project failure. So whether you’ve already been through a painful project which tried to decompose boundaries by the book and failed, or you’re looking for some insight into other considerations often not spoken about, this talk is for you.

1. 1
Heuristics for Service Boundaries
Heuristics for Service Boundaries
Erich Eichinger, Lead Consultant OpenCredo
@oakinger

2. 2
Heuristics for Service Boundaries
About
• Lead Consultant at OpenCredo
• Much longer in Software Delivery than I am willing to admit
• Hands on software development consultancy
• Cloud Native; Data Engineering & ML
@oakinger

3. 3
Heuristics for Service Boundaries
Why am I here?
• Wrote blog post: https://opencredo.com/identify-service-boundary-
heuristics/
• “Things I wish someone had told me”
• share my thoughts around those heuristics
@oakinger

4. 4
Heuristics for Service Boundaries
Where am I coming from?
• Architecting, Development and/or Hosting of ~1000 customer
websites
• Domains: Embedded, News, Online Betting, Sports, Banking,
Automotive, Public Sector, ...
• “Ate my own dog-food”
@oakinger

5. 5
Heuristics for Service Boundaries
A naive approach... (don’t try this at home)
... unless you can make sure you’ll be far away when the first change
request comes in...
@oakinger

6. 6
Heuristics for Service Boundaries
Traditional Practices
• “Use noun phrase technique”
for domain analysis
• add some UI/Business/Data
Layer
@oakinger

7. 7
Heuristics for Service Boundaries
Traditional Processes
@oakinger

8. 8
Heuristics for Service Boundaries
... and you get 🙀
@oakinger
Customer
Service
Customer UI
Shopping Cart
Service
Shopping Cart UI
Address Service
Address Data
Access
User Profile Data
Access
UI
Biz
Data

9. 9
Heuristics for Service Boundaries
What are (some of) the problems?
• Boxes look good, but...
• Coordination between Teams exponential
• Ignorance of Organizational Context (Silos)
• Change Requests ripple through
• Archi-Tectonic Drift
@oakinger

10. 10
Heuristics for Service Boundaries
Real World Service-Orientation
• “Bob books a Vacation”:
– https://dannorth.net/classic-soa/
• “Starbucks doesn’t use 2-phase commit”
– https://www.enterpriseintegrationpatterns.com/ramblings/18_starbucks.html
@oakinger

11. 11
Heuristics for Service Boundaries
Service Attributes
• Independent delivery pipeline (planning, implementation,
deployment)
• Owned by one team
• Decentralized governance
• Independent Data-Storage
• Ownership of Communication Interfaces
• Clear Terminology (aka “ubiquitous language”)
• If user-facing, it comes with its own UI
@oakinger

12. 12
Heuristics for Service Boundaries
Forces & Dimensions
• Multiple forces drive architectural decision making
@oakinger

13. 13
Heuristics for Service Boundaries
Coupling: Failure Domains
https://twitter.com/chimeracoder/status/1047154302375141377?s=21
@oakinger

14. 14
Heuristics for Service Boundaries
Coupling: Other
• Data Structures and -Types (Events, Records)
• Deep Links/URIs
• Synchronous APIs (both, syntax *and* semantics)
• Distributed Transactions
@oakinger

15. 15
Heuristics for Service Boundaries
Domain Model Cohesion
• “unified view of customer”
@oakinger
Customer Service

16. 16
Heuristics for Service Boundaries
Domain Model Cohesion (II)
• “Customer” in Accounting is very different from “Customer” in
Support
• Leads to unrelated changes in the same service
=> Bounded Context (Domain Driven Design)
@oakinger

17. 17
Heuristics for Service Boundaries
Stable vs. Unstable
• Over time some services will mature and stabilize
• Other services are under constant change or may even get retired
=> Isolate Stable from Unstable services
@oakinger

18. 18
Heuristics for Service Boundaries
Load
• What if a batch process hits your API?
=> Instead of hardening the entire service, better isolate/specialize
high frequency/large payload consumer API from others
@oakinger

19. 19
Heuristics for Service Boundaries
Organisation
• Technical Optimum can be very different from organisational
Optimum:
=> Large Change, but Team ”WeChat” stays independent!
@oakinger
SSO Service
WeChat
Integration
Small
change
Large
change
vs

20. 20
Heuristics for Service Boundaries
Erosion: “what’s your unit/scope of change?”
• Changes ripple across multiple
services
Death by coordination meetings
Architecture erodes by teams taking
shortcuts
@oakinger

21. 21
Heuristics for Service Boundaries
Split at Process Hand-Offs
• Changes often affect process flows
• UI+Biz+Data = Self Contained
Systems
@oakinger
Browse
Products
Add to
Cart
Configure
Product A
Checkout
Configure
Product B
Configure
Product C

22. 22
Heuristics for Service Boundaries
Operation
• Every service comes with overhead
– Deployment
– Versioning
– UI
– Monitoring
– Tracing
– Resiliency
• Different Teams may have different maturity/skillsets
@oakinger
Checkout
Service
Checkout
Service
Checkout
Service
Profile
Service
Checkout
Service
Browse
Product
Service

23. 23
Heuristics for Service Boundaries
Security
• Every service increases attack surface
@oakinger
One Big
Service
Profile
Service
Profile
Service
Profile
Service
Profile
Service
vs

24. 24
Heuristics for Service Boundaries
There’s more...
• Data Location
• Security Constraints
• Budget Owner
• ...
@oakinger

25. 25
Heuristics for Service Boundaries
Most of all: time!
• Time may invalidate underlying assumptions
– functions move around
– service retirement
• We learn over time
– Example Batch API overload
• Learning & Response requires agility on all levels
– Reduce entry/exit costs for services (e.g. with containers)
– Observability
@oakinger

26. 26
Heuristics for Service Boundaries
“Begin with the End (&Cost) in Mind”
• Where does the organization stand right now?
– It takes time to digest changes
• what do we want to achieve/optimize for?
– Have a clear vision
• define measurable goal(s)
– “Fitness Functions” (Neal Ford, “Building Evolutionary Architectures”)
• Goals and Optima are highly contextual and come with costs!
– “More services” is an economic question
@oakinger

27. 27
Heuristics for Service Boundaries
Example Goals
• Isolate Critical Modules
• More deployments/[day,week,month]
– SkyScanner Talk “10k deploys a day”
• Parallelize Delivery
– But remember Amdahl’s law
@oakinger

28. 28
Heuristics for Service Boundaries
Enable Change
• Consider Service End-Of-Life
– How can a service be retired?
• Reduce entry/exit costs for services
– Make dealing with overhead “cheaper”
– Ultimately serverless
• Observability
@oakinger

29. 29
Heuristics for Service Boundaries
Co-Evolve
• Culture
• Business
• Architecture
• Operations
• Development
• Security
They all influence and enable each other – can’t have 100 services
without low-cost deployment pipeline and org culture
@oakinger

30. 30
Heuristics for Service Boundaries
Tips
• Start small (extreme: “Monolith first”)
• no right way to decompose - question of economy/fitness function
– Bounded Context and Process Flows are a good start
• observability first
• make principles & decisions easy to communicate & understand
– have peers challenge your ideas
• “continuous architecture” (aka “evolutionary”)
– Grow architecture, co-evolve with culture: biz, arch, dev, sec & ops
– re-evaluate assumptions, reduce entry/exit costs for services
@oakinger

31. 31
Heuristics for Service Boundaries
Thanks!
Catch me on Twitter @oakinger
Blog with catalogue of heuristics (and lots of related links):
https://opencredo.com/identify-service-boundary-heuristics/
@oakinger