MLOps - Ein strategischer Ausblick

Welche MLOps-Plattform wird sich durchsetzen?

Es gibt eine Vielzahl von Technologien und Plattformen, die gerade mit dem MLOps-Begriff den Markt unter sich aufteilen. Was wird daraus werden?

Eine konkrete Plattform zu wählen ist in jedem Fall eine individuell zu betrachtende IT-Strategie-Entscheidung. Dass es eine braucht, ist für jedes Unternehmen, das die ersten Schritte mit Machine Learning gemacht hat, mehr oder weniger offensichtlich geworden. Versuchen wir einmal die strategische Entscheidung zu erleichtern.

Zitat: Prognosen sind schwierig, besonders wenn sie die Zukunft betreffen! (Quelle unklar)

Argument 1: Fixkostendegression 

Die Fixkostendegression ist das Kern-Argument für MLOps-Werkzeuge generell. Machine-Learning-Projekte verursachen zwei Typen von Kosten:

• variable Kosten, die pro entstehendem Projekt und pro betriebenem Modell anfallen
• fixe Kosten, die die unabhängig davon anfallen (vor allem für Infrastruktur, Weiterbildung, IT-Sicherheit).

MLOps-Werkzeuge versprechen aus der Kostensicht mit etwas höheren Fixkosten die variablen Kosten zu senken. Das gelingt vor allem durch die Standardisierung von Abläufen, Rollen und Komponenten und ist ein sehr starkes Argument. Für Entscheidungsträgerinnen reduziert sich die Auswahl einer geeigneten Plattform mit diesem Argument auf die Suche nach einigen wenigen Zahlen. Insbesondere: "Wie viele ML-Modelle werden wir in fünf Jahren entwickeln und betreiben?" und "Wie sind die variablen und fixen Kosten der MLOps-Plattformen?"

Das ist sicher leichter gesagt als getan. Interessant ist hier ein Blick auf die Extremwerte: 

• DataRobot ist eine eher geschlossene Plattform mit einem Preismodell, dass sich an betriebenen Modellen orientiert. Hier wird ein Großteil der Fixkosten auf das Risiko des Plattformanbieters zu variablen Kosten umgemünzt - das Risiko und die Fixkosten müssen mitbezahlt werden, der variable Kostensatz ist folglich eher hoch.
• Auf der anderen Seite der Fixkosten-Skala steht Googles Kubeflow: Es ist ein offenes System und bietet alle Freiheiten und Optionen sowie die Integrationsoptionen des Kubernetes-Ökosystems, in der Cloud oder On-Premise. Das bringt aber einen relevanten Fixkostenblock mit, der sich erst mit mehr als einer Hand voller ML-Projekte amortisiert.

Irgendwo werden sich die beiden Geraden schneiden und die Entscheidung kippen; Kubeflow ist wie die Siebträger-Kaffeemaschine, DataRobot wie eine mit Kapsel-Portionen. Weil die Parameter dafür aber schwer zu schätzen sind, blicken wir auf weitere Argumentationen, um die Entscheidung für MLOps-Tools zu fällen. 

Argument 2: Dominantes Design 

Über die Idee von Dominanten Designs kann man die Entscheidung für IT-Architekten entschärfen. Die Theorie aus den 70'ern beschreibt das Ford Model-T ebenso treffend wie die Entwicklung der VHS-Videokassette oder das Layout und Bestellprozessen bei Online-Shops:

1. Es gibt eine Phase intensiven Wettbewerbs im Umfeld von disruptiven Innovationen.
2. Daraus geht ein Dominantes Design hervor, dass sich aus den Erwartungen der Nutzer:innen speist und stabilisiert.

