Nicht auf Skalierbarkeit ausgelegt: Die verborgene Fragilität von Cloudsmith

Keine Resilienz – 863x300JFrog Skalierbarkeit1

Cloudsmith behauptet, eine Enterprise-Ready-Lösung zu sein – eine Plattform, die entwickelt wurde, um die Anforderungen moderner Unternehmen auch bei großer Skalierung zu erfüllen. Auf den ersten Blick klingt das überzeugend: Zuverlässigkeit, Performance, Sicherheit, Skalierbarkeit. Cloudsmith geht sogar so weit, sich als „unbegrenzt skalierbare Alternative zu JFrog“ zu positionieren. Wenn ein Anbieter jedoch behauptet, für Enterprise-Anforderungen ausgelegt zu sein, lohnt sich die Frage: Kann er diese Versprechen auch bei hoher Skalierung und unter anspruchsvollen Enterprise-Bedingungen tatsächlich einlösen?

Was Cloudsmith auf seiner Website verspricht
Wir haben beschlossen, uns das genauer anzusehen. Und zwar nicht die Marketingversprechen, sondern das Verhalten der Plattform in der realen Welt unter hoher Belastung. Was passiert, wenn Sie nicht nur ein paar Pakete pushen, sondern vollständige CI/CD-Pipelines laufen, mehrere Teams gleichzeitig Anfragen stellen oder Container in großem Umfang verteilt werden?

Wir haben Cloudsmith auf die Probe gestellt – und das haben wir herausgefunden.

Das Setup: Simulation realer Workflows
Bei JFrog unterstützen wir Tausende Cloud-Kunden, die täglich die Grenzen der Skalierung ausreizen, umfangreiche CI/CD-Pipelines betreiben, containerisierte Anwendungen weltweit bereitstellen und Software an ganze Geräteflotten am Edge verteilen. Wir wissen, wie Enterprise-Skalierung aussieht, weil wir täglich damit arbeiten.

Als es darum ging, Cloudsmiths Behauptungen, „Enterprise-ready“ zu sein, zu prüfen, haben wir uns daher nicht auf synthetische Benchmarks oder isolierte Labortests verlassen. Stattdessen haben wir Szenarien aufgebaut, die reale Engineering-Umgebungen entsprechen, darunter:

Mehrere gleichzeitig laufende Workloads, die teamübergreifend Artefakte pullen und pushen

Container-Image-Traffic im Rahmen vollständiger CI/CD-Workflows

Stressszenarien mit 50–100 gleichzeitigen Anfragen zur Simulation einer typischen Entwickler- und Automatisierungslast

Und um es klarzustellen: Wir sind dabei nicht einmal an die Grenzen gegangen. Es handelte sich um Tests mittleren Umfangs, die für die meisten Teams eher als Einstiegsszenarien gelten würden. Doch selbst unter diesen kontrollierten Bedingungen zeigten sich erste Schwächen bei der Zuverlässigkeit von Cloudsmith.

Wir haben diese Tests sowohl mit JFrog als auch mit Cloudsmith unter vergleichbaren Bedingungen durchgeführt.

Vereinfachte Tests: Die Messlatte an das Ergebnis anpassen
Auf den ersten Blick sieht es gar nicht so schlecht aus. Als wir die durchschnittlichen Upload- und Download-Geschwindigkeiten einzelner Pakete gemessen haben, waren die Unterschiede zwischen JFrog und Cloudsmith nicht so groß, dass die Entscheidung eindeutig ausgefallen wäre. Betrachtet man nur einzelne Vorgänge bei geringer Last, könnte zunächst der Eindruck entstehen, dass beide Plattformen die Anforderungen erfüllen.

Schauen wir uns die Werte für einige gängige Pakettypen genauer an:

Docker:
JFrog liegt sowohl beim Ingress als auch beim Egress deutlich vorne: mit einer Upload-Rate von 3,2 MB/s gegenüber 1,4 MB/s bei Cloudsmith und einer Download-Rate von 20,8 MB/s im Vergleich zu 17,0 MB/s bei Cloudsmith.
Maven:
JFrog übertrifft Cloudsmith bei der Upload-Geschwindigkeit (0,8 MB/s vs. 0,1 MB/s), während Cloudsmith beim Download einen leichten Vorsprung hat (0,7 MB/s vs. 0,6 MB/s).
NPM:
Hier liegen die Plattformen gleichauf: beide liefern 1 MB/s beim Upload und 3 MB/s beim Download.

