Le monolithe
Abréviations 🖍️: µS = Microservices S = Service
facile à debug et à remonter en local (si bien fait), le soucis est l’ajout de features. En soit un monolithe est bon pour démarrer un projet car simple
Les =/= variantes des monolithes veillent à respecter les principes SOLID
Layers des DP
les design pattern du cloud appartiennent à =/= layers comme les design pattern logiciels
Application layer
Problèmes adressés aux développeurs tel que la data la data maintenance, les tests…
- Decomposition: Comment décomposer son app en µS, par ex décomposition par (sous) domaine métier, le self contained service: comment faire si SA → SB → SC? ne pas attendre que tout soit fini: redonner la main à l’user et faire le reste en async
- Data Management: consistence de données etc.. ex api composition, CQRS, Database per service, saga, 2PC
Application-infrastructure
Changement structurels qui impactent le code
- Communications
- Observabilité
- Reliability: Circuit breaker on let en place un service fusible qui va s’ouvrir/fermer pour éviter à toute l’archi de s’écrouler le temps que les service qui ont fail redémarrent.
- Sécurité
Infrastructure
Changement structurels qui n’impactent pas le code
- Service Registry
Cube du scale
https://cinish.medium.com/microservices-architecture-5da90504f92a
