Pas conçu pour évoluer à grande échelle : la fragilité cachée de Cloudsmith

Aucune résilience – 863×300Évolutivité de JFrog1

Cloudsmith affirme être une solution prête pour les entreprises, une plateforme conçue pour répondre à grande échelle aux besoins des organisations modernes. À première vue, l’entreprise « tient le bon discours » : fiabilité, performances, sécurité et évolutivité. Elle va même jusqu’à se présenter comme une « alternative à JFrog capable d’évoluer à l’infini ». Cependant, lorsqu’un fournisseur affirme que sa solution est conçue pour les entreprises, une question mérite d’être posée : peut-il réellement tenir ses promesses à grande échelle ou face à n’importe quelle exigence d’entreprise ?

Ce qu’affirme Cloudsmith sur son site web
Nous avons décidé d’examiner la question de plus près, en nous intéressant non pas au discours marketing creux, mais au comportement réel de la plateforme lorsqu’elle est soumise à une forte pression. Que se passe-t-il lorsque vous ne vous contentez pas d’envoyer quelques packages, mais que vous exécutez des pipelines CI/CD complets, répondez simultanément aux demandes de plusieurs équipes ou distribuez des conteneurs en masse ?

Nous avons mis Cloudsmith à l’épreuve, et voici ce que nous avons découvert.

Configuration du test : simulation de workflows réels
Chez JFrog, nous accompagnons des milliers de clients cloud qui repoussent chaque jour les limites de l’évolutivité en exécutant d’immenses pipelines CI/CD, en déployant des applications conteneurisées dans le monde entier et en distribuant des logiciels à des parcs d’appareils en périphérie du réseau. Nous savons à quoi ressemble une infrastructure à l’échelle de l’entreprise, car nous la vivons au quotidien.

Ainsi, lorsqu’est venu le moment d’évaluer l’affirmation de Cloudsmith selon laquelle sa plateforme est « prête pour les entreprises », nous ne nous sommes pas appuyés sur des benchmarks synthétiques ou des tests de laboratoire isolés. Nous avons créé des scénarios reproduisant de véritables environnements d’ingénierie, notamment :

Plusieurs charges de travail simultanées effectuant des pull et des push d’artefacts pour différentes équipes

Du trafic d’images de conteneurs dans le cadre de workflows CI/CD complets

Des scénarios de test de résistance comprenant 50 à 100 requêtes simultanées afin de reproduire une charge basique générée par des développeurs et des processus automatisés

Précisons que nous étions encore loin de pousser la plateforme dans ses derniers retranchements. Il s’agissait de tests à échelle moyenne, correspondant largement à ce que la plupart des équipes considéreraient comme un niveau d’entrée de gamme. Pourtant, même dans ces conditions contrôlées, des failles ont commencé à apparaître dans la fiabilité de Cloudsmith.

Nous avons effectué ces tests sur JFrog et Cloudsmith dans des conditions équivalentes.

Tests naïfs : dessiner la cible autour de la flèche
À première vue, les résultats ne semblent pas si mauvais. Lorsque nous avons mesuré les vitesses moyennes d’envoi et de téléchargement de packages individuels, les différences entre JFrog et Cloudsmith n’étaient pas suffisamment importantes pour rendre le choix évident. En apparence, l’une ou l’autre plateforme pourrait sembler capable de faire le travail si l’on examine uniquement des opérations isolées soumises à une faible charge.

Examinons les chiffres pour quelques types de packages courants :

Docker:
JFrog affiche une avance nette tant en entrée qu’en sortie, avec un débit de téléversement de 3,2 Mo/s contre 1,4 Mo/s pour Cloudsmith, et un débit de téléchargement de 20,8 Mo/s par rapport aux 17,0 Mo/s de Cloudsmith.
Maven :
JFrog surpasse Cloudsmith en matière de vitesse d’envoi (0,8 Mo/s contre 0,1 Mo/s), tandis que Cloudsmith bénéficie d’un léger avantage pour le téléchargement (0,7 Mo/s contre 0,6 Mo/s).
NPM :
les deux plateformes font jeu égal, avec une vitesse d’envoi de 1 Mo/s et une vitesse de téléchargement de 3 Mo/s.

