C’est quoi une App monolithique ?
→ L’ensemble du code serveur dans un projet
→ Toutes les fonctionnalités métiers au même endroit
→ Fortes dépendances entres les données et services
C’est une architecture simple et adaptée au lancement
Inconvénient App monolithique
→ L’appel à l’API de Bob prends tout le stockage restant
La fonctionnalité “modifier profil” se retrouve cassée
→ L’appel à l’API de Bob pour le traitement prends tout le CPU
L’appel d’Alice ne peut pas correctement s’exécuter
→ Dans le meilleur des cas = lags, dans le pire = crashe
L’usage d’une partie de l’app (fonctionnalité) par une personne
entraîne l’indisponibilité totale de l’app (et donc des autres
fonctionnalités !)
Possibilité de scaling ?
→ Augmenter les capacités du serveur // scaling vertical
→ Dupliquer le serveur // scaling horizontal
Répond au problème mais entraîne un surdimensionnement de
notre solution (car les briques utilisateurs + stockage sont aussi
dupliquées mais peu sollicitées)
→ Surutilisation des ressources
→ Découper la solution en micro-services
Le scaling vertical coûte cher, est limité et peu automatisable
Avantage micro service
→ Haute tolérance aux dysfonctionnements
→ Maintenabilité de la solution optimale (plusieurs équipes)
→ Cohabitation de langages et technologies
→ Maîtrise des coûts d’exploitation, ressources adaptées aux
besoins
Inconvénients micro-service
→ Complexité pour la conception
→ Tests
→ Monitoring
→ Coûts de mise en place
→ Mauvaise balance bénéfices-coûts pour les petits projets
Technologie micro-service
Communication inter-services
→ Queue messaging
Centralisation du point d’entrée de l’API
Les messages ne sont jamais perdus
La Queue Messaging attend toujours la confirmation de lecture
Requête HTTP = communication synchrone sans garantie de livraison
Queue messaging = communication asynchrone avec garantie de livraison
→ API Gateway
Répartition de la charge
Redirige les requêtes vers les bons services selon des règles
Permet de centraliser le point d’accès de notre app = de l’extérieur, c’est 1 seule API
→ Load balancer
Déploiement et lancement des services
Répartit la charge sur les réplicats selon des règles
L’extérieur n’a pas à se soucier de connaître les réplicats, ni leur nombre
→ Orchestrateur
Définition Single point of failure
Certaines briques de notre architecture doivent impérativement fonctionner pour que
le tout fonctionne
Attention aux SPOF (Single point of failure) ⚠
→ bien les identifier et les documenter
→ utiliser des standards, sur des machines robustes
→ préparer un DRP (Disaster plan recovery