Würde man die Tests an dieser Stelle beenden und jeweils nur ein einzelnes Paket ohne realistische Last testen, könnte man zu dem Schluss kommen, dass beide Plattformen ähnlich gut abschneiden. Doch das wäre so, als würde man zuerst den Pfeil abschießen und dann erst die Zielscheibe darum herum malen.

Solche vereinfachten Tests lässt außer Acht, was in modernen DevOps-Umgebungen tatsächlich passiert. Ihre Pipelines laufen nicht isoliert – und das sollten Ihre Performance-Benchmarks auch nicht.

Moderne Pipelines basieren sich nicht auf einzelnen Downloads. Sie hängen von Konsistenz, Durchsatz und Stabilität unter hoher Last ab.
JFrog Skalierbarkeit1Vergleich der Upload- und Download-Geschwindigkeiten von JFrog und Cloudsmith.

Unter Last zeigen sich die ersten Probleme
Wir begannen mit einem einfachen Baseline-Test zur Simulation eines typischen Tages im Leben eines Entwicklungsteams. Ein paar Paket-Pulls, , mehrere gleichzeitige Nutzeraktivitäten – nichts Außergewöhnliches. Wie erwartet, lief zunächst alles problemlos. Keine Auffälligkeiten. Keine Fehler.

Doch Enterprise-Umgebungen bleiben nicht bei solchen Basisszenarien.

Also gingen wir einen Schritt weiter. Wir erhöhten die Last: 50 bis 100 Paketabrufe, die parallel laufen, um mehrere Entwickler oder automatisierte Prozesse zu simulieren, wodurch das System mit realistischen Workloads auf Einsteigerniveau leicht beansprucht wird.

Und genau hier traten die Probleme regelmäßig auf. Ab diesem Punkt begann Cloudsmith zu schwächeln.

Timeouts traten bereits bei nur 1–2(!) gleichzeitigen Threads auf
Das Rate Limiting griff bei 180 Anfragen pro Minute
Uploads wurden blockiert, Pipelines verlangsamten sich und die Plattform begann, 503-Fehler zurückzugeben
Beispiel für eine Fehlermeldung:

{"detail": "Request was throttled. Please wait 1 minute(s) before trying again."}JFrog Skalierbarkeit – image3
Zur Klarstellung: Wir haben nicht den kostenlosen Tarif getestet. Zum Einsatz kam ein kostenpflichtiger Cloudsmith-Premium(Pro)-Tarif im Vergleich mit dem entsprechenden Artifactory-Cloud(Pro)-Tarif – und trotzdem stießen wir schnell an Grenzen.

Sie benötigen ein höheres Limit? Dann sollten Sie am besten gut vorbereitet mit einer detaillierten Begründung ankommen und möglichst genau vorhersagen können, welchen Bedarf Sie künftig haben werden, damit Cloudsmith sich darum „kümmern“ kann.

Cloudsmith könnte argumentieren, dass ihre Ratenbegrenzungen dokumentiert und notwendig sind. Doch es besteht ein Unterschied zwischen verantwortungsvollen Nutzungskontrollen und der Begrenzung grundlegender Automatisierungsprozesse. Auch bei JFrog überwachen wir aktiv missbräuchliche Nutzung und schützen die Plattform vor unfairer Auslastung, aber wir blockieren keine legitime Automatisierung zahlender Kunden bei lediglich 3 Anfragen pro Sekunde. Das ist kein sinnvoller Schutzmechanismus, sondern ein Signal dafür, dass Cloudsmith entweder nicht wirklich versteht, wie Automatisierung in modernen Unternehmen funktioniert, die Software bereitstellt, oder dass ihre Cloud-Infrastruktur deutlich zu knapp dimensioniert ist.

Diese Meldung lässt die Anfrage nach mehr Bandbreite fast wie die Beantragung einer Hypothek wirken (Ressource: offizielle Dokumentation von Cloudsmith)
Im Gegensatz dazu blieb JFrog Cloud während des gesamten Tests stabil und leistungsfähig und verarbeitete jede Anfrage ohne einen einzigen Ausfall mit einer aus unserer Sicht geringen Parallelität. Leistung und Stabilität blieben selbst bei deutlich höherer Anzahl gleichzeitiger Anfragen und größerem Anfragevolumen konstant. Und das war kein einmaliger Ausreißer: Unsere SaaS-Plattform verarbeitet weltweit jeden Tag Zehntausende Anfragen pro Sekunde.
Docker-Performance-DiagrammDocker-Performance basierend auf Anfragen pro Minute und Anzahl der Threads
Docker-Pull-ChartDer erste Durchlauf von Cloudsmith schlägt mit mehreren Fehlern fehl. Bei den darauffolgenden Durchläufen verbessern sich die Performance, doch Zuverlässigkeit sollte nicht von vorherigen „Warm-up“-Durchläufen abhängen.

