Les microservices, c'est pas automatique ! - Linkvalue Tech
-
Upload
marine-karam -
Category
Software
-
view
295 -
download
0
Transcript of Les microservices, c'est pas automatique ! - Linkvalue Tech
JEAN-MARIELAMODIERE
Build microservicessince 07/2015
@JMLamodiere
LES MICROSERVICES,C'EST PAS AUTOMATIQUE !
Linkvalue | Jean-Marie Lamodière2
Microservices? Think twice!
1935 CP
Linkvalue | Jean-Marie Lamodière
ASHAMED OF YOUR MONOLITH?
Spaghetti code
Side effects
Team velocity decreasing
Hard to refactor
Bugs
3
Linkvalue | Jean-Marie Lamodière
PROBLEMS THEY SOLVE
1.Autonomy : deployment
2.Autonomy : langage, framework
3.Autonomy : scalability
7
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
Linkvalue | Jean-Marie Lamodière
OTHER KEY BENEFITS
Easier for newcomers
Allows isolated POC
Teams scalability
Simpler code design
Easy refactoring
10
Linkvalue | Jean-Marie Lamodière
WHO USES IT?
Uber
Netflix
Amazon
Ebay
Sound Cloud
Groupon11
Guilt
Zalando
Spotify
Meetic
M6 Web
Auchan
Linkvalue | Jean-Marie Lamodière
TESTIMONY(45' talks published on )
« We had to fall back to a monolith, and retry when ready » – SAMUEL ROZEPHP Tour 2016 • Prenons soin de nos microservices
« I wish I had known... » – MATT RANNEYGOTO 2016 • What I Wish I Had KnownBefore Scaling Uber to 1000 Services
14
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 testing16
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
Linkvalue | Jean-Marie Lamodière
DDD* TO THE RESCUE!(* Domain Driven Design)
Toolset to help domain expertsand developers to refine andshare domain knowledge, reflect it inthe code base, and prioritize efforts.
19
Linkvalue | Jean-Marie Lamodière
SPLIT BY BOUNDED CONTEXT
Bounded context = Team sharingthe same « ubiquitous language »(same terms)
Vertical, business-focus slice
21
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
Linkvalue | Jean-Marie Lamodière
CONWAY'S LAW
« Organizations which design systemsare constrained to produce designswhich are copies of the communicationstructures of these organizations »
23
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
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 api26
Linkvalue | Jean-Marie Lamodière
SYNCHRONOUS COMMUNICATION- PROS -
Easier to understand(= method call)
Easier transition from monolith
Instant feedback to the client
29
Linkvalue | Jean-Marie Lamodière
SYNCHRONOUS COMMUNICATION
3030
User
OptinOther servicedepending on
1 optin
Register
Registerfrench user
Read 1 optin
Read
Linkvalue | Jean-Marie Lamodière
SYNCHRONOUS COMMUNICATION- CONS -
Fanout : 1% slow calls moreprobable when cascading calls
Beware of coupling !
Beware of distributed monolith !!
31
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 / ES33
Linkvalue | Jean-Marie Lamodière
ASYNCHRONOUS COMMUNICATION
34
Message brokerMessage broker
Message brokerMessage broker
User French user registered
Optin User optins changed
Other servicedepending on
1 optin
Register
Read
Linkvalue | Jean-Marie Lamodière
COMMUNICATION TRAPS
Chatty communication = couplingfeature envy, wrong splitting…
Perf overhead : define « acceptable »
35
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 needed37
Linkvalue | Jean-Marie Lamodière
NETFLIX CHAOS MONKEY
Randomly shutdown services
Cure developersoptimism ;)
38
Linkvalue | Jean-Marie Lamodière
SERVICE DISCOVERY
Each µs scales individualy : whichIP should we call ?
DNS in front of a load-balancer
Kubernetes services
Docker Swarm discovery(libkv + consul/etcd/zookeeper)
39
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 inconsistency40
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
Linkvalue | Jean-Marie Lamodière
CHANGE PROOF CLIENTS
Old and new api should cohexist
Postel's law : « be conservative inwhat you do, be liberal in what youaccept from others »
Tolerant reader (Martin Fowler) :ignore changes not impacting you
43
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
Linkvalue | Jean-Marie Lamodière
API GATEWAY
46
Microservice
LegacyMonolith
Microservice Microservice
AndroidAPI Gateway
Androidapplication
Public
Private
ReactJSWeb application
ReactJSAPI Gateway
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
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
Linkvalue | Jean-Marie Lamodière
TESTING = TRUST
50
Involve a quality assurance memberin your feature team
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 µs51
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 : autonomy53
Linkvalue | Jean-Marie Lamodière
MONITORING / LOGGING TIPS
Pass a unique « correlation id »to each sub-calls, includingmessages and asynchronous calls
Make sure your APM supportseach language + versions
Have a look at Sysdig.org
54
Linkvalue | Jean-Marie Lamodière55
Extreme Programming
TDD / BDD
S.O.L.I.D.
Loose coupling,high cohesion
DDD
Hexagonal
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
Linkvalue | Jean-Marie Lamodière
ASYNCHRONOUS COMMUNICATION
blog.christianposta.comWhy Microservices Should BeEvent Driven:Autonomy vs Authority
reactivemanifesto.org
57
Lightbend.com (free)
Linkvalue | Jean-Marie Lamodière
TALKS What I Wish I Had Known BeforeScaling Uber to 1000 ServicesGOTO 2016 • Matt Ranney
Prenons soin de nos microservicesPHP Tour 2016 • SAMUEL ROZE
Meetic backend mutation with SymfonySymfonyLive 2015 • J. Calabrese E. Broutin
Kafka event architecture at MeeticForum PHP 2015 • B. Pineau M. Robin
58