Wichtig zu verstehen ist, dass ein Dominantes Design nicht als "perfektes Design" zu verstehen ist. Die Erwartungen und Netzwerkeffekte tragen das Produkt. Der Gestaltungsraum für Fahrzeuge, Video-Wiedergabe und Online-Shops ist riesig. Es macht aber ab einem gewissen Verbreitungsgrad keinen Sinn mehr, Nutzer:innen zu überraschen oder ein Mitdenken zu erwarten. Der Betamax-Videostandard war einige Zeit der VHS-Kassette sichtbar überlegen, das reichte aber nicht aus, um das strategische Handeln einzelner und die Netzwerkeffekte zu überwinden.

Wie sieht das entstehende Dominante Design für MLOps aus?

1. Es ist ein Framework für zwei Zielgruppen: Starke Standards und Erweiterbarkeit werden gleichzeitig angestrebt. Methodenspezialistinnen werden ebenso als Zielgruppe adressiert wie das Operations-Team (die Brücke zwischen beidem zu schlagen ist Kern der MLOps-Idee, Übergaben oder Reifungsprozesse dürfen gern ohne Technologiebruch stattfinden).
2. Es nutzt die Kubernetes-Plattform und Verarbeitungsschritte finden in Containern statt (K8s ist als Rahmenbedingung oft schon gesetzt, Compute- und Storage-Reserven sind in definierter Weise erreichbar).
3. Machine-Learning-Code und seine Integration finden in Python statt, es gibt aber viel Freiheit fürData Scientists auch mit anderen Sprachen (die Entwicklung von ML-Algorithmen und deren Implementierungen ist vielfältig und schnelllebig. Kernaufgabe fast jeder IT-Architektur ist, schnell veränderliche von langsam veränderlichen Dingen sinnvoll zu trennen).
4. Die Kompatibilität der vielen beteiligten Open Source-Komponenten handhabbar zu machen ist Kern des Werteversprechens - mit eigenen Implementierungen ist außer für "Glue Code" nicht zu rechnen (die Open Source-Werkzeuge für Algorithmen und Basis-Technologien wie GitOps etc. haben die Innovationsführerschaft und sind zwar gratis, deren Integrations- und Wartungsaufwand lässt sich durch MLOps-Frameworks aber gut teilen).
5. Machine-Learning-Prozesse werden als DAG orchestriert, die sich als "Infrastructure as Code" beschreiben, kombinieren und versionieren aber auch grafisch darstellen lassen (nur so lässt sich Übersicht sinnvoll waren - es gibt Überschneidungen zum Siegeszug der Low-Code-Prozessautomatisierung).

Dieses Design findet sich bei Google's Kubeflow ebenso wie bei Azure ML, Amazon SageMaker, Airflow und weiteren, mit kleinen Unterschieden im Detail.

Folgt man der Dominant Design-Theorie ergibt sich eine gute Nachricht darin: Die Unterschiede werden eher noch kleiner. Ein Investment in Ausbildung in der Nähe des Dominant Designs erscheint unabhängig davon wie sich die Marktanteile entwickeln sehr sicher. Alle haben einen Anreiz den Wechsel von Entwicklungsteams sehr einfach zu gestalten. Das wird so lange weitergehen, bis es zu einer disruptiven Innovation kommt. Naturgemäß ist diese allerdings nicht in Sicht.

Die zweite Vorhersage aus dieser Perspektive wäre: Unternehmen, die nicht dem Dominanten Design folgen, werden den Markt verlassen (oder sich zumindest anpassen, das Spielfeld wechseln oder nur nach Anpassungsfähigkeit sortiert Erfolg haben). Mit diesem Argument lässt sich die Shortlist der zukunftssicheren Optionen schon etwas eingrenzen.

