Microservices Best Practices
12 Factor apps
Tldr
Suivre les 12 Factor Apps garantit une bonne tenue à l'exploitation des microservices dans un cloud (containers + orchestrateur). Une app 12 factor peut:
- être facilement scalée
- être recréée from scratch et stoppée
- être exploitée sur le cloud
voir 12factor.net
- codebase: une seule codebase versionnée (pas de codebase différente par environnement)
- dependencies: les dépendances doivent être déclarées explicitements et isolées
- config: store config in the env definition
- backing services:
- backing services = other microservices, databases, third party services
- treat all as "attached resources", can switch easily.
- no distinction between first or third party resources
- build/run/release: are separate stages!
- build (env independent package)
- release (env dependent package)
- run (create and run container)
- processes: one or more stateless processes, can store state in central data store (redis=
- port binding: l'app est complètement self-contained et expose juste ses ports
- concurrency: une application = un ou plusieurs process
- first class concept in 12 factor apps
- ex: long-running process for workers, http process etc
- the app should support horizontal scaling (more application instance)
- the app should only rely on the OS (no PID manipulation, no homemade daemonization)
- disposability: the app should be able to shutdown gracefully without affecting other microservices
- terminate on
SIGTERM
- terminate on
- dev/prod parity: tous les environnements doivent être le plus possible similaire les uns aux autres, y compris dans les backing services
- logs: logs are event streams, and should be centralized
- logs to
stdout
- no logfile writing / homemade rotate etc!
- logs to
- admin processes:
- admin processes = database migration, console debug, one time scripts
- they are versioned and use the same env parity and tools
Collaboration between microservices
- REST: cool mais synchrone
- Event messaging: asynchrone mais deserialization, routage, transactions et retry à gérer.
Découper
- Single responsibility principle: cool mais donne des services trop petits
- Single source of truth: le microservice est seule source de vérité pour son domaine. la data peut etre ensuite utilisée par d'autres services.
- Autonomy: critère plus important pour découper. Peut-on déployer séparément ce truc?
- Conways Law: plus l'équipe est découpée, plus les microservices peuvent etre petits
Merger
- Trop de couplage entre services: si deux services s'appellent les uns les autres + référencent les mêmes tables, alors il faut peut etre les merger...
Enablers
Pas de microservice si on n'a pas :
- devops: la flexibilité des microservices nécessite du déploiement / évaluation / collaboration constante entre équipes
- monitoring: