Votre MVP n'a pas besoin de microservices : guide d'un directeur technique pour choisir une architecture adaptée

Au cours des trois dernières années, nous avons analysé les bases de code de plus de 30 start-ups. La tendance numéro un : une architecture conçue pour 10 millions d'utilisateurs, mais qui n'en dessert que 500.

Une start-up qui n'a pas encore généré de revenus, disposant d'un cluster Kubernetes, de 12 microservices, d'une file d'attente de messages, d'un maillage de services et d'une facture d'infrastructure de 3 000 $ par mois. Son concurrent ? Une application monolithique Django hébergée sur un serveur à 50 $ par mois, qui déploie ses fonctionnalités quatre fois plus vite.

La surconception ne se contente pas de gaspiller de l'argent. Elle gaspille la seule ressource que les start-ups ne peuvent pas acheter : le temps.

Instagram dessert 300 millions d'utilisateurs grâce à une architecture monolithique Django. Shopify fonctionne sur une architecture monolithique Rails. Stack Overflow accueille 100 millions de visiteurs par mois grâce à une architecture monolithique .NET répartie sur 9 serveurs web.

Une architecture monolithique bien conçue, s'appuyant sur PostgreSQL et Redis, est capable de gérer un trafic bien supérieur à celui que 99 % des start-ups ne connaîtront jamais. Le goulot d'étranglement ne réside pas dans votre architecture, mais dans vos requêtes de base de données, vos problèmes N+1 et l'absence d'une couche de mise en cache.

Ne séparez un service que lorsque vous en ressentez le besoin, pas avant :

1. Les difficultés liées à la croissance de l'équipe. Si plus de dix développeurs se marchent sur les pieds au sein d'une même base de code, il est judicieux de la scinder en deux ou trois services dont la responsabilité est clairement définie.

2. Couplage au niveau du déploiement. Si le déploiement du système de notification nécessite de déployer l'application dans son intégralité et d'exécuter tous les tests, extrayez les notifications pour en faire un service.

3. Des besoins de mise à l'échelle différents. Si votre traitement d'images nécessite 10 fois plus de puissance de calcul que votre API, le fait de les séparer vous permet de les faire évoluer indépendamment.

4. Des cadences de livraison différentes. Si l'équipe chargée de la facturation effectue des livraisons hebdomadaires tandis que l'équipe chargée du produit principal en effectue quotidiennement, le recours à des services distincts permet à chaque équipe d'avancer à son propre rythme.

Si aucun de ces cas ne s'applique à vous aujourd'hui, vous n'avez pas besoin de microservices. Point final.

Après avoir développé plus de 65 produits, voici ce que nous recommandons par défaut pour un MVP :

Cette pile prend en charge 100 000 utilisateurs par mois, coûte moins de 100 $ par mois et peut être gérée par un seul développeur. Lorsque vous devez évoluer, chaque composant peut être mis à niveau sans réécriture.

Au cours des plus de 50 entretiens de due diligence auxquels nous avons participé, les investisseurs n'ont jamais demandé : « Utilisez-vous des microservices ? » Ils ont plutôt demandé :

1. À quelle vitesse pouvez-vous mettre en place une nouvelle fonctionnalité ? (Vitesse)

2. Que se passe-t-il si votre développeur principal démissionne ? (Facteur de risque lié à une seule personne)

3. L'architecture est-elle capable de supporter une charge 10 fois supérieure à votre charge actuelle ? (Pas 1 000 fois, juste 10 fois)

4. Disposez-vous de tests automatisés et d'un système de CI/CD ? (Qualité)

Une architecture monolithique rigoureusement testée, intégrant des processus de CI/CD, obtient de meilleurs résultats à tous les égards qu'une architecture en microservices insuffisamment testée que seule une personne comprend.