Si vous arrêtiez les tests ici, en évaluant un seul package à la fois et sans aucune charge réelle, vous pourriez conclure que la compétition est équilibrée. Mais ce serait comme tirer une flèche, puis dessiner une cible autour d’elle.

Ce type de test naïf ne tient pas compte de ce qui se passe réellement dans les environnements DevOps modernes. Vos pipelines ne fonctionnent pas de manière isolée, et vos benchmarks de performances ne devraient pas l’être non plus.

Les pipelines modernes ne reposent pas sur des téléchargements uniques. Ils dépendent de la régularité, du débit et de la stabilité sous pression.
Évolutivité de JFrog1Comparaison des vitesses d’envoi et de téléchargement de JFrog et Cloudsmith.

Sous charge, les choses commencent à se dégrader
Nous avons commencé simplement, avec un test de référence visant à reproduire une journée typique au sein d’une équipe de développement. Quelques pulls de packages, un peu d’activité simultanée de la part des utilisateurs, rien d’inhabituel. Sans surprise, tout semblait fonctionner correctement. Aucun signal d’alerte. Aucune erreur.

Mais les environnements d’entreprise ne s’arrêtent pas à un fonctionnement « basique ».

Nous avons donc accentué légèrement la pression. Nous sommes passés à 50, puis à 100 téléchargements de packages exécutés en parallèle, simulant plusieurs développeurs ou tâches automatisées et sollicitant légèrement le système avec des workflows réalistes d’entrée de gamme.

C’est alors que les défaillances ont commencé à se produire régulièrement. C’est à ce moment-là que Cloudsmith commence à flancher.

Des délais d’expiration sont apparus avec seulement 1 à 2(!) threads simultanés.
La limitation du débit s’est déclenchée à 180 requêtes par minute.
Les téléversements ont été bloqués, les pipelines ont ralenti et la plateforme a commencé à renvoyer des erreurs 503.
Exemple de message d’erreur :

{"detail": "Request was throttled. Please wait 1 minute(s) before trying again."}Évolutivité de JFrog – image 3
Et pour que les choses soient parfaitement claires, nous ne testions pas l’offre gratuite. Il s’agissait d’une offre Cloudsmith Premium (Pro) payante, comparée à l’offre équivalente Artifactory Cloud (Pro), et nous avons malgré tout atteint une limite infranchissable.

Besoin d’une limite plus élevée ? Mieux vaut arriver préparé, avec une justification détaillée et une boule de cristal permettant de prédire vos besoins futurs, afin que Cloudsmith puisse « s’en occuper ».

Cloudsmith peut affirmer que ses limites de débit sont documentées et nécessaires, mais il existe une différence entre des contrôles responsables de l’utilisation et la limitation de processus automatisés élémentaires. Chez JFrog, nous surveillons également activement les abus et nous protégeons contre les utilisations déloyales, mais nous ne bloquons pas les automatisations légitimes de clients payants fonctionnant à seulement trois requêtes par seconde. Ce n’est pas une mesure de protection. Cela indique que Cloudsmith ne comprend pas pleinement le fonctionnement de l’automatisation dans une organisation moderne qui fournit des logiciels, ou que son infrastructure cloud est largement sous-dimensionnée.

Ce message donne l’impression que demander davantage de bande passante revient à solliciter un prêt immobilier (Source : documentation officielle de Cloudsmith).
À l’inverse, JFrog Cloud est resté stable et performant pendant toute la durée du test, traitant chaque requête sans la moindre défaillance avec ce que nous considérons comme un faible nombre de requêtes simultanées. Les performances et la stabilité sont restées constantes, même avec l’augmentation du nombre de requêtes simultanées. Et il ne s’agit pas d’un heureux hasard isolé : notre plateforme SaaS traite chaque jour des dizaines de milliers de requêtes par seconde dans le monde entier.
Graphique des performances de DockerPerformances de Docker en fonction du nombre de requêtes par minute et du nombre de threads
Graphique des pulls DockerLa première exécution de Cloudsmith échoue avec plusieurs erreurs. Les exécutions suivantes s’améliorent, mais la fiabilité ne devrait pas dépendre d’une phase de préchauffage.

