Warum sich Open Source für MLOps besser eignet als proprietäre Software

Machine Learning Teams können entweder proprietäre Plattformen wie Knime oder SageMaker verwenden, oder mit Hilfe von Open Source Tools direkt ihre eigenen Plattformen entwickeln. Unternehmen vermarkten ihre eigenen, kostenpflichtigen Plattformen oft als leistungsfähiger, effizienter und einfacher zu bedienen. In Wirklichkeit sind sie jedoch oft sogar komplizierter und weniger leistungsfähig als Open Source Alternativen.

Wir bauen unsere MLOps-Architektur rein auf Basis von Open Source. In diesem Artikel erfährst du, warum wir das so wichtig finden.

Open Source ist qualitativ hochwertiger

Kostenlose Tools werden oft etwas misstrauisch beäugt. In unseren Augen jedoch zu Unrecht, da Open Source-Software oft qualitativ hochwertiger als kostenpflichtige Alternativen ist. 

Open Source-Projekte profitieren außerdem davon, dass sie von wesentlich mehr Menschen genutzt werden als Closed Source-Alternativen. Sobald ein Nutzer einen Fehler findet, kann er einen Fix beisteuern, von dem direkt alle anderen Nutzer profitieren.

Darüber hinaus wird Open Source-Software in der Regel nicht kommerzialisiert. Das bedeutet, nur die Qualität der Software entscheidet darüber, ob sich die Software durchsetzt. Der Erfolg kommerzieller Projekte hängt dagegen viel stärker von Marketing, Partnerschaften und Branding ab. Dadurch wird in diese Bereiche oft mehr Zeit und Mühe investiert, als in das Tool selbst.

"You get what you pay for" ist daher beim Thema Open Source-Software ein klarer Trugschluss.

Open Source ermöglicht übertragbare Skills

Entwickler lernen gerne mit Open Source-Tools umzugehen, weil sie dieses Wissen auch in anderen Unternehmen nutzen können. Niemand möchte in seinem aktuellen Job feststecken, weil er zehn Jahre damit verbracht hat, sich das Know-how einer eklektischen Plattform anzueignen.

Auf den ersten Blick mag es vielleicht riskant erscheinen, dein Team im Einsatz von Tools zu schulen, die auch für andere Unternehmen wertvoll sind, wie z. B. Tensorflow und Kubernetes. Es ist jedoch der einzige nachhaltige Weg, um die besten Entwickler anzuziehen.

Außerdem profitiert dein Team auch anderweitig von diesen übertragbaren Fähigkeiten: Es ist viel einfacher, kompetente Berater oder Hilfe aus der Community zu bekommen, wenn du die gleichen Tools wie alle anderen verwendest.

Open Source-Lösungen sind modular aufgebaut

Kostenpflichtige Plattformen versuchen sich vor allem dadurch zu differenzieren, dass sie Allround-Lösungen bieten. Anstatt nur eine Trainingsplattform oder nur ein Deployment-Tool zu entwickeln, verkaufen sie sich als "All-in-One"-Lösungen oder "das einzige Tool, das dein Team braucht". 

Es ist jedoch komplett unrealistisch, in allen Bereichen die beste Lösung zu bieten. Außerdem macht es die monolithische Natur dieser Lösungen schwer, einzelne Komponenten durch bessere Alternativen auszutauschen. Wenn dein Team beispielsweise das beste Model-Registry nutzen möchte, kann es das oft nicht einfach in die bestehende Plattform integrieren.

Im Gegensatz dazu ist Open Source-Software differenzierter und legt einen starken Fokus darauf, mit anderen Plattformen zu integrieren. Eine Open Source-Lösung ähnelt also in gewisser Weise einem Lego-Baustein: Sobald ein Teil Schwierigkeiten macht, kann man es einfach herausnehmen und durch eine bessere Alternative ersetzen.

Versteckte Kosten bei proprietärer Software

Proprietäre Plattformen versuchen ihren bestehenden Kunden Upgrades und neue Funktionen zu verkaufen. Das bedeutet in vielen Fällen, dass sie ihre Limitierungen nicht von vorneherein offenlegen.

Während des Verkaufs überzeugt man dich also vielleicht davon, dass ein niedriger oder mittlerer Tarif perfekt zu deinen Bedürfnissen passt. Erst nach dem Kauf stellst du fest, dass strategisch wichtige Funktionen entfernt oder bestimmte Einschränkungen hinzugefügt wurden, die deinen Workflow so lange lahmlegen, bis du für das nächste Upgrade zahlst.

Außerdem können diese Plattformen ihre Preise ohne Vorankündigung erhöhen, sodass dein Team entweder alles neu programmieren muss, oder am Ende viel mehr bezahlt, als eingeplant war.

Wann macht es Sinn, proprietäre Plattformen einzusetzen?

Wenn dein Team nicht über viel technisches Fachwissen verfügt - besonders im Bereich DevOps und dem Aufsetzen und der Verwaltung einer Infrastruktur - dann kann die Einrichtung und Wartung von Open Source-Lösungen zur Herausforderung werden. 

Open Source-Tools werden in der Regel "von Entwicklern für Entwickler" entwickelt, sodass nicht-technische Teams (z. B. im Marketing) unter Umständen auch proprietäre Plattformen bevorzugen. 

Wenn du außerdem an eher kleinen, internen Projekten oder Proof-of-Concept-Anwendungen arbeitest, besteht normalerweise kein großer Bedarf an einer eigenen Infrastruktur.

Braucht dein Team Hilfe bei der Umstellung auf Open Source MLOps?

Wir sind darauf spezialisiert, Forschungsteams beim Aufbau von Open Source MLOps Infrastrukturen zu begleiten. Melde dich gerne bei uns, wenn du dabei Unterstützung suchst.