The Need for Speed – aber nur auf einer Spur
In Unternehmensumgebungen läuft die Softwarebereitstellung nicht im Schritttempo, sondern auf Hochtouren. CI/CD-Pipelines sind ständig in Bewegung, wobei Dutzende oder Hunderte Prozesse parallel Artefakte pushen und pullen. Teams im gesamten Unternehmen stoßen Builds an, veröffentlichen Releases und stellen Updates bereit, alle gleichzeitig und zu jeder Zeit.

Diese hohe Parallelität ist keine Ausnahme, sondern der Normalfall. Und Kunden erwarten von einem SaaS-Artefakt-Managementsystem, dass es damit ohne Einschränkungen Schritt hält. Das bedeutet: keine Engpässe, kein standardmäßiges Throttling und eine Plattform, bei der Performance nicht zur Verhandlung steht.

Wenn Sie einem Anbieter die wichtigsten Assets in Ihrem Softwarebereitstellungsprozess anvertrauen – Ihre Binärdateien –, erwarten Sie, dass die Plattform in jeder Größenordnung, unter jeder Last und ohne Ausreden funktioniert.

Und wenn Ihr System Anfragen drosselt, Timeouts verursacht oder Sie mitten in der Bereitstellung blockiert, ist das nicht nur eine Kennzahl, sondern ein echtes Hindernis. Dies kostet Zeit, Glaubwürdigkeit und das Vertrauen Ihrer Kunden.

Cloudsmith drosselt Anfragen bei mehr als 180 Anfragen pro Minute
JFrog Cloud skaliert ohne Fehler, ohne dass Limits erreicht werden

You had one job: Fällt die Artefakt-Registry aus, steht das gesamte Unternehmen still
JFrog Skalierbarkeit – image9Cloudsmiths turbulenter Juli – Überblick über die Incidents
Ein Artefakt-Repository ist mehr als nur ein Speicher, es bildet das Rückgrat moderner Softwarebereitstellung. Es ist das Herzstück jeder Build-, Test-, Deployment- und Release-Pipeline. Unternehmen sind darauf angewiesen, um schnell zu agieren, Sicherheit zu gewährleisten und Software zuverlässig bereitzustellen. Wenn diese zentrale Infrastruktur ins Stocken gerät, verlangsamt sich alles in ihrem Umfeld oder kommt völlig zum Stillstand.

Genau deshalb bringt der Betrieb eines Cloud-Repository-Services in großem Maßstab eine enorme Verantwortung mit sich. Es reicht nicht aus, den Traffic die meiste Zeit problemlos zu bewältigen. Jede einzelne automatisierte Anfrage muss zuverlässig verarbeitet werden – ohne Ausnahme. In dem Moment, in dem Automatisierung unzuverlässig wird, ist sie keine Automatisierung mehr und das Vertrauen geht verloren.

Dabei handelt es sich nicht nur um kleinere technische Störungen. Wenn beim Abruf von Artefakten Timeouts auftreten oder sich Uploads verzögern, geraten CI/CD-Pipelines ins Stocken, Deployments verzögern sich und Teams müssen warten – mit realen Kosten. Auf Dauer führen solche Unterbrechungen zu langsameren Release-Zyklen, verpassten Deadlines und frustrierten Entwicklern. Am schlimmsten ist, dass solche Probleme oft genau dann auftreten, wenn Resilienz unverzichtbar ist  – bei wichtigen Releases oder dringenden Patches.

Trotz der Implementierung eines restriktiven Rate Limiting hat Cloudsmith weiterhin Schwierigkeiten, einen zuverlässigen Artefaktmanagement-Service bereitzustellen.

Eine Repository-Plattform, die nicht mit Ihrem Workload skalieren kann, ist nicht nur eine Unannehmlichkeit. Sie ist ein großes Risiko.
Cloud-native – Online zu sein, ist NICHT optionalJFrog Skalierbarkeit – image7JFrog Skalierbarkeit – image7
Wenn es um die Zuverlässigkeit einer Plattform geht, gibt es keinen Speilraum für Kompromisse. Ihre Pipelines, Entwickler und Deployments sind alle auf die Verfügbarkeit des Services angewiesen. Und die Zahlen sprechen für sich.

