Aller au contenu

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

  1. codebase: une seule codebase versionnée (pas de codebase différente par environnement)
  2. dependencies: les dépendances doivent être déclarées explicitements et isolées
  3. config: store config in the env definition
  4. 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
  5. build/run/release: are separate stages!
    • build (env independent package)
    • release (env dependent package)
    • run (create and run container)
  6. processes: one or more stateless processes, can store state in central data store (redis=
  7. port binding: l'app est complètement self-contained et expose juste ses ports
  8. 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)
  9. disposability: the app should be able to shutdown gracefully without affecting other microservices
    • terminate on SIGTERM
  10. dev/prod parity: tous les environnements doivent être le plus possible similaire les uns aux autres, y compris dans les backing services
  11. logs: logs are event streams, and should be centralized
    • logs to stdout
    • no logfile writing / homemade rotate etc!
  12. 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: