Une étude de cas interne d’Amazon fait grand bruit, car elle conclut qu’on peut réduire ses coûts de 90 % en faisant l’impasse sur les microservices, comme les fonctions sans serveurs AWS Lambda et les transitions d’état par AWS Step Functions, en leur préférant des solutions monolithiques.
Or AWS, comme ses concurrents, présentent les microservices comme l’architecture à préférer pour les applications modernes dans le nuage.
Cette étude, de l’équipe Prime Video, s’intéresse à un outil de suivi des problèmes de qualité de chaque flux vidéo visionné par un client, et qui doit être par conséquent facilement mise à l’échelle pour des milliers de flux simultanés.
Initialement, l’équipe avait développé une solution avec des composants distribués orchestrés par AWS Step Functions. Ces fonctions s’avérèrent être un goulot d’étranglement.
« Comme notre service a effectué plusieurs transitions d’état pour chaque seconde du flux, nous avons rapidement atteint les limites de notre compte. En outre, AWS Step Functions facture les utilisateurs par transition d’état », indique le document. Il y avait également un problème de coût avec le « nombre élevé d’appelsau service de stockage de données S3 » utilisé pour le stockage temporaire des images vidéo capturées.
« Nous avons compris que cette approche distribuée n’apportait pas beaucoup d’avantages dans notre cas d’utilisation spécifique, et nous avons donc regroupé tous les composants dans un seul processus », poursuit le document, éliminant ainsi le besoin pour S3. « Nous avons également mis en place une orchestration qui contrôle les composants au sein d’une instance unique. » La solution fonctionne désormais sur EC2 (capacité de calcul redimensionnable) et ECS (exécution de conteneurs), avec une couche d’orchestration légère pour distribuer les demandes des clients.
Le document conclut que « les microservices et les composants sans serveur sont des outils qui fonctionnent à grande échelle, mais le choix de les utiliser plutôt qu’un monolithe doit être fait au cas par cas. Le passage de notre service à un monolithe a permis de réduire nos coûts d’infrastructure de plus de 90 %. Cela a également augmenté nos capacités de mise à l’échelle ».
Il s’agit certes d’un cas particulier, qui ne peut sans doute pas se généraliser à tous les besoins. Il prouve à tout le moins que les entreprises ont intérêt à évaluer les différentes architectures d’applications dans le nuage, sans prendre les recommandations des prestataires pour argent comptant.
Des sommités, tel que David Heinemeier Hansson, créateur de Ruby On Rails, commentent que cette étude « résume vraiment une grande partie de l’engouement pour les microservices qui a capté l’industrie technologique pendant un certain temps : EN THÉORIE. Aujourd’hui, les résultats concrets de toute cette théorie sont enfin connus et il est clair qu’en pratique, les microservices représentent peut-être le plus grand chant de sirène pour compliquer inutilement votre système. Et le sans serveur ne fait qu’empirer les choses ». Selon Hansson, « remplacer les appels de méthode et les séparations de modules par des invocations de réseau et un partitionnement des services au sein d’une équipe et d’une application uniques et cohérentes est une folie dans presque tous les cas. »