Le document présente un retour d'expérience sur l'architecture microservice chez Botsunit, détaillant les promesses et défis rencontrés lors de l'implémentation. Il souligne les avantages comme la tolérance aux pannes et le déploiement indépendant des services, tout en mentionnant les difficultés liées à la gestion des bases de données et à la complexité des tests. Enfin, il expose des conseils pour réussir dans la transition vers l'architecture microservice.

1. Retour d’expérience
Architecture MicroService chez BotsUnit
Grégoire Lejeune - Developper & Architect
Mikael Robert - Devops & Infrastructure Architect

2. Plan
I Le microservice c’est quoi ?
II Promesses et difficultés
III Notre histoire avec le microservice
IV Retour d’expérience

3. I - Le microservice ?

4. L’âge de pierre
monolithe SQL

5. L’âge de cuivre
monolithe SQL

6. L’âge de bronze
composant
composant
composant
composant
composant
composant
composant

7. L’age de fer
service
service
service
service
service
service
service

8. La littérature
approach to developing a single
application as a suite of small services,
each running in its own process and
communicating with lightweight
mechanisms, often an HTTP resource
API. These services are built around
business capabilities and
independently deployable by fully
automated deployment machinery.
There is a bare minimum of centralized
management of these services, which
may be written in different
programming languages and use
different data storage technologies.
-- Fowler & Lewis
user identity billing
shopmail
shop Store
API

9. II - Promesses et difficultés

10. Isolation /
Interdépendance
monolithe
Bank
User
Shop

11. Isolation /
Interdépendance
Changer un élément implique de le
changer partout, de revoir les tests
partout et de redéployer l’ensemble.
monolithe
Bank
User
Shop

12. Isolation /
Interdépendance
Changer un élément implique de le
changer à un seul endroit, de modifier
les tests à un seul endroit et de ne
redéployer que le MS modifié.
Shop
Bank
User
Table

13. Scalabilité
Que ce qui est nécessaire
...
billing
...
...
shop
...
...
billing
shop
shop
Store
Store
Store
Store
Store
Store
Store
2 core
4 GB
2 core
4 GB
2 core
4 GB
4 core
8 GB
4 core
8 GB

14. Scalabilité
Tout ou rien monolithe
monolithe
monolithe SQL
8 core
32 GB
8 core
32 GB
8 core
32 GB
8 core
128 GB

15. Défaillance
L’ensemble est compromis
monolithe SQL

16. Défaillance
Seul un élément est compromis.
Design for failure
...
...
...
...
...
...
...
Store
Store
Store
Store
Store
Store
Store

17. Défaillance
Seul un élément est compromis.
Design for failure
...
...
...
...
...
...
...
Store
Store
Store
Store
Store
Store
Store

18. Polyglotte
User
Bank
Chat
Front

19. Difficultés
Mise en place d’un mécanisme
inter-services.
Problème de transaction distribuées
Complexité des tests
...
... ...
...
...
...
...
......
...
...
...

20. Difficultés
Développement d’un Framework
autour de Kafka (Event based).
Message ∈ Transaction
Kafka
... ... ... ... ... ...
... ... ... ... ... ...

21. Difficultés
Déploiement
Utilisation des ressources physiques
.erl
.ex ...
Store
...
1
4
3
Kafka
2

22. So...
● Scaling Micro et non Macro
● Découpage
● Multi Langage / Polyglotte
● Un MS = Une micro équipe
● Eviter perte de contrôle du monolithe
● Tirer parti des avantages des différents
hébergeurs
● Dizaines d’applications
○ Déploiement
○ Release management
● Énormément de machines à gérer
● REST/HTTP vs BUS
● Front
● Transactionnel
● Déporter la charge sur le réseau
(+) (-)

23. III Notre histoire

24. Une startup
Fintech
1) Monolithe
HTML
JS
CSS
Rails
Store
Monolithe

25. Une startup
Fintech
1) Monolithe
2) SOA
HTML
JS
CSS
Rails
Store
Monolithe
API
Front
HTML
JS
CSS
Rails
Store

26. Une startup
Fintech
1) Monolithe
2) SOA
3) MicroServices
HTML
JS
CSS
Rails
Store
Monolithe
Store
API
Front
HTML
JS
CSS
Rails
Kafka
API
Front
Mail Gen File Virement
ErlangErlangErlang
Store

27. Notre propre Startup
● Convaincus par le MS suite au REX
On monte notre boîte !
● Le Projet initial :
○ Plateforme à la Heroku mais orienté
MicroServices
○ Framework microservices / kafka
○ Infra / DB / Middlewares on Demand
Objectifs initiaux
● Très haute volumétrie (plusieurs M / jours)
● Prouver notre capacité à encaisser
● Tolérance à la panne, auto-guérison
● Coûts raisonnables pour ces objectifs

28. Equipe
● Un investisseur / Directeur commercial.
● Un architecte d’applications Web de plus de 10 ans XP (MS et Streaming)
● Un CTO, 10 ans d’Erlang, Outils Cloud (Vidal, eNovance, Fintech).
● Un architecte d’infrastructure / devops, 8 ans XP (OCTO Technology,
Startup Fintech)
Erlang Elixir GCE Consul ChefDockerKafka

29. Expérimenter la plateforme
Démarrer : framework kafka + infra on demand avec des MS “tests”
Conclusion rapide : On ne prouvait pas vraiment prouver notre efficacité avec
des cas d’école, il fallait développer la plateforme avec un vrai projet
Besoin : Prouver nos idées et la pertinence de nos outils
Idée :
Plateforme de streaming vidéo live/chat intéractive

30. Principes de bases
● Framework Kafka, protocole et format de message commun
● Event based
● Duplication de donnée en local (cache) pour éviter de ré-appeler
Kafka
User Payment ChatStore Store
From: User
Payer : 1000
Recipient : 1001
Amount: 10
From: Payment
Payer : 1000
Recipient : 1001
Amount: 10
Tip
Notify

31. Le premier micro service … le front
Kafka
...
Store
front
Store
StandBy
front
API API

32. Puis un deuxième : User
Kafka
... ...
Store
user
Store
StandBy
user
API API

33. Puis un troisième : Identity
Kafka
... ...
Store
identity
Store
StandBy
Identity
API API
...

34. Puis on en a rapidement 8, 10, 12 ... :
front, user, identity, payment, broadcast, chat, realtime, shop..
Kafka
... ... ... ... ... ...
... ... ... ... ... ...

35. Notre retour d’expérience
Douleurs & solutions

36. Aujourd’hui : nos avantages
● Le produit fonctionne bien, il est prêt à être lancé :)
● Tolérance à la panne : Quand un service plante, on ne perd pas tout le site
● Mise à jour service par service (voir aussi le point précédent)
● Asynchrone - traitement de masse
● Scaling des composants indépendant
● Optimisation indépendante : en optimisant un service, on ne risque pas
d’effets de bords sur un autre
● On pourrait sous traiter le développement de micro services

37. Aujourd’hui : nos douleurs
1. Trop de machines
a. Cela coûte cher ...
b. Même notre prototype opérationnel Kubernetes en souffre, difficile à stabiliser
2. Trop de bases de données
a. Extrêmement difficile en exploitation
b. Consistance difficile à assurer
3. Des microservices devenu des mini monolithes
4. Deux sources de vérité pour les données : Kafka et les BDD
5. Le front est devenu un plat de spaghettis

38. 1. Trop de machines
● Plus simple de debugger dans une VM que dans un container
● Etape 1 : Travail pour réduire la consommation en idle (polling kafka et BDDs)
● Etape 1.5 : Optimisation qui n’ont pas pu être faites à cause de la pression des
features
● Etape 2 : Diminuer le nombre de serveurs de base de données
● Etape 3 : Tout mettre dans Kubernetes

39. 2. Trop de base de données
● Golden Hammer : on sait faire avec Postgres on met Postgres partout
○ Très loin d’être adapté à tous les cas
○ Scale mal
● Pistes étudiées actuellement :
○ 1 cluster Postgres, 1 cluster Redis et 1 cluster Cassandra, le tout en commun
○ Bascule vers Redis plein de data qui sont uniquement temporaires ou du cache
○ Passer de N bases à M bases (mutualiser certaines bases entre des microservices)

40. 3. Des microservices devenu des mini
monolithes
Payment
Encheres
Tipping
Achat
Ventes
Enchères Tipping
VentesAchats

41. 4. Deux sources de vérités pour les données
● Les données arrivent par Kafka, mais sont aussi stockées en base.
○ Qui a raison en cas de conflit? De duplicata ?
● Très conflictuel quand on a un soucis, on ne sait jamais trop quelle source
prendre
● Kafka pour la reprise sur erreur
○ Parfaitement adapté
● Le cluster cassandra commun pourrait être une solution
○ Scalable
○ Haute performance

42. 5. Le front plat de spaghettis
● Front V2, refonte complète
○ On voudrait faire une SPA, mais toujours problème de SEO
○ Mettre le CSS et le JS dans un seul microservice et pas dans tous, partie par partie évitera pas
mal de soucis et permettra la réutilisation
● Avantages :
○ On ne multiplie plus les endroits pour modifier le front
● Inconvénients :
○ On risque de devoir mettre à jour ce service chaque fois qu’un autre évolue

43. Monolithe vs Microservices :
Design for Failure : l’architecture idéale (selon nous)
Shop PaymentUserChat
SPA:
HTML
JS
CSS
CDN
SPA:
HTML/CSS/JS

44. Monolithe vs Microservices :
Design for Failure : l’architecture idéale (selon nous)
Shop PaymentUserChat
SPA:
HTML
JS
CSS
CDN
SPA:
HTML/CSS/JS

45. Nos conseils
● Evitez de courir deux chevaux à la fois.
○ Équipe d’experts et pattern maîtrisés.
○ R&D
● Pas de pattern leader.
● Faire un choix et s’y tenir.
● Éviter les effets de mode.
Le micro service est sans hésiter l’avenir de l’architecture IT

46. Questions ?
Q & A
gregoire.lejeune@botsunit.com
@glejeune
/glejeune
mikael.robert@botsunit.com
@mikaelrob
/mikrob /botsunit