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
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
19. Difficultés
Mise en place d’un mécanisme
inter-services.
Problème de transaction distribuées
Complexité des tests
...
... ...
...
...
...
...
......
...
...
...
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
(+) (-)
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
... ... ... ... ... ...
... ... ... ... ... ...
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