Wir haben einen Blick auf die Statusseite von Cloudsmith geworfen und dabei deren eigene Testimonials zur Uptime untersucht. Für ein Unternehmen, das mit einem „Cloud-nativen“ Ansatz für sein Service-Management wirbt, zeichnen die Uptime-Berichte ein durchaus besorgniserregendes Bild.
Sowohl Backend-Verarbeitungsservices als auch die Datenbanken erreichten im Mai eine Verfügbarkeit von 99,41 %. Für Unternehmen, die auf Continuous Delivery und eine zuverlässige Performance angewiesen sind, ist das eine erhebliche Ausfallzeit.

Zur Einordnung: Das entspricht mehr als 4 Stunden im Monat, in denen Build-Pipelines fehlschlagen, Artefakt-Downloads und -Uploads nicht funktionieren und Entwickler sowie Agents nicht weiterarbeiten könnten. Dadurch können Releases beeinträchtigt, Deployments verzögert und neue Features und Bugfixes später an Kunden ausgeliefert werden und insgesamt eine enorme Menge an Zeit verloren gehen, während das Unternehmen darauf wartet, dass der Cloud-Dienst wieder verfügbar ist. In schnelllebigen Entwicklungsumgebungen können bereits wenige Minuten Ausfallzeit pro Monat problematisch sein und sind inakzeptabel, ganz zu schweigen von einer Ausfallzeit von mehreren Stunden.

Im Gegensatz dazu erreichte JFrog Cloud im selben Zeitraum eine ausgezeichnete Verfügbarkeit von 100 %, bei einem garantierten SLA von 99,9 % Verfügbarkeit. Das ist nicht nur eine Kennzahl, sondern ein akribisch überwachtes Ziel: jederzeit verfügbar zu sein – als Cloud-Service, der die Softwarefabrik Ihres Unternehmens zuverlässig unterstützt.

Wenn Sie sich also für das Fundament Ihrer Software-Lieferkette entscheiden, sollten Sie sich nicht mit „gut genug" zufrieden geben. Wählen Sie die Cloud-Plattform, die über die notwendige operativen Reife verfügt und auf kontinuierliche Uptime sowie globale Ausfallsicherheit unter realen Workloads ausgelegt ist.

Fazit
Echte Skalierbarkeit bedeutet nicht nur hohe Geschwindigkeit, sondern auch konstante Performance unter anhaltender Last, inhärente Resilienz gegenüber Ausfällen und eine möglichst hohe Verfügbarkeit. Eine Cloud-native Lösung auf Enterprise-Niveau für Artefaktmanagement und Sicherheit muss den kontinuierlichen Anforderungen von Hunderten oder sogar Tausenden Entwicklern gerecht werden und eine schnelle Bereitstellung sowie den unterbrechungsfreien Zugriff auf gemeinsam genutzte Entwicklungsressourcen gewährleisten.

Es reicht jedoch nicht aus, dass Anbieter ihre Lösungen als „Cloud-native“ bezeichnen. Unternehmen müssen sich darauf verlassen können, dass die zugrundeliegende Architektur und Fachkompetenz diese Versprechen auch tatsächlich einlösen können. Im Fall von Cloudsmith gibt das standardmäßige Rate Limiting bei einem Anfragevolumen, das viele noch unterhalb eines typischen Einstiegsszenarios einordnen würden, gepaart mit wiederkehrende Service-Unterbrechungen und einer Uptime-Zusage, die hinter den Branchenstandards zurückbleibt, Anlass zur Sorge. Zusammengenommen deuten diese Faktoren darauf hin, dass Cloudsmith möglicherweise Schwierigkeiten dabei hat, die Zuverlässigkeit und Performance zu bieten, die große Unternehmen für den zuverlässigen Betrieb ihrer Entwicklungsprozesse benötigen.

Hinzu kommen die von Cloudsmith zusätzlich zum Artefakt-Repository angebotenen Funktionen für die Software-Lieferkette, bei der es sich um eine zusammengeschusterte Lösung aus veralteten OSS-Tools handelt, die ein falsches Gefühl von Sicherheit vermitteln.

Vertrauen Sie die Softwareentwicklungprozesse und die Sicherheit Ihres Unternehmens einer bewährten Technologie an,die von Tausenden Enterprise-Cloud-Kunden eingesetzt wird und die für die Abwicklung ihrer Workflows auch unter Spitzenlasten ausgelegt ist – statt unter hoher Belastung an ihre Grenzen zu stoßen.

Lernen Sie die JFrog Plattform bei einer Online-Tour kennen, vereinbaren Sie eine 1:1-Demo oder starten Sie eine kostenlose Testversion.