Service Oriented Architecture has been around for a while, now Microservices is the new black, that’s cool, but can we learn from when we failed and succeeded implementing SOA? There are some really useful lessons we can take and avoid the pitfalls.

1. SOA Lessons Learnt
(or Microservices Done Better)
Sean Farmar
Particular Software
@farmar1

2. Tried all “Best Practices”
Layers and Tiers
Distributed monoliths using Web Services
and failed ...
@farmar
My journey to SOA
2

3. So I went to my
master…
@farmar3

4. Solve the problem you want?
mmmm…
Coupling your problem is…
@farmar4

5. @farmar5

6. Coupling Dimensions
Afferent (Ca)
Efferent (Ce)
What depends on you
What you depend on
@farmar6

7. Coupling Dimensions
Temporal
Time, synchronous communication,
logical temporal coupling
Spatial
Physical, deployment, endpoint
address
Platform
Protocols, platform specific features
@farmar7

8. Durability, Scalability, Maintainability
var svc = new MyService();
var result = svc.Process(data);
@farmar8

9. Fallacies of Distributed Computing
1. The network is reliable. (Bill Joy and Tom Lyon)
2. Latency is zero. (Bill Joy and Tom Lyon)
3. Bandwidth is infinite. (Bill Joy and Tom Lyon)
4. The network is secure. (Bill Joy and Tom Lyon)
@farmar9

10. Fallacies of Distributed Computing
5. Topology doesn’t change. (Peter Deutsch)
6. There is one administrator. (Peter Deutsch)
7. Transport cost is zero. (Peter Deutsch)
8. The network is homogeneous. (James
Gosling)
@farmar10

11. Fallacies of Distributed Computing
Fallacies ebook(David Boike):
http://go.particular.net/CMTA17
Ted Neward’s blog:
http://blogs.tedneward.com/post/enterprise
-computing-fallacies/
@farmar11

12. Why Microservices?
Break down the monolith
@farmar12

13. Monolith
UI
BL
DAL
DB
Tight Coupling
Loose Coupling
@farmar13

14. Vertical Slicing
UI
BL
DAL
DB Referential Integrity
Tight Coupling
Loose Coupling
Re-introduces Coupling
Sales
Conten
t
CRMOps
@farmar14

15. Why SOA?
“Address coupling in our software
design by building loosely coupled and
highly encapsulated components”
Udi Dahan
@farmar15

16. Process
It’s hard (er)
No silver bullet: use messaging only if it
suites
Decomposing your business domain is
hard, no framework/tools will magically fix
that
@farmar16

17. Decomposition
Autonomy
Decompose business entities
by properties/fields
Bounded context == high coupling
@farmar17

18. Design
Be pragmatic but keep the paradigm
Right size?
Logical “Service” /= Physical Process
@farmar18

19. Communication
Asynchronous fire and forget, Pub/Sub
Synchronous communications for reads
Use massaging where is works
@farmar19

20. Software Architecture
Don’t generalise, be explicit
SRP (Single Responsibility Principle)
Keep your vertical slice thin, top to bottom
@farmar20

21. Data
Referential integrity and GUIDS
Separating data writes and data reads
(CQS)
Data (write) ownership
@farmar21

22. Data
Data reads and eventual consistency
Don’t share your transactional data
(OLTP)
You can share your view models
@farmar22

23. DevOps
Monitoring - Lights on
Testing is HARD
Deployment - Automate everything
@farmar23

24. Organisation
Get organization and people buy in
Build trust with the business
Build your business not a system
@farmar24

25. Summary
Avoid all dimensions of coupling
Avoid synchronous communication
between components/microservices,
Don't share data, use view/read models to
share read only data
Just do it, NServiceBus
@farmar25

26. Q&A
Blog post:
http://particular.net/blog/goodbye-
microservices-hello-right-sized-services
Fallacies EBook:
http://go.particular.net/CMTA17
NServiceBus:
http://particular.net
@farmar26

27. Thank You!
Sean Farmar
Particular.net
@farmar27