Le besoin de vitesse – Rouler sur une seule voie
Dans les environnements d’entreprise, la livraison de logiciels ne se fait pas au compte-gouttes. Elle tourne à plein régime. Les pipelines CI/CD sont constamment en mouvement, avec des dizaines ou des centaines de processus qui pullent et pushent des artefacts en parallèle. Dans toute l’organisation, les équipes déclenchent des builds, publient des versions et déploient des mises à jour, simultanément et en permanence.

Ce niveau d’activité simultanée n’est pas une exception. C’est la norme. Et les clients attendent d’un système SaaS de gestion des artefacts qu’il suive le rythme sans faiblir. Cela signifie aucun goulot d’étranglement, aucune limitation par défaut et une plateforme pour laquelle les performances ne sont pas négociables.

Lorsque vous confiez à un fournisseur les ressources les plus essentielles de votre processus de livraison logicielle, c’est-à-dire vos fichiers binaires, vous vous attendez à ce que son système fonctionne à n’importe quelle échelle et sous n’importe quelle charge, sans excuses.

Et lorsque votre système limite le débit, expire ou vous bloque en plein déploiement, il ne s’agit pas simplement d’un indicateur. Il s’agit d’un obstacle. Cela coûte du temps, de la crédibilité et la confiance des clients.

Cloudsmith limite les requêtes au-delà de 180 requêtes par minute.
JFrog Cloud évolue sans aucune erreur et sans qu’aucune limite soit atteinte.

Une seule mission, et pourtant… quand votre registre d’artefacts ne fonctionne plus, c’est toute l’organisation qui s’effondre
Évolutivité de JFrog – image 9Le mois de juillet mouvementé de Cloudsmith – Vue d’ensemble des incidents
Un dépôt d’artefacts est bien plus qu’un simple espace de stockage. Il constitue l’épine dorsale de la livraison logicielle moderne. Il se trouve au cœur de chaque pipeline de build, de test, de déploiement et de publication. Les organisations comptent sur lui pour avancer rapidement, rester sécurisées et fournir leurs logiciels en toute confiance. Lorsque cette infrastructure essentielle flanche, tout ce qui l’entoure ralentit ou s’arrête complètement.

C’est pourquoi proposer à grande échelle un service cloud de dépôt implique une immense responsabilité. Il ne suffit pas de gérer correctement le trafic la plupart du temps. Chaque requête automatisée doit être traitée, sans exception. Dès que l’automatisation devient peu fiable, ce n’est plus de l’automatisation et la CONFIANCE vole en éclats.

Il ne s’agit pas de simples problèmes techniques mineurs. Lorsque le pull d’artefacts expire ou que les uploads sont retardés, les pipelines CI/CD se bloquent, les déploiements sont retardés et les équipes restent dans l’attente. Le coût est réel. Au fil du temps, ces interruptions ralentissent les cycles de publication, entraînent le non-respect des délais et frustrent les ingénieurs. Pire encore, elles ont tendance à survenir à des moments critiques, comme lors de publications majeures ou de l’application de correctifs urgents, lorsque la résilience n’est pas négociable.

Malgré la mise en place d’une limitation agressive du débit des requêtes, Cloudsmith peine toujours à fournir un service fiable de gestion des artefacts.

Une plateforme de dépôt incapable d’évoluer avec votre charge de travail n’est pas simplement une source de désagrément. C’est un handicap.
Cloud native – La disponibilité n’est PAS facultativeÉvolutivité de JFrog – image 7Évolutivité de JFrog – image 7
En matière de fiabilité d’une plateforme, il n’y a pas de place pour les compromis. Vos pipelines, vos développeurs et vos déploiements dépendent tous de la disponibilité du service. Et les chiffres parlent d’eux-mêmes.