• Microsofts Azure ML und Googles Kubeflow haben das Dominante Design herausgebildet. Das macht sie zu einer eher sicheren Option. → Sie können, in Grenzen, das Dominante Design weiter verfeinern.
• DataRobot fokussiert sowohl technisch als auch im Marketing nur Fachanwender und versuchen soweit zu vereinfachen und zu standardisieren, dass die eigentliche MLOps-Idee einer Brücke zwischen Data Science und Software Engineering / Betrieb nicht individuell adressiert werden muss. Dieses hohe Maß an Standardisierung ist ebenfalls für das Kern-Feature "AutoML" der Data Robot-Plattform notwendig, deren Strategie damit gut nachvollziehbar ist. Sie ist eine Strategie der "niedrig hängenden Früchte" - der Weg von AutoML zu einem MLOps der "niedrig hängenden Früchte" war für sie relativ leicht. Eine Anpassung an das Dominate Design erscheint schwer, weil sie sowohl eine Neuausrichtung der Zielgruppen als auch mehr Flexibilität erforderlich macht, dass die aktuellen MLOps und AutoML-Services konzeptuell erlauben. → Es ist mit starken Anpassungen oder einem Nieschenprodukt zu rechnen.
• Apache Spark / DataBricks zeigen schon deutliche Anpassungen an das Dominante Design. Über PySpark und eine Einbettung in das Azure-Ökosystem rückt die Spark-Welt mit dem Fokus auf sehr große Datenmengen mit verteilter Bearbeitung im Hadoop-Stil näher an das dominante Design heran. Spark ist mit seinem dediziertem Cluster und dem Scala-Interface technologisch ein Fremdkörper in der MLOps-Perspektive, hat sich aber schon weit genug angepasst, um nicht als störender Fremdkörper zu wirken.
• RapidMiner und Knime sind Werkzeuge, die schon früh auf die graphische Darstellung von Datenflüssen gesetzt haben, dies aber nicht im Sinne eines "Infrastructure as Code". Das macht die Wiederverwendung von Komponenten, die Navigation in großen Projekten und das Versionsmanagement schwerer. Mit den Kubernetes Job-Agents sieht RapidMiner dem Open Source-Kern und den vielen Freiheiten sieht RapidMiner dem Dominanten Design ansonsten recht ähnlich. 

Argument 3: Netzwerk-Effekte 

Wie bei den Video-Kassetten und Fax-Geräten tritt die Qualität eines konkreten Produktes manchmal in den Hintergrund und die Qualität des Netzwerkes steht im Vordergrund: Wo kann ich Video-Kassetten für meinen Recorder bekommen? Wem kann ich ein Fax schicken?

Netzwerk-Effekte spielen auch im MLOps-Markt eine Rolle. Google versucht die Netzwerk-Effekte durch ihren Marktplatz von Kubeflow-Verarbeitungsschritten explizit zu fördern. Algorithmia und https://dagshub.com sind ein ähnliche Versuche. Es wird aber auch bilaterale Netzwerk-Effekte geben, bspw. zwischen Großunternehmen und ihren Dienstleistern.

In Summe ergibt sich aus diesem Argument die folgende Prognose: Es wird sich die MLOps-Umgebung durchsetzen, die das Zusammenarbeiten und Wiederverwenden von Komponenten über Unternehmensgrenzen hinweg am meisten fördert.

Wichtig dabei ist zu verstehen, dass eine Komponente idealerweise kein isoliertes ML-Modell ist, wie es ein "Stück Software" in der klassischen Entwicklung wäre. Das wird dem Anspruch an Reproduzierbarkeit und Transparenz nicht gerecht, sofern man diese Ansprüche hat (oder gesetzlich haben muss) und nicht individuelle KI-Aufgaben bearbeitet, für die sich nicht ohnehin vortrainierte Modelle eignen (Objekterkennung, Sentiment-Analyse etc.). Das wird aber für viele MLOps-Anwenderinnen nicht der Fall sein, denn die Investition in MLOps Infrastruktur und Fertigkeiten lohnt ohnehin nur, wenn individuelle Lösungen benötigt werden.

Argument 4: Spieltheorie

Wenn es um strategisches Handeln geht, ist die Spieltheorie nicht weit. Für die Bewegung im MLOps-Marktsegment kommt das als erstes Hotellings Gesetz in den Sinn. 

