Les microservices, c'est pas automatique ! - Linkvalue Tech

Committed to innovateLINKVALUE

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




PROBLEMS THEY SOLVE

1.Autonomy

2.Autonomy

3.Autonomy

6


PROBLEMS THEY SOLVE

1.Autonomy : deployment

2.Autonomy : langage, framework

3.Autonomy : scalability

7



WHY AUTONOMY MATTERS?

Loosely coupled organisation= less coupled systems

Quality audit on windows vista :organizational structures= most important factor!

Team accountability

9


OTHER KEY BENEFITS

Easier for newcomers

Allows isolated POC

Teams scalability

Simpler code design

Easy refactoring

10


WHO USES IT?

Uber

Netflix

Amazon

Ebay

Sound Cloud

Groupon11

Guilt

Zalando

Spotify

Meetic

M6 Web

Auchan


« Trade-offs » appears 24xin « Building Microservices » book

12



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



WHAT IS SO COMPLEX ?

Boundaries : hard to find / change

Huuuge dev-ops stack

Distributed system

Failure handling

Monitoring

End-to-end testing16



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


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


MAKE THE IMPLICIT, EXPLICIT!

20

Copyright @DDDreboot ;)


SPLIT BY BOUNDED CONTEXT

Bounded context = Team sharingthe same « ubiquitous language »(same terms)

Vertical, business-focus slice

21


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


CONWAY'S LAW

« Organizations which design systemsare constrained to produce designswhich are copies of the communicationstructures of these organizations »

23


2ND LAW OF CONSULTING(Gerald Weinberg)

24


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


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


COMMUNICATION BETWEEN µS

27



SYNCHRONOUS COMMUNICATION- PROS -

Easier to understand(= method call)

Easier transition from monolith

Instant feedback to the client

29


SYNCHRONOUS COMMUNICATION

3030

User

OptinOther servicedepending on

1 optin

Register

Registerfrench user

Read 1 optin

Read


SYNCHRONOUS COMMUNICATION- CONS -

Fanout : 1% slow calls moreprobable when cascading calls

Beware of coupling !

Beware of distributed monolith !!

31

32

« Distributed monolith »@tiffyshindo


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



34

Message brokerMessage broker

Message brokerMessage broker

User French user registered

Optin User optins changed

Other servicedepending on

1 optin

Register

Read


COMMUNICATION TRAPS

Chatty communication = couplingfeature envy, wrong splitting…

Perf overhead : define « acceptable »

35



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


NETFLIX CHAOS MONKEY

Randomly shutdown services

Cure developersoptimism ;)

38


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


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



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


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


CHANGE PROOF CLIENTS

44


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


API GATEWAY

46

Microservice

LegacyMonolith

Microservice Microservice

AndroidAPI Gateway

Androidapplication

Public

Private

ReactJSWeb application

ReactJSAPI Gateway



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


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


TESTING = TRUST

50

Involve a quality assurance memberin your feature team


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



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


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


Extreme Programming

TDD / BDD

S.O.L.I.D.

Loose coupling,high cohesion

DDD

Hexagonal


BEFORE YOU START

microservices.io

martinfowler.com/microservices//articles/microservices.html/articles/microservice-trade-offs.html

groups.google.com/forum/#!forum/microservices

56



blog.christianposta.comWhy Microservices Should BeEvent Driven:Autonomy vs Authority

reactivemanifesto.org

57

Lightbend.com (free)


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


DDD RECOMMENDED BOOKS

59

leanpub.com (free)

Thank you!


Committed to innovate

LINKVALUE JEAN-MARIELAMODIERE

Build microservicessince 07/2015

@JMLamodiere

1935 CP

Software

Les microservices, c'est pas automatique ! - Linkvalue Tech