soa lessons learnt - codemotion tel aviv 20170330
TRANSCRIPT
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
@farmar3
So I went to my master…
4
Solve the problem you want?mmmm…
Coupling your problem is…
@farmar
5 @farmar
6
Coupling Dimensions
Afferent (Ca)
Efferent (Ce)
What depends on you
What you depend on
@farmar
7
Coupling DimensionsTemporal
Time, synchronous communication, logical temporal
couplingSpatial
Physical, deployment, endpoint address
Platform Protocols, platform specific
features @farmar
8
Durability, Scalability, Maintainability
var svc = new MyService();
var result = svc.Process(data);
@farmar
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)
@farmar
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)
@farmar
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
/
@farmar
@farmar12
Why Microservices?Break down the monolith
13
Monolith
UI
BL
DAL
DB
Tight CouplingLoose Coupling
@farmar
14
Vertical Slicing
UI
BL
DAL
DB Referential Integrity
Tight CouplingLoose Coupling
Re-introduces Coupling
SalesConte
ntCRMOps
@farmar
15
Why SOA?
“Address coupling in our software design by building loosely coupled and highly encapsulated components”
Udi Dahan
@farmar
16
Process
It’s hard (er)No silver bullet: use messaging only
if it suitesDecomposing your business domain
is hard, no framework/tools will magically fix that
@farmar
17
Decomposition
AutonomyDecompose business entities
by properties/fieldsBounded context == high coupling
@farmar
18
Design
Be pragmatic but keep the paradigmRight size?
Logical “Service” /= Physical Process
@farmar
19
Communication
Asynchronous fire and forget, Pub/Sub
Synchronous communications for reads
Use massaging where is works
@farmar
20
Software Architecture
Don’t generalise, be explicit SRP (Single Responsibility Principle)Keep your vertical slice thin, top to
bottom
@farmar
21
Data
Referential integrity and GUIDSSeparating data writes and data
reads (CQS)Data (write) ownership
@farmar
22
Data
Data reads and eventual consistencyDon’t share your transactional data
(OLTP)You can share your view models
@farmar
23
DevOps
Monitoring - Lights onTesting is HARD
Deployment - Automate everything
@farmar
24
Organisation
Get organization and people buy in Build trust with the business
Build your business not a system
@farmar
25
Summary
Avoid all dimensions of couplingAvoid synchronous communication
between components/microservices, Don't share data, use view/read models to share read only data
Just do it, NServiceBus
@farmar
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
@farmar
27
Thank You!
Sean Farmar
Particular.net
@farmar