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