Ein Gedankenexperiment: Wir wollen an einem Strand (der 1 km lang ist und gleichverteilt Gäste bekommt) einen Eis-Kiosk aufstellen und müssen einen optimalen Ort zum Aufbauen wählen. Wir sehen am anderen Ende des Strandes aber schon unsere Konkurrenz mit Kiosk-Material vor der gleichen Frage stehen. Wo bauen wir unseren Kiosk auf? 

Hierzu gibt es ein soziales Optimum: Wir laufen nur 250m und der Kollege auch. In der Konsequenz muss niemand am Strand mehr als 250 m laufen, um ein Eis zu kaufen. Das soziale Optimum ist aber nicht das strategische Optimum. Wenn ich es für meinen Eisstand wählen würde, könnte die Konkurrenz uns einfach entgegenkommen und letztlich 3/4 der Kundschaft bedienen. 
Daraus folgt das strategische Optimum: Beide stehen in der Mitte auf der 500m-Marke nebeneinander. Dieses Setting ist strategisch stabil: Niemand kann aus dieser Situation heraus umziehen und dadurch mehr Kunden erreichen (ein Nash-Gleichgewicht). Mit sehr wenigen Annahmen erscheinen die Positionen von Kaufhäusern in deutschen Innenstädten genauso plausibel wie die politische Positionierung von CDU, CSU und SPD im Bundestagswahlkampf: Sich ähnlich zu positionieren ist, wenn die Beteiligten unabhängig entscheiden müssen, die einzig sichere Strategie, um am Spiel teilzunehmen.

Schauen wir mit dieser methodischen Brille auf den MLOps-Markt stellen wir fest:

• Kubeflow war eine innovative Open Source-Lösung von Google.
• Sie wird mittlerweile unterstützt von Amazon, Cicso, Microsoft, Weights & Biases, Red Hat, Intel, Uber, Huawei und weiteren Partnern.
• Kubeflow hat eine um etwa den Faktor 10 größere Anzahl von Contributors als das nächstgrößere MLOps-Produkt.

Es scheint, dass ein Beitragen zur Kubeflow-Plattform für die großen Cloud-Anbieter eine dominante Strategie ist.

Warum ist das so? Sie verdienen oft an der Infrastruktur, nicht an Lizenzen - für sie ist es strategisch nicht notwendig, Innovationsführerin zu sein, solange die Plattform der Wahl mit ihren Cloud-Diensten kompatibel ist. Gleiches gilt für Red Hat. Man möchte aber auch nicht den fahrenden Zug verpassen: Ein moderates Investment in das Kubeflow-Ökosystem (insb. um Wissen aufzubauen und Kompatibilität sicherzustellen), ist weniger teuer und weniger riskant als ein innovativer Alleingang oder auch nur der Versuch, die Integrationsleistung von einem Pool von Open Source-Tools selbst besser hinzubekommen (ohne das o.g. Dominate Design zu verletzen).

Was bedeutet das für IT-Architektinnen? Das spieltheoretische Modell sieht keinen Zeitverlauf vor - ein gefundenes Gleichgewicht gilt als Erwartungshaltung, solange die gemachten Annahmen halten. Das würde bedeuten, wir rechnen mit einer längeren Phase der Stabilität. Gleichgewichte erzeugen Stabilität. Vielleicht ist jetzt, wo Stabilität in Sicht ist, der richtige Zeitpunkt gekommen, eine MLOps-Richtungsentscheidung zu treffen? Etwas Ähnliches ist bereits mit dem Linux-Betriebssystem geschehen.

Was ist Ihre Prognose? Welche weiteren Argumente sehen Sie?

Sprechen wir gern einmal im MLOps-Seminar darüber? 

Unsere Leistung:

MLOps - KI produktiv einsetzen

Die viadee IT-Unternehmensberatung berät und unterstützt Unternehmen beim produktiven Einsatz von KI und Machine Learning. Von der Strategie- und Architekturentscheidung für MLOps-Plattformen bis zur Umsetzung on Datenversorgung, Pipelines und Betrieb. Erfahren sie mehr über unsere Leistungen im Bereich MLOps und produktiven Einsatz von KI.