Amazon a réduit ses coûts de 90% en abandonnant les microservices. Et alors ?

Je suis tombé là dessus il y a quelques jours : l’équipe Prime Video d’Amazon a migré un service critique d’une architecture microservices serverless vers un monolithe. Résultat : -90% sur la facture d’infrastructure.

Bien sûr. la tech sphère s’est enflammée. Les pro-monolithe ont crié victoire. Les défenseurs des microservices ont minimisé. Tout le monde avait tort.

Ce qui s’est réellement passé

L’équipe Prime Video avait besoin d’analyser la qualité audio/vidéo de milliers de flux simultanés en temps réel. Corruption d’image, gel vidéo, problèmes de synchronisation — le genre de défaut que le spectateur ne doit jamais voir.

L’architecture initiale était un cas d’école AWS :
→ AWS Step Functions pour l’orchestration
→ Lambda pour le traitement
→ S3 comme stockage intermédiaire entre les étapes

Sur le papier, c’est propre. En production, à grande échelle, c’est devenu un gouffre financier.

Le problème n’était pas les microservices en soi. C’était leur usage dans ce contexte précis :

• Step Functions facturait chaque transition d’état — et il y en avait plusieurs par seconde, par flux
• Les données vidéo transitaient par S3 entre chaque étape, générant des millions d’appels API
• Le système atteignait ses limites de scaling à seulement 5% de la charge prévue

La solution : tout remettre dans le même process

L’équipe a consolidé le media converter et les détecteurs de défauts dans un seul conteneur ECS. Les données circulent en mémoire au lieu de transiter par le réseau.

Pas de réécriture complète. Pas de nouvelle techno révolutionnaire. Juste une décision d’architecture pragmatique.

Ce que ça veut dire

1. L’architecture n’est pas une religion

Werner Vogels, le CTO d’Amazon, l’a dit lui-même :

« Building evolvable software systems is a strategy, not a religion. »

On ne choisit pas une architecture parce qu’elle est à la mode. On la choisit parce qu’elle répond aux contraintes réelles du projet : volume, budget, équipe, time-to-market.

2. Le coût du « distribué » est souvent sous-estimé

Chaque appel réseau entre services a un coût. En latence, en complexité de debug, en facture cloud. Quand vos composants échangent des données volumineuses à haute fréquence — comme des frames vidéo — les distribuer est une décision coûteuse.

3. Commencer simple n’est pas un aveu de faiblesse

Pour une PME ou une startup, un monolithe bien structuré est souvent le meilleur choix initial. Vous pourrez toujours extraire des services plus tard, quand vous aurez des données réelles sur vos goulots d’étranglement.

Le vrai talent en architecture, c’est de concevoir un système capable d’évoluer — pas un système qui anticipe tous les problèmes qu’il n’aura peut-être jamais.

Le piège à éviter

Ne tirez pas la conclusion inverse. Amazon n’a pas abandonné les microservices. Netflix tourne toujours sur des centaines de microservices. L’équipe Prime Video elle-même précise :

« Microservices and serverless components are tools that do work at high scale, but whether to use them over monolith has to be made on a case-by-case basis. »

La seule mauvaise décision, c’est celle qu’on prend par dogme plutôt que par analyse.

Et vous, sur vos projets, comment arbitrez-vous entre monolithe et microservices ? Avez-vous déjà fait marche arrière sur un choix d’architecture ?