Microservices : quand le monolithe est en fait meilleur

Vous avez lu les articles Medium. Vous avez vu les talks YouTube. Vous avez entendu dire que Netflix et Uber utilisent les microservices. Donc vous avez décidé : "Nous aussi, on va faire des microservices."

18 mois plus tard, vous avez 47 services. Une trace distribuée qui prend 5 minutes à debug. Des dépendances en spaghetti que personne ne comprend vraiment. Et vous payez CHF 200,000 de plus par an en infrastructure parce que chaque service a besoin de sa propre base de données "pour l'autonomie."

Votre CTO vous regarde et dit : "On aurait peut-être dû garder le monolithe."

Il a raison. Voici pourquoi et quand les microservices ont vraiment du sens.

Le vrai coût des microservices

Les architectes adorent parler des bénéfices des microservices : scalabilité indépendante, déploiement autonome, liberté technologique. C'est tout vrai.

Mais personne ne parle du coût.

Coût 1 : Observabilité devient difficile

Un monolithe avec un problème ? Vous avez une stack trace, une database log, tout dans un seul endroit. Vous savez d'où vient le problème.

47 microservices avec un problème ? Vous avez besoin de :

• Logging distribué (Elasticsearch, Loki, CloudWatch)
• Distributed tracing (Jaeger, Datadog, tempo)
• Metrics centralisées (Prometheus, Graphite)
• Alerting intelligent (sinon vous avez 10,000 alerts par jour)
• Correlation IDs partout (pour tracker une requête à travers 15 services)

Coût : CHF 50,000-200,000 par an rien que pour observabilité. Une entreprise de 500+ employees sans cette stack en microservices est morte (vous ne saurez jamais où sont les bugs).

Coût 2 : Réseau devient un problème

Un monolithe : tous les appels internes sont en mémoire (< 1ms). Zéro latency.

Microservices : chaque appel traverse le réseau. Vous avez :

• Latence réseau (5-20ms par hop)
• Risk de timeouts
• Partial failures (service A répond, mais service B timeout)
• Retry storms (si vous avez pas de circuit breakers intelligent)

Une application qui faisait 10 appels internes en 10ms en monolithe, ça devient 100ms+ en microservices. Vous devez rearchitect pour batch requests, cache agressivement, etc.

Coût en performance : 10x plus lent sans optimisation. Et l'optimisation ? CHF 30,000-100,000 en engineering time.

Coût 3 : Deployment devient complexe

Un monolithe : vous déployez 1 chose. Vous testez 1 chose. Si ça casse, vous rollback 1 chose.

47 microservices : vous avez 47 CI/CD pipelines. 47 potential failure points. Vous devez orchestrer les déploiements (service A dépend de la version X de service B, you cannot deploy B d'abord sans breaking A).

Et les dépendances ? Elles changent tout le temps. Service C qui dépendait de service D veut maintenant appeler service E aussi. Ça s'appelle "distributed monolith" : tous les services sont étroitement couplés mais le couplage n'est pas visible.

Coût : 1 personne à plein temps juste pour gérer les déploiements.

Coût 4 : Testing devient un cauchemar

Un monolithe : vous testez tout ensemble. Intégration test = lancer l'app et tester.

Microservices : pour tester vraiment, vous avez besoin de lancer tous les 47 services localement. Ou vous mockez les dépendances (et tes mocks divergent du comportement réel). Ou vous avez un staging environment qui ressemble à la prod (coûteux).

Contract testing, integration test entre services, end-to-end tests... ça va te coûter CHF 100,000+ en automatisation et infrastructure de test.

Coût 5 : Data consistency devient un philosophie

Un monolithe : une database, une transaction ACID, c'est gagné.

Microservices : chaque service a sa propre database (sinon pourquoi tu les as séparé ?). Donc comment tu garantis la cohérence ?

Saga patterns, event sourcing, distributed transactions : c'est avancé, complexe, et beaucoup de CTO se trompent sur l'implémentation.

Résultat : des race conditions subtiles qui causent du downtime une fois par trimestre.

Total du coût caché

Voici ce que les microservices coûtent vraiment, au-delà de l'infrastructure :

Plus les infrastructure compute normales (CHF 200,000-400,000). Un système de 47 microservices coûte vite CHF 630,000-830,000 par an pour une entreprise de 500 personnes.

Un monolithe bien architécté ? CHF 200,000-300,000 par an. Différence : CHF 300,000-500,000.

Ça veut dire les microservices devront avoir un bénéfice de CHF 300,000+ par an juste pour se justifier. Quel bénéfice ? Rarement clairement mesuré.

Quand les microservices ont du VRAI sens

Maintenant, les microservices ne sont pas mauvais. Il y a des cas où c'est la bonne answer:

Cas 1 : Vraiment gros équipe, vraiment gros système

Netflix a 5000+ engineers. Chaque équipe a ~10 personnes. Pour que 500 équipes ne se marchent pas dessus, il faut l'autonomie. Donc microservices.

Mais vous avez 20 engineers ? Vous n'avez pas ce problème. Un monolithe décent qu'on peut déployer 20x par day, c'est meilleur que 20 microservices qu'on ne peut déployer que 2x par month.

Rule of thumb : Moins de 40 engineers, oubliez les microservices. Plus de 100 engineers, c'est justifié.

Cas 2 : Vraiment différents scaling requirements

Vous avez un service utilisé par 1 million de requêtes par seconde et un autre avec 10 requêtes par seconde.

Si vous les mélangez dans un monolithe, vous devez scaler le tout (même s'il faut scaler que le high-traffic service). Coûteux.

Si vous les séparez en microservices, vous scalez juste le high-traffic. Économie d'infrastructure.

Mais attention : ce cas est rare. 90% des services ont besoin de scaling similaire.

Cas 3 : Vraiment différentes technologies

Votre équipe data science veut Python + TensorFlow. Votre équipe backend veut Go. Votre équipe frontend veut Node.js.

Dans un monolithe, quelqu'un perd. Vous faites tout en Python ou tout en Go.

Dans microservices, chaque équipe a sa technologie.

Mais honêtement ? Si vous avez besoin de 3 langages, c'est symptôme d'un problème d'organisation, pas une solution. Et c'est solvable avec des libraries partagées.

Cas 4 : Vraiment besoin de déploiements très fréquents et indépendants

Si vous devez déployer une feature dans service A 10x par jour sans toucher aux autres services, microservices aide.

Mais combien d'équipes ont vraiment ce cas ? Peut-être 5% des entreprises.

L'alternative : Modular Monolith

Il y a une architecture entre monolithe et microservices qui a mieux marché pour nous : modular monolith.

Idée : Un codebase, une database, une deployé, mais internalement organisé en modules indépendants avec boundaries clairs.

monolith/
  ├── user_module/
  │   ├── handlers.go
  │   ├── service.go
  │   ├── repository.go
  │   └── tests/
  ├── payment_module/
  │   ├── handlers.go
  │   ├── service.go
  │   ├── repository.go
  │   └── tests/
  └── shared/
      ├── database.go
      └── logger.go

Bénéfices :

• Observabilité triviale (tout est dans un seul process)
• Performance facile (appels internes en mémoire)
• Testing simple (lancer l'app une fois)
• Deployment simple (une chose à déployer)

Flexibilité :

• Si plus tard un module a vraiment besoin de scaler indépendamment, vous le sortez en microservice. Mais vous avez les interfaces claires.
• Les équipes peuvent travailler sur des modules différents sans chaos.

Vous avez 80% des bénéfices des microservices, 20% du coût.

Migration décision tree

Voici comment décider si c'est temps de bouger vers microservices :

Avez-vous > 100 engineers ?
  Non -> Arrêtez ici. Monolithe ou modular monolith.
  Oui -> Continuer.

Avez-vous des services avec scaling requirements radicalement différents ?
  Non -> Arrêtez ici. Modular monolith suffira.
  Oui -> Continuer.

Avez-vous mesuré le coût de observabilité et infrastructure supplémentaire ?
  Non -> Allez mesurer. Peut-être vous changiez d'avis.
  Oui et c'est justifié par le bénéfice ? -> Allez-y avec microservices.

En résumé

Les microservices sont sexy sur le papier. En réalité, ils coûtent CHF 400,000-500,000/an de plus qu'un monolithe, et ça n'est justifié que si vous avez :

• 100+ engineers
• Scaling requirements très différents par service
• Ou besoin de déploiements ultra-fréquents et indépendants

Pour tout le monde d'autre (et ça c'est 95% des entreprises suisses) : un modular monolith est meilleur. Moins cher, plus rapide à build, plus facile à opérer.

Si vous êtes en doute ? La réponse correcte est probablement de rester simple. La complexité c'est une dette qui il faut rembourser pour le reste de l'histoire de votre app.

À lire aussi :

• Kubernetes pour les PME suisses : par où commencer ?
• Zero-downtime deployments : guide pour les CTO

Cet article vous a été utile ? Découvrez comment Hidora peut vous accompagner : Professional Services · Managed Services · SLA Expert