Microservices are great. Or at least that is what all the buzz says. And they are. If you get them right. That is, if you get boundaries between them and the scope of each one right. If not, microservices are just a distributed mess - which is worse than a monolithic mess. In this talk I will outline how you identifying good candidates for microservices and how you define the scope for each one in a way that optimizes for maintainability in the long run, resilience in production and efficiency of work.

1. SCOPING MICROSERVICES
CHRISTIAN HORSDAL
@CHR_HORSDAL
C.HORSDAL@GMAIL.COM

2. ABOUT ME
Christian Horsdal Gammelgaard
Independent Consultant
www.horsdal-consult.dk
c.horsdal@gmail.com
@chr_horsdal

3. INTRODUCTION TO MICROSERVICES

4. INTRODUCTION TO MICROSERVICES
A microservice is a service with one, and only one, very
narrowly focused capability that a remote API exposes
to the rest of the system.

5. INTRODUCTION TO MICROSERVICES

6. WHY MICROSERVICES?
• Enables continuous delivery
• Highly maintainable services
• Efficient developer workflow
• Robust by design
• Flexible scalability

7. WHY NOT?
• Distributed systems are hard
• 100s or more services
➢Complex production environment
➢Lots of deployments
• Refactoring across services is cumbersome

8. THE 6 CHARACTERISTICS
A microservice
1. Is responsible for a single capability.
2. Is individually deployable.
3. Consists of one or more processes.
4. Owns its own data store.
5. A small team can maintain a handful of microservices.
6. Is replaceable.

9. RESPONSIBLE FOR A SINGLE CAPABILITY
“Gather together the things that change for the same reasons.
Separate those things that change for different reasons.”
Uncle Bob, The Single Responsible Principle

10. INDIVIDUALLY DEPLOYABLE
SpecialOffersService
LoyaltyProgramService
NotificationService
InvoiceService
PricingService
NotificationService

11. ONE OR MORE PROCESSES
SpecialOffersService
LoyaltyProgramService
NotificationService
InvoiceService
PricingService

12. OWNS ITS OWN DATA STORE
SpecialOffersService
LoyaltyProgramService

13. OWNS ITS OWN DATA STORE
SpecialOffersService
LoyaltyProgramService

14. A SMALL TEAM CAN MAINTAIN A
HANDFUL OF MICROSERVICES.

15. REPLACEABLE

16. SCOPING MICROSERVICES

17. THE 6 CHARACTERISTICS
A microservice
1. Is responsible for a single capability.
2. Is individually deployable.
3. Consists of one or more processes.
4. Owns its own data store.
5. A small team can maintain a handful of microservices.
6. Is replaceable.

18. BOUNDED CONTEXT
• Where the language is consistent
• Tends to follow organizational structure

19. BUSINESS CAPABILITY
• A thing the business does
• Exists within one bounded context
• A bounded context spans several business capabilities

20. FIRST SCOPING RULE
The primary driver for scoping
microservices is business capabilities
A microservice is responsible for a
single business capability

21. EXAMPLE: BOUNDED CONTEXTS

22. EXAMPLE: LOYALTY PROGRAM CAPABILITIES
• Issue cards
• Cancel cards
• Award points
• Raffle
• Track eligibility for special offers
• Special events

23. Loyalty cards
microservice
Loyalty points
microservice
Raffle microservice
Eligibility
microservice
Special Events
microservice
Loyalty Program Bounded Context

24. SECOND SCOPING RULE
The secondary driver for scoping
microservices is technical capabilities
A microservice is responsible for a
single technical capability

25. EXAMPLE

26. EXAMPLE

27. EXAMPLE

28. THRID SCOPING RULE
The tertiary driver for scoping microservices
is effieciency of work
A microservice scope must respect
Conways law

29. Conway’s Law
Any organization that designs a system (defined broadly)
will produce a design whose structure is a copy of the
organization's communication structure.

30. DEPENDENCY CHAINS
• Services
• And organization

31. VALUE STREAM MAPPING FOR CODERS

32. THRID SCOPING RULE
The tertiary driver for scoping microservices
is effieciency of work
A microservice scope must respect
Conways law

33. SCOPING RULE
A microservice is responsible
for a single capability

34. When in doubt error on the
side of larger microservices

35. WHAT ABOUT WHEN IT GOES WRONG?
• Merge
• or split
• It’s an evolution

36. DRIVERS FOR MERGING
• Coordinated deploys
• Cross services refactoring
• Chatty interface

37. DRIVERS FOR SPLITTING
• Changes apply only to part of the capability
• Big, slow, cumbersome

38. HOW TO SPLIT
• Identify sub-capabilities
• Isolate
• Define interface
• Split data
• Split code

39. HOW TO SPLIT

40. SUMMARY
• Scope to business capability
• Scope to technical capability
• Scope for efficiency of work

41. ABOUT ME
Christian Horsdal Gammelgaard
Independent Consultant
www.horsdal-consult.dk
c.horsdal@gmail.com
@chr_horsdal