Nous avons consulté, sans choisir de période particulière, la page d’état de Cloudsmith afin d’examiner les données de disponibilité que l’entreprise publie elle-même. Pour une entreprise qui vante son approche « cloud native » de la gestion des services, les rapports de disponibilité dressent un tableau plutôt inquiétant.
Les services de traitement back-end ainsi que les bases de données ont affiché une disponibilité de 99,41 % au mois de mai, ce qui représente une panne grave pour toute organisation dépendant d’une livraison continue et de performances fiables.

Pour mettre ce chiffre en perspective : cela représente plus de 4 heures(!) au cours du mois pendant lesquelles les pipelines de build pouvaient échouer, les téléchargements et uploads d’artefacts pouvaient ne pas fonctionner et les développeurs comme les agents ne pouvaient plus progresser. Dans les faits, cela peut perturber les publications, retarder les déploiements, bloquer la livraison de nouvelles fonctionnalités et de correctifs aux clients, et faire perdre globalement un nombre considérable d’heures à toute organisation attendant le rétablissement du service cloud. Dans les environnements de développement qui évoluent rapidement, même quelques minutes d’indisponibilité mensuelle sont importantes et inacceptables, sans même parler de plusieurs heures.

À l’inverse, pendant la même période, JFrog Cloud a maintenu une disponibilité parfaite de 100 %, avec un SLA garantissant une disponibilité de 99,9 %. Il ne s’agit pas simplement d’une statistique. C’est un objectif de disponibilité permanente faisant l’objet d’un suivi méticuleux, pour un service cloud qui permet à la fabrique logicielle de votre entreprise de fonctionner.

Ainsi, lorsque vous choisissez les fondations de votre chaîne d’approvisionnement logicielle, ne vous contentez pas d’une solution « suffisamment bonne ». Choisissez la plateforme cloud reposant sur la maturité opérationnelle et l’engagement nécessaires pour assurer une disponibilité continue et une résilience mondiale face aux charges de travail réelles.

Conclusion
Une véritable évolutivité ne se limite pas à la vitesse brute. Elle englobe également des performances constantes sous des charges prolongées, une résilience intrinsèque face aux défaillances et une disponibilité maximale. Une solution cloud native de gestion et de sécurisation des artefacts conçue pour les entreprises doit répondre aux demandes permanentes de centaines, voire de milliers de développeurs, tout en garantissant une livraison rapide et un accès ininterrompu aux ressources de développement partagées.

Malheureusement, il ne suffit pas aux fournisseurs de qualifier leurs offres de « cloud natives », car les entreprises doivent avoir la certitude que l’architecture sous-jacente et l’expertise du domaine permettent réellement de tenir ces promesses. Dans le cas de Cloudsmith, la limitation du débit des requêtes appliquée par défaut à un niveau que beaucoup considèrent comme inférieur à celui d’une solution d’entrée de gamme, associée aux interruptions fréquentes du service et à un engagement de disponibilité inférieur aux normes du secteur, constitue indéniablement une source de préoccupation. Pris dans leur ensemble, ces facteurs suggèrent que Cloudsmith pourrait avoir des difficultés à fournir la fiabilité et les performances fondamentales dont les grandes entreprises ont besoin pour déployer en toute confiance leurs solutions de gestion des opérations de développement.

À cela s’ajoutent les fonctionnalités de chaîne d’approvisionnement logicielle proposées par Cloudsmith en complément de son dépôt d’artefacts, qui forment une solution bricolée reposant sur des outils open source obsolètes et procurant un faux sentiment de sécurité.

Confiez les opérations de développement logiciel et la sécurité de votre organisation à une technologie éprouvée dont bénéficient des milliers de clients cloud professionnels, conçue pour gérer leurs workflows lors des pics de charge et non pour flancher sous la pression.

Découvrez la plateforme JFrog en suivant une visite en ligne, en programmant une démonstration individuelle ou en commençant un essai gratuit à votre convenance.