Votre application monolithique vous fait un peu honte, à l'heure où tout le monde semble résoudre ses problèmes à coups de microservices. Mais savez-vous qu'ils entraînent un grand nombre de challenges, aussi bien techniques qu'organisationnels, souvent découverts sur le tard et dans la douleur ?
Après plus d'un an passé à développer des microservices pour un Pure Player à très fort trafic, je viens partager la check-list qui me semble indispensable avant de se lancer dans l'aventure.
9. Linkvalue | Jean-Marie Lamodière
WHY AUTONOMY MATTERS?
Loosely coupled organisation
= less coupled systems
Quality audit on windows vista :
organizational structures
= most important factor!
Team accountability
9
10. Linkvalue | Jean-Marie Lamodière
OTHER KEY BENEFITS
Easier for newcomers
Allows isolated POC
Teams scalability
Simpler code design
Easy refactoring
10
14. Linkvalue | Jean-Marie Lamodière
TESTIMONY
(45' talks published on )
« We had to fall back to a monolith,
and retry when ready » – SAMUEL ROZE
PHP Tour 2016 • Prenons soin de nos microservices
« I wish I had known... » – MATT RANNEY
GOTO 2016 • What I Wish I Had Known
Before Scaling Uber to 1000 Services
14
16. Linkvalue | Jean-Marie Lamodière
WHAT IS SO COMPLEX ?
Boundaries : hard to find / change
Huuuge dev-ops stack
Distributed system
Failure handling
Monitoring
End-to-end testing
16
18. Linkvalue | Jean-Marie Lamodière
BOUNDARIES : WHERE TO SPLIT?
Splitting = hard to change
Size ? Small enough, not smaller
Splitting by technical layers? no!
Things that should change together
(« S » in S.O.L.I.D.)
Loose coupling, high cohesion
18
19. Linkvalue | Jean-Marie Lamodière
DDD* TO THE RESCUE!
(* Domain Driven Design)
Toolset to help domain experts
and developers to refine and
share domain knowledge, reflect it in
the code base, and prioritize efforts.
19
20. Linkvalue | Jean-Marie Lamodière
MAKE THE IMPLICIT, EXPLICIT!
20
Copyright @DDDreboot ;)
21. Linkvalue | Jean-Marie Lamodière
SPLIT BY BOUNDED CONTEXT
Bounded context = Team sharing
the same « ubiquitous language »
(same terms)
Vertical, business-focus slice
21
22. Linkvalue | Jean-Marie Lamodière
WHEN TO SPLIT ?
When ready : technical stack chosen,
architectural decisions taken,
devs and ops willing to go,
autonomous 2 pizza feature teams
When sure of a splitting point
Start with a monolith (!) to find them
22
23. Linkvalue | Jean-Marie Lamodière
CONWAY'S LAW
« Organizations which design systems
are constrained to produce designs
which are copies of the communication
structures of these organizations »
23
25. Linkvalue | Jean-Marie Lamodière
SPLITTING STRATEGY
Implement double-writing
(microservice or legacy side)
Publish needed messages
One-shot data import script
Assert data is sync
Read from microservice
25
26. Linkvalue | Jean-Marie Lamodière
COMMUNICATION BETWEEN µS
No shared database!
Language agnostic (ex : rest / json)
If weakly typed (json), have a clear doc
(optional? nullable?) or json-schema
Keep consistency. ex : pagination
Define minimal customer-centric api
26
29. Linkvalue | Jean-Marie Lamodière
SYNCHRONOUS COMMUNICATION
- PROS -
Easier to understand
(= method call)
Easier transition from monolith
Instant feedback to the client
29
30. Linkvalue | Jean-Marie Lamodière
SYNCHRONOUS COMMUNICATION
3030
User
Optin
Other service
depending on
1 optin
Register
Register
french user
Read 1 optin
Read
31. Linkvalue | Jean-Marie Lamodière
SYNCHRONOUS COMMUNICATION
- CONS -
Fanout : 1% slow calls more
probable when cascading calls
Beware of coupling !
Beware of distributed monolith !!
31
33. Linkvalue | Jean-Marie Lamodière
ASYNCHRONOUS COMMUNICATION
Message broker
Reactive : event driven
Choregraphy over orchestration
Autonomy over authority :
each service copy the data it needs
Work well with CQRS / ES
33
34. Linkvalue | Jean-Marie Lamodière
ASYNCHRONOUS COMMUNICATION
34
Message brokerMessage broker
Message brokerMessage broker
User French user registered
Optin User optins changed
Other service
depending on
1 optin
Register
Read
35. Linkvalue | Jean-Marie Lamodière
COMMUNICATION TRAPS
Chatty communication = coupling
feature envy, wrong splitting…
Perf overhead : define « acceptable »
35
37. Linkvalue | Jean-Marie Lamodière
DESIGN FOR FAILURE
It will fail, have a plan!
Define what to do, to return
Define timeout for each call
Message hospital (dead letter queue)
Circuit breaker / back pressure
Blameless culture needed
37
38. Linkvalue | Jean-Marie Lamodière
NETFLIX CHAOS MONKEY
Randomly shut
down services
Cure developers
optimism ;)
38
39. Linkvalue | Jean-Marie Lamodière
SERVICE DISCOVERY
Each µs scales individualy : which
IP should we call ?
DNS in front of a load-balancer
Kubernetes services
Docker Swarm discovery
(libkv + consul/etcd/zookeeper)
39
40. Linkvalue | Jean-Marie Lamodière
CAP THEOREM
(Distributed Systems)
Choose 2 between consistency (C),
availability (A) and partition (P)
Avoid distributed transactions
Embrase eventual consistency
Use idempotent operations
Worker to clean inconsistency
40
42. Linkvalue | Jean-Marie Lamodière
MICROSERVICES CLIENTS
Libraries ok, 1 per language needed
No business logic in client :
avoid anemic CRUD microservices
To call a complex api (legacy,
external), build a facade service
42
43. Linkvalue | Jean-Marie Lamodière
CHANGE PROOF CLIENTS
Old and new api should cohexist
Postel's law : « be conservative in
what you do, be liberal in what you
accept from others »
Tolerant reader (Martin Fowler) :
ignore changes not impacting you
43
45. Linkvalue | Jean-Marie Lamodière
API GATEWAY
Avoid exposing µs to frontend
Hide spliting to new microservices
Handle authentication / roles
Pro-tips : Back-end for frontend,
1 gateway per front application
45
46. Linkvalue | Jean-Marie Lamodière
API GATEWAY
46
Microservice
Legacy
Monolith
Microservice Microservice
Android
API Gateway
Android
application
Public
Private
ReactJS
Web application
ReactJS
API Gateway
48. Linkvalue | Jean-Marie Lamodière
TESTING A MICROSERVICE
No end-to-end testing at µs level
Stub/mock others µs in functional tests
Have consumer-driven tests
No continuous integration = no µs!
One c.i. pipeline per microservice
48
49. Linkvalue | Jean-Marie Lamodière
END TO END TESTING
Test journeys (main features),
not user stories (already tested)
Goal : check wiring
Should be done in each front app
Can run in production
49
50. Linkvalue | Jean-Marie Lamodière
TESTING = TRUST
50
Involve a quality assurance member
in your feature team
51. Linkvalue | Jean-Marie Lamodière
ARCHITECT ROLE
Keep µs map up to date
Define communication between µs
Define automatic deploying,
monitoring and logging strategy
Adapt to change, like a city planner
Enforce team autonomy inside a µs
51
53. Linkvalue | Jean-Marie Lamodière
WHAT SHOULD µS KEEP COMMON ?
Rules : communication, logs...
Template to create new µs,
but no synchronization afterward
Violate DRY accross µs !
Shared code = coupling
Priority : autonomy
53
54. Linkvalue | Jean-Marie Lamodière
MONITORING / LOGGING TIPS
Pass a unique « correlation id »
to each sub-calls, including
messages and asynchronous calls
Make sure your APM supports
each language + versions
Have a look at Sysdig.org
54
56. Linkvalue | Jean-Marie Lamodière
BEFORE YOU START
microservices.io
martinfowler.com
/microservices/
/articles/microservices.html
/articles/microservice-trade-offs.html
groups.google.com
/forum/#!forum/microservices
56
57. Linkvalue | Jean-Marie Lamodière
ASYNCHRONOUS COMMUNICATION
blog.christianposta.com
Why Microservices Should Be
Event Driven:Autonomy vs Authority
reactivemanifesto.org
57
Lightbend.com (free)
58. Linkvalue | Jean-Marie Lamodière
TALKS
What I Wish I Had Known Before
Scaling Uber to 1000 Services
GOTO 2016 • Matt Ranney
Prenons soin de nos microservices
PHP Tour 2016 • SAMUEL ROZE
Meetic backend mutation with Symfony
SymfonyLive 2015 • J. Calabrese E. Broutin
Kafka event architecture at Meetic
Forum PHP 2015 • B. Pineau M. Robin
58
