Keine Resilienz\u00a0\u2013 863x300JFrog Skalierbarkeit1<\/p>\n
Cloudsmith behauptet, eine Enterprise-Ready-L\u00f6sung zu sein\u00a0\u2013 eine Plattform, die entwickelt wurde, um die Anforderungen moderner Unternehmen auch bei gro\u00dfer Skalierung zu erf\u00fcllen. Auf den ersten Blick klingt das \u00fcberzeugend: Zuverl\u00e4ssigkeit, Performance, Sicherheit, Skalierbarkeit. Cloudsmith geht sogar so weit, sich als \u201eunbegrenzt skalierbare Alternative zu JFrog\u201c zu positionieren. Wenn ein Anbieter jedoch behauptet, f\u00fcr Enterprise-Anforderungen ausgelegt zu sein, lohnt sich die Frage: Kann er diese Versprechen auch bei hoher Skalierung und unter anspruchsvollen Enterprise-Bedingungen tats\u00e4chlich einl\u00f6sen?<\/p>\n
Was Cloudsmith auf seiner Website verspricht
\nWir 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\u00e4ndige CI\/CD-Pipelines laufen, mehrere Teams gleichzeitig Anfragen stellen oder Container in gro\u00dfem Umfang verteilt werden?<\/p>\n
Wir haben Cloudsmith auf die Probe gestellt \u2013 und das haben wir herausgefunden.<\/p>\n
Das Setup: Simulation realer Workflows
\nBei JFrog unterst\u00fctzen wir Tausende Cloud-Kunden, die t\u00e4glich die Grenzen der Skalierung ausreizen, umfangreiche CI\/CD-Pipelines betreiben, containerisierte Anwendungen weltweit bereitstellen und Software an ganze Ger\u00e4teflotten am Edge verteilen. Wir wissen, wie Enterprise-Skalierung aussieht, weil wir t\u00e4glich damit arbeiten.<\/p>\n
Als es darum ging, Cloudsmiths Behauptungen, \u201eEnterprise-ready\u201c zu sein, zu pr\u00fcfen, haben wir uns daher nicht auf synthetische Benchmarks oder isolierte Labortests verlassen. Stattdessen haben wir Szenarien aufgebaut, die reale Engineering-Umgebungen entsprechen, darunter:<\/p>\n
\tMehrere gleichzeitig laufende Workloads, die team\u00fcbergreifend Artefakte pullen und pushen<\/p>\n
\tContainer-Image-Traffic im Rahmen vollst\u00e4ndiger CI\/CD-Workflows<\/p>\n
\tStressszenarien mit 50\u2013100 gleichzeitigen Anfragen zur Simulation einer typischen Entwickler- und Automatisierungslast<\/p>\n
Und um es klarzustellen: Wir sind dabei nicht einmal an die Grenzen gegangen. Es handelte sich um Tests mittleren Umfangs, die f\u00fcr die meisten Teams eher als Einstiegsszenarien gelten w\u00fcrden. Doch selbst unter diesen kontrollierten Bedingungen zeigten sich erste Schw\u00e4chen bei der Zuverl\u00e4ssigkeit von Cloudsmith.<\/p>\n
Wir haben diese Tests sowohl mit JFrog als auch mit Cloudsmith unter vergleichbaren Bedingungen durchgef\u00fchrt.<\/p>\n
Vereinfachte Tests: Die Messlatte an das Ergebnis anpassen
\nAuf 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\u00df, dass die Entscheidung eindeutig ausgefallen w\u00e4re. Betrachtet man nur einzelne Vorg\u00e4nge bei geringer Last, k\u00f6nnte zun\u00e4chst der Eindruck entstehen, dass beide Plattformen die Anforderungen erf\u00fcllen.<\/p>\n
Schauen wir uns die Werte f\u00fcr einige g\u00e4ngige Pakettypen genauer an:<\/p>\n
\tDocker:
\nJFrog liegt sowohl beim Ingress als auch beim Egress deutlich vorne: mit einer Upload-Rate von 3,2\u00a0MB\/s gegen\u00fcber 1,4\u00a0MB\/s bei Cloudsmith und einer Download-Rate von 20,8\u00a0MB\/s im Vergleich zu 17,0\u00a0MB\/s bei Cloudsmith.
\n \tMaven:
\nJFrog \u00fcbertrifft Cloudsmith bei der Upload-Geschwindigkeit (0,8 MB\/s vs. 0,1 MB\/s), w\u00e4hrend Cloudsmith beim Download einen leichten Vorsprung hat (0,7 MB\/s vs. 0,6 MB\/s).
\n \tNPM:
\nHier liegen die Plattformen gleichauf: beide liefern 1 MB\/s beim Upload und 3 MB\/s beim Download.<\/p>\n
W\u00fcrde man die Tests an dieser Stelle beenden und jeweils nur ein einzelnes Paket ohne realistische Last testen, k\u00f6nnte man zu dem Schluss kommen, dass beide Plattformen \u00e4hnlich gut abschneiden. Doch das w\u00e4re so, als w\u00fcrde man zuerst den Pfeil abschie\u00dfen und dann erst die Zielscheibe darum herum malen.<\/p>\n
Solche vereinfachten Tests l\u00e4sst au\u00dfer Acht, was in modernen DevOps-Umgebungen tats\u00e4chlich passiert. Ihre Pipelines laufen nicht isoliert \u2013 und das sollten Ihre Performance-Benchmarks auch nicht.<\/p>\n
Moderne Pipelines basieren sich nicht auf einzelnen Downloads. Sie h\u00e4ngen von Konsistenz, Durchsatz und Stabilit\u00e4t unter hoher Last ab.
\nJFrog Skalierbarkeit1Vergleich der Upload- und Download-Geschwindigkeiten von JFrog und Cloudsmith.<\/p>\n
Unter Last zeigen sich die ersten Probleme
\nWir begannen mit einem einfachen Baseline-Test zur Simulation eines typischen Tages im Leben eines Entwicklungsteams. Ein paar Paket-Pulls, , mehrere gleichzeitige Nutzeraktivit\u00e4ten \u2013 nichts Au\u00dfergew\u00f6hnliches. Wie erwartet, lief zun\u00e4chst alles problemlos. Keine Auff\u00e4lligkeiten. Keine Fehler.<\/p>\n
Doch Enterprise-Umgebungen bleiben nicht bei solchen Basisszenarien.<\/p>\n
Also gingen wir einen Schritt weiter. Wir erh\u00f6hten die Last: 50 bis 100\u00a0Paketabrufe, die parallel laufen, um mehrere Entwickler oder automatisierte Prozesse zu simulieren, wodurch das System mit realistischen Workloads auf Einsteigerniveau leicht beansprucht wird.<\/p>\n
Und genau hier traten die Probleme regelm\u00e4\u00dfig auf. Ab diesem Punkt begann Cloudsmith zu schw\u00e4cheln.<\/p>\n
\tTimeouts traten bereits bei nur 1\u20132(!) gleichzeitigen Threads auf
\n \tDas Rate Limiting griff bei 180\u00a0Anfragen pro Minute
\n \tUploads wurden blockiert, Pipelines verlangsamten sich und die Plattform begann, 503-Fehler zur\u00fcckzugeben
\nBeispiel f\u00fcr eine Fehlermeldung:<\/p>\n
{"detail": "Request was throttled. Please wait 1 minute(s) before trying again."}JFrog Skalierbarkeit\u00a0\u2013 image3
\nZur 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 \u2013 und trotzdem stie\u00dfen wir schnell an Grenzen.<\/p>\n
Sie ben\u00f6tigen ein h\u00f6heres Limit? Dann sollten Sie am besten gut vorbereitet mit einer detaillierten Begr\u00fcndung ankommen und m\u00f6glichst genau vorhersagen k\u00f6nnen, welchen Bedarf Sie k\u00fcnftig haben werden, damit Cloudsmith sich darum \u201ek\u00fcmmern\u201c kann.<\/p>\n
Cloudsmith k\u00f6nnte argumentieren, dass ihre Ratenbegrenzungen dokumentiert und notwendig sind. Doch es besteht ein Unterschied zwischen verantwortungsvollen Nutzungskontrollen und der Begrenzung grundlegender Automatisierungsprozesse. Auch bei JFrog \u00fcberwachen wir aktiv missbr\u00e4uchliche Nutzung und sch\u00fctzen die Plattform vor unfairer Auslastung, aber wir blockieren keine legitime Automatisierung zahlender Kunden bei lediglich 3\u00a0Anfragen pro Sekunde. Das ist kein sinnvoller Schutzmechanismus, sondern ein Signal daf\u00fcr, 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.<\/p>\n
Diese Meldung l\u00e4sst die Anfrage nach mehr Bandbreite fast wie die Beantragung einer Hypothek wirken (Ressource: offizielle Dokumentation von Cloudsmith)
\nIm Gegensatz dazu blieb JFrog Cloud w\u00e4hrend des gesamten Tests stabil und leistungsf\u00e4hig und verarbeitete jede Anfrage ohne einen einzigen Ausfall mit einer aus unserer Sicht geringen Parallelit\u00e4t. Leistung und Stabilit\u00e4t blieben selbst bei deutlich h\u00f6herer Anzahl gleichzeitiger Anfragen und gr\u00f6\u00dferem Anfragevolumen konstant. Und das war kein einmaliger Ausrei\u00dfer: Unsere SaaS-Plattform verarbeitet weltweit jeden Tag Zehntausende Anfragen pro Sekunde.
\nDocker-Performance-DiagrammDocker-Performance basierend auf Anfragen pro Minute und Anzahl der Threads
\nDocker-Pull-ChartDer erste Durchlauf von Cloudsmith schl\u00e4gt mit mehreren Fehlern fehl. Bei den darauffolgenden Durchl\u00e4ufen verbessern sich die Performance, doch Zuverl\u00e4ssigkeit sollte nicht von vorherigen \u201eWarm-up\u201c-Durchl\u00e4ufen abh\u00e4ngen.<\/p>\n
The Need for Speed\u00a0\u2013 aber nur auf einer Spur
\nIn Unternehmensumgebungen l\u00e4uft die Softwarebereitstellung nicht im Schritttempo, sondern auf Hochtouren. CI\/CD-Pipelines sind st\u00e4ndig in Bewegung, wobei Dutzende oder Hunderte Prozesse parallel Artefakte pushen und pullen. Teams im gesamten Unternehmen sto\u00dfen Builds an, ver\u00f6ffentlichen Releases und stellen Updates bereit, alle gleichzeitig und zu jeder Zeit.<\/p>\n
Diese hohe Parallelit\u00e4t ist keine Ausnahme, sondern der Normalfall. Und Kunden erwarten von einem SaaS-Artefakt-Managementsystem, dass es damit ohne Einschr\u00e4nkungen Schritt h\u00e4lt. Das bedeutet: keine Engp\u00e4sse, kein standardm\u00e4\u00dfiges Throttling und eine Plattform, bei der Performance nicht zur Verhandlung steht.<\/p>\n
Wenn Sie einem Anbieter die wichtigsten Assets in Ihrem Softwarebereitstellungsprozess anvertrauen\u00a0\u2013 Ihre Bin\u00e4rdateien\u00a0\u2013, erwarten Sie, dass die Plattform in jeder Gr\u00f6\u00dfenordnung, unter jeder Last und ohne Ausreden funktioniert.<\/p>\n
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\u00fcrdigkeit und das Vertrauen Ihrer Kunden.<\/p>\n
\tCloudsmith drosselt Anfragen bei mehr als 180\u00a0Anfragen pro Minute
\n \tJFrog Cloud skaliert ohne Fehler, ohne dass Limits erreicht werden<\/p>\n
You had one job: F\u00e4llt die Artefakt-Registry aus, steht das gesamte Unternehmen still
\nJFrog Skalierbarkeit\u00a0\u2013 image9Cloudsmiths turbulenter Juli\u00a0\u2013 \u00dcberblick \u00fcber die Incidents
\nEin Artefakt-Repository ist mehr als nur ein Speicher, es bildet das R\u00fcckgrat moderner Softwarebereitstellung. Es ist das Herzst\u00fcck jeder Build-, Test-, Deployment- und Release-Pipeline. Unternehmen sind darauf angewiesen, um schnell zu agieren, Sicherheit zu gew\u00e4hrleisten und Software zuverl\u00e4ssig bereitzustellen. Wenn diese zentrale Infrastruktur ins Stocken ger\u00e4t, verlangsamt sich alles in ihrem Umfeld oder kommt v\u00f6llig zum Stillstand.<\/p>\n
Genau deshalb bringt der Betrieb eines Cloud-Repository-Services in gro\u00dfem Ma\u00dfstab eine enorme Verantwortung mit sich. Es reicht nicht aus, den Traffic die meiste Zeit problemlos zu bew\u00e4ltigen. Jede einzelne automatisierte Anfrage muss zuverl\u00e4ssig verarbeitet werden \u2013 ohne Ausnahme. In dem Moment, in dem Automatisierung unzuverl\u00e4ssig wird, ist sie keine Automatisierung mehr und das Vertrauen geht verloren.<\/p>\n
Dabei handelt es sich nicht nur um kleinere technische St\u00f6rungen. Wenn beim Abruf von Artefakten Timeouts auftreten oder sich Uploads verz\u00f6gern, geraten CI\/CD-Pipelines ins Stocken, Deployments verz\u00f6gern sich und Teams m\u00fcssen warten\u00a0\u2013 mit realen Kosten. Auf Dauer f\u00fchren 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 \u00a0\u2013 bei wichtigen Releases oder dringenden Patches.<\/p>\n
Trotz der Implementierung eines restriktiven Rate Limiting hat Cloudsmith weiterhin Schwierigkeiten, einen zuverl\u00e4ssigen Artefaktmanagement-Service bereitzustellen.<\/p>\n
Eine Repository-Plattform, die nicht mit Ihrem Workload skalieren kann, ist nicht nur eine Unannehmlichkeit. Sie ist ein gro\u00dfes Risiko.
\nCloud-native\u00a0\u2013 Online zu sein, ist NICHT optionalJFrog Skalierbarkeit\u00a0\u2013 image7JFrog Skalierbarkeit\u00a0\u2013 image7
\nWenn es um die Zuverl\u00e4ssigkeit einer Plattform geht, gibt es keinen Speilraum f\u00fcr Kompromisse. Ihre Pipelines, Entwickler und Deployments sind alle auf die Verf\u00fcgbarkeit des Services angewiesen. Und die Zahlen sprechen f\u00fcr sich.<\/p>\n
Wir haben einen Blick auf die Statusseite von Cloudsmith geworfen und dabei deren eigene Testimonials zur Uptime untersucht. F\u00fcr ein Unternehmen, das mit einem \u201eCloud-nativen\u201c Ansatz f\u00fcr sein Service-Management wirbt, zeichnen die Uptime-Berichte ein durchaus besorgniserregendes Bild.
\nSowohl Backend-Verarbeitungsservices als auch die Datenbanken erreichten im Mai eine Verf\u00fcgbarkeit von 99,41\u00a0%. F\u00fcr Unternehmen, die auf Continuous Delivery und eine zuverl\u00e4ssige Performance angewiesen sind, ist das eine erhebliche Ausfallzeit.<\/p>\n
Zur Einordnung: Das entspricht mehr als 4\u00a0Stunden im Monat, in denen Build-Pipelines fehlschlagen, Artefakt-Downloads und -Uploads nicht funktionieren und Entwickler sowie Agents nicht weiterarbeiten k\u00f6nnten. Dadurch k\u00f6nnen Releases beeintr\u00e4chtigt, Deployments verz\u00f6gert und neue Features und Bugfixes sp\u00e4ter an Kunden ausgeliefert werden und insgesamt eine enorme Menge an Zeit verloren gehen, w\u00e4hrend das Unternehmen darauf wartet, dass der Cloud-Dienst wieder verf\u00fcgbar ist. In schnelllebigen Entwicklungsumgebungen k\u00f6nnen bereits wenige Minuten Ausfallzeit pro Monat problematisch sein und sind inakzeptabel, ganz zu schweigen von einer Ausfallzeit von mehreren Stunden.<\/p>\n
Im Gegensatz dazu erreichte JFrog Cloud im selben Zeitraum eine ausgezeichnete Verf\u00fcgbarkeit von 100\u00a0%, bei einem garantierten SLA von 99,9\u00a0% Verf\u00fcgbarkeit. Das ist nicht nur eine Kennzahl, sondern ein akribisch \u00fcberwachtes Ziel: jederzeit verf\u00fcgbar zu sein \u2013 als Cloud-Service, der die Softwarefabrik Ihres Unternehmens zuverl\u00e4ssig unterst\u00fctzt.<\/p>\n
Wenn Sie sich also f\u00fcr das Fundament Ihrer Software-Lieferkette entscheiden, sollten Sie sich nicht mit \u201egut genug" zufrieden geben. W\u00e4hlen Sie die Cloud-Plattform, die \u00fcber die notwendige operativen Reife verf\u00fcgt und auf kontinuierliche Uptime sowie globale Ausfallsicherheit unter realen Workloads ausgelegt ist.<\/p>\n
Fazit
\nEchte Skalierbarkeit bedeutet nicht nur hohe Geschwindigkeit, sondern auch konstante Performance unter anhaltender Last, inh\u00e4rente Resilienz gegen\u00fcber Ausf\u00e4llen und eine m\u00f6glichst hohe Verf\u00fcgbarkeit. Eine Cloud-native L\u00f6sung auf Enterprise-Niveau f\u00fcr 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\u00e4hrleisten.<\/p>\n
Es reicht jedoch nicht aus, dass Anbieter ihre L\u00f6sungen als \u201eCloud-native\u201c bezeichnen. Unternehmen m\u00fcssen sich darauf verlassen k\u00f6nnen, dass die zugrundeliegende Architektur und Fachkompetenz diese Versprechen auch tats\u00e4chlich einl\u00f6sen k\u00f6nnen. Im Fall von Cloudsmith gibt das standardm\u00e4\u00dfige Rate Limiting bei einem Anfragevolumen, das viele noch unterhalb eines typischen Einstiegsszenarios einordnen w\u00fcrden, gepaart mit wiederkehrende Service-Unterbrechungen und einer Uptime-Zusage, die hinter den Branchenstandards zur\u00fcckbleibt, Anlass zur Sorge. Zusammengenommen deuten diese Faktoren darauf hin, dass Cloudsmith m\u00f6glicherweise Schwierigkeiten dabei hat, die Zuverl\u00e4ssigkeit und Performance zu bieten, die gro\u00dfe Unternehmen f\u00fcr den zuverl\u00e4ssigen Betrieb ihrer Entwicklungsprozesse ben\u00f6tigen.<\/p>\n
Hinzu kommen die von Cloudsmith zus\u00e4tzlich zum Artefakt-Repository angebotenen Funktionen f\u00fcr die Software-Lieferkette, bei der es sich um eine zusammengeschusterte L\u00f6sung aus veralteten OSS-Tools handelt, die ein falsches Gef\u00fchl von Sicherheit vermitteln.<\/p>\n
Vertrauen Sie die Softwareentwicklungprozesse und die Sicherheit Ihres Unternehmens einer bew\u00e4hrten Technologie an,die von Tausenden Enterprise-Cloud-Kunden eingesetzt wird und die f\u00fcr die Abwicklung ihrer Workflows auch unter Spitzenlasten ausgelegt ist \u2013 statt unter hoher Belastung an ihre Grenzen zu sto\u00dfen.<\/p>\n
Lernen Sie die JFrog Plattform bei einer Online-Tour kennen, vereinbaren Sie eine 1:1-Demo oder starten Sie eine kostenlose Testversion.<\/p>\n","protected":false},"excerpt":{"rendered":"
Keine Resilienz\u00a0\u2013 863x300JFrog Skalierbarkeit1 Cloudsmith behauptet, eine Enterprise-Ready-L\u00f6sung zu sein\u00a0\u2013 eine Plattform, die entwickelt wurde, um die Anforderungen moderner Unternehmen auch bei gro\u00dfer Skalierung zu erf\u00fcllen. Auf den ersten Blick klingt das \u00fcberzeugend: Zuverl\u00e4ssigkeit, Performance, Sicherheit, Skalierbarkeit. Cloudsmith geht sogar so weit, sich als \u201eunbegrenzt skalierbare Alternative zu JFrog\u201c zu positionieren. Wenn ein Anbieter jedoch …<\/p>\n","protected":false},"author":590,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[10517],"tags":[11476,11477,11478,11479,11480,11481,11482,11483],"class_list":["post-174930","post","type-post","status-publish","format-standard","hentry","category-devops-de","tag-performance","tag-enterprise","tag-cloud-native","tag-skalierbarkeit","tag-cloudsmith","tag-zuverlassigkeit","tag-entwicklungsgeschwindigkeit","tag-uptime"],"yoast_head":"\n