Warum nicht Python

Joannes Vermorel

Vor Jahren, aber auch Jahre nach der Gründung von Lokad, wurde mir klar, dass keine einzelne App jemals etwas annähernd Großartiges in Bezug auf supply chain Optimierung liefern würde. Wir haben unser Bestes gegeben, aber es war nicht genug. Egal, wie viele Funktionen wir in die frühesten Versionen von Lokad einfließen ließen, jeder neue Kunde schien verzweifelt ganz anders zu sein als alle bisherigen, die wir bislang abdecken konnten. Supply chain challenges sind einfach zu vielfältig und zu chaotisch, um in eine vernünftige Anzahl von Menüs, Schaltflächen und Optionen gepresst zu werden.

Tatsächlich erkennen die meisten unserer Mitbewerber diese Situation an und folgten dem Weg, Softwareprodukte zu entwickeln, die mit einer verrückten Zahl von Menüs, Schaltflächen und Optionen ausgestattet sind – alles in einem verzweifelten Versuch, alle supply chain challenges zu bewältigen. Leider führt dieser Weg zu Softwaremonstrositäten, die zu spektakulären Misserfolgen werden, wenn sie in großem Maßstab eingesetzt werden. Ich bezeichne dieses Anti-Pattern als den Non-Euclidian Horror.

So, angesichts einer Klasse von Problemen – also supply chain challenges – die einfach nicht mit einer einzelnen App gelöst werden konnten, begannen wir, teils zufällig¹, das Meta-Problem anzugehen: Wie man maßgeschneiderte Apps bereitstellt, bei denen jede App der Lösung eines einzelnen Problems für eine bestimmte Situation gewidmet ist, z. B. der Optimierung der Lagerauffüllung für ein bestimmtes Unternehmen.

Maßgeschneiderte Software für Unternehmen bereitzustellen, ist nichts Neues. Die Softwareindustrie begann in den 60er Jahren so und entwickelte sich später in den 80ern hin zum dominanten shrinkwrap model, das wir heute kennen. In der Regel weist maßgeschneiderte Software im Vergleich zu shrinkwrap viele unerwünschte Eigenschaften auf: höhere Anfangsinvestitionen, lange Einrichtungsphasen, höhere Wartungskosten, höhere Risiken usw.

Doch die Erfahrungen, die ich in den ersten Jahren von Lokad gesammelt hatte, zeigten, dass maßgeschneiderte Software, was die supply chain Optimierung betrifft, einen einen entscheidenden Vorteil hatte: Sie lieferte tatsächlich großartige Ergebnisse. In der Tat, während unsere ursprüngliche App bestenfalls annehmbare Ergebnisse² erzielte, ganz gleich, wie genau die Prognosen waren, erzielten diese Prototypen häufig großartige Leistungen. Darüber hinaus bestand der einzige Trick darin, dass es auf die extreme Spezialisierung der Software-Anwendung ankam, die für das jeweilige Problem vorgesehen war.

Nachdem wir scheinbar alle Alternativen ausgeschöpft hatten, kamen wir zu dem Schluss, dass die Bereitstellung maßgeschneiderter Apps der einzige Weg war. Dennoch waren Skalierbarkeit – also wie man viele Apps bereitstellt – und Wartbarkeit – also wie man die Wartungskosten unter Kontrolle hält – zwei zentrale Anliegen. Zunächst mussten wir eine Programmiersprache wählen. Damals haben wir viele Optionen in Betracht gezogen: R, Python, JavaScript, Lua, C#, … sowie die Entwicklung unserer eigenen domänenspezifischen Programmiersprache (DSL), die später als Envision bekannt werden sollte. Die Vor- und Nachteile all dieser Optionen zu diskutieren, wäre etwas mühsam gewesen³, daher beschränkte sich die Diskussion der Klarheit halber auf die Wahl zwischen Python und Envision, wobei Python der stärkste Konkurrent zur Einführung unserer eigenen DSL war.

Python war ansprechend wegen seiner Einfachheit und seines reichen Ökosystems an Drittanbieter-Bibliotheken, insbesondere im Bereich des Machine Learning⁴. Es war zudem eine kostengünstige Option für Lokad: Da Python und nahezu alle seiner populären Bibliotheken open source sind, hätten wir einfach eine enge Teilmenge von Python neu verpackt, indem wir ein paar Dutzend handverlesener Pakete auswählten, und damit wären wir fertig gewesen. Der Großteil der Arbeit bei Lokad hätte sich darauf konzentriert, eine PaaS-Erfahrung rund um Python à la Heroku zu liefern – so maßgeschneidert wie möglich in Hinblick auf supply chain challenges.

Doch hier ist ein Lackmustest, den wir in Betracht zogen: War es vernünftig zu erwarten, dass ein Business Analyst – später bekannt als Supply Chain Scientist – der 1 Tag pro Woche für 6 months arbeitet, eine produktionsreife App zur Lösung eines geschäftskritischen supply chain challenge, wie der Lagerauffüllung, für ein Unternehmen im Wert von $10M liefern würde? Betrachtet man die Python-Option, war klar, dass wir niemals auch nur annähernd an ein solches Maß an operativer Effizienz herankommen würden.

Erstens, Python erfordert Softwareingenieure. Tatsächlich offenbart Python, wie jede vollwertige Programmiersprache, eine Menge technischer Feinheiten für jeden, der in Python Code schreibt. Obwohl die Rolle des supply chain scientist erst später formell definiert wurde, hatten wir früh die Intuition, dass es selbst bei klugen, talentierten Menschen zu viel verlangt wäre, von ihnen zu erwarten, dass sie sowohl Experten im supply chain Engineering als auch Experten in der Softwareentwicklung sind. Wir benötigten programmatische Fähigkeiten, die einem breiten Spektrum technisch versierter Menschen zugänglich sind – und nicht nur professionellen Softwareingenieuren.

So haben wir Envision als Sprache entwickelt, um ganze Klassen technischer Probleme zu eliminieren, die mit Python unvermeidbar sind. Zum Beispiel:

• Objekte können null sein, Daten können absurd weit in der Vergangenheit oder in die Zukunft liegen, NaN kann freudig durch deine Datenpipeline propagieren, und Strings können absurd groß werden… In supply chain sind diese „Features“ nichts weiter als Probleme, die darauf warten, aufzutreten.
• Objektorientierte Elemente (d. h. Klassen) werden garantiert missbraucht⁵, und dasselbe gilt für benutzerdefinierte Ausnahmen oder Regexes. Das bloße Vorhandensein dieser Elemente ist bestenfalls eine ungesunde Ablenkung.
• Mehrere grundlegende Operationen, wie das Parsen unterschiedlicher tabellarischer Dateien (einschließlich Excel-Tabellen), gehören nicht zur Sprache und erfordern den Umgang mit vielen verschiedenen Paketen, von denen jedes seine eigenen technischen Feinheiten aufweist.

Keine dieser Klassen technischer Probleme kann aus Python entfernt werden, ohne die Sprache selbst lahmzulegen. Envision als Programmiersprache ist für supply chain specialists (im Gegensatz zu software specialists) nur deshalb zugänglich, weil es sich mit messerscharfem Fokus auf predictive supply chain optimization problems befasst.

Denken Sie an das letzte Mal, als Sie Berechnungen mit einer Excel-Tabelle durchführen mussten, und stellen Sie sich vor, Sie würden all die Änderungen, die Sie an dieser Excel-Tabelle vorgenommen haben, telefonisch diktieren, ohne die Tabelle selbst sehen zu können. So sieht eine von Praktikern getriebene, aber von Softwareingenieuren (keine supply chain specialists) umgesetzte supply chain-Optimierungsinitiative aus. Das Geschäft investiert enorme Mengen an Zeit, um IT mitzuteilen, was es möchte; und IT verbringt ebenso viel Zeit damit, herauszufinden, was das Geschäft will. Nach einem Jahrzehnt Erfahrung bei Lokad beobachte ich, dass das Vertrauen auf Softwareentwickler, die keine supply chain specialists sind, um eine die Quantitative Supply Chain Optimierungsinitiative umzusetzen, die Kosten um mindestens den Faktor 5 vervielfacht, egal wie agil und talentiert das Softwareteam auch sein mag.

Zweitens gehen die Wartungskosten von übereilten Python-Prototypen durch die Decke. Außerhalb der Softwarebranche ist sich nur wenigen bewusst, dass Software Engineering hauptsächlich darin besteht, die Wartungskosten unter Kontrolle zu halten. Doch das Lösen von supply chain optimization problems ist ein chaotischer Prozess: Die Daten aus vielen (schlecht) zuverlässigen Systemen müssen zuverlässig in Pipelines eingespeist werden, unvollkommene und sich ständig ändernde Prozesse müssen dokumentiert und modelliert werden, und die Optimierungsmetriken spiegeln eine Geschäftsstrategie in einem ständigen Wandel wider, usw. Infolgedessen enthält jedes Softwarestück, das zur Umsetzung der supply chain optimization geschrieben wird, immer eine gewaltige Dosis domänenspezifischer Komplexität, die lediglich versucht, mit dem umzugehen, was die Welt uns entgegenwirft.

Doch Zeit ist von entscheidender Bedeutung. Es hat keinen Sinn, den perfekten Plan für den Produktionsplan des letzten Jahres zu haben. Als Faustregel kann man davon ausgehen, dass an dem Tag, an dem der Software-Prototyp zu funktionieren beginnt, er in wenigen Wochen in die Produktion überführt wird – egal, ob der Prototyp gut oder schlecht geschrieben ist.

Zu erwarten, dass das obere Management eine sechsmonatige Verzögerung genehmigt, um den Prototyp neu zu schreiben und aus Wartungssicht produktionsreif zu machen, ist Wunschdenken. Dennoch ist das In-Betrieb-Nehmen eines übereilten Python-Prototyps das Rezept für epische Wartungskosten, ein aussichtsloser Kampf gegen einen unaufhörlichen Strom von Bugs, der rund um die Uhr notdürftig geflickt werden muss.

Daher ist der einzige praktikable Weg, die Produktion im Zaum zu halten, den Prototyp mit einer Programmiersprache zu schreiben, die ein hohes Maß an Korrektheit by Design gewährleistet. Zum Beispiel liefert Envision, im Gegensatz zu Python:

• Endliche Ausführungszeit garantiert zur Compile-Zeit: Beim Verarbeiten mehrerer Terabytes an Daten wird es sehr mühsam, stundenlang zu warten, bis man merkt, dass eine Berechnung einfach niemals enden wird. Begrenzter Speicherverbrauch, garantiert zur Compile-Zeit: Sich mit Out-of-Memory-Fehlern in der nächtlichen Produktionsausführung herumzuschlagen, ist alles andere als spaßig und stört in der Praxis den Betrieb erheblich.
• Atomare Lese- und Schreibzugriffe: Envision verhindert von vornherein gleichzeitige Lese- und Schreibzugriffe im Dateisystem, selbst wenn Dateien per FTP übertragen werden, während Skripte ausgeführt werden. Das Dateisystem, das Envision unterstützt, ist so etwas wie ein Git, das für gigantisch große Flachdateien maßgeschneidert ist. Ohne eine ordnungsgemäße data Versionierung werden viele Bugs zu Heisenbugs: In dem Moment, in dem jemand das Problem näher untersucht, wurden die Daten bereits aktualisiert, und das Problem lässt sich nicht mehr reproduzieren.
• Ambient scale-out Ausführung des Programms über eine cloud von Rechenressourcen, die alle Parallelisierungsbarrieren beseitigt, die unweigerlich auftreten, sobald die Daten einige Dutzend Gigabytes überschreiten.

Generische Programmiersprachen bieten wenig Korrektheit by Design; und Python, das stark im Bereich des Late Binding angesiedelt ist, liefert in diesem Bereich außerordentlich wenig. Selbst wenn man bessere Alternativen – aus der Perspektive der Korrektheit by Design – wie Rust in Betracht zieht, sind diese Alternativen bei der supply chain optimization bei weitem nicht zufriedenstellend.

Hier sind noch einige weitere Bereiche, in denen Envision in einer Weise glänzt, die mit Python einfach nicht erreichbar ist:

Defence in-depth: Sobald jemand in Ihrer Organisation damit beginnt, Code zu schreiben – sofern nicht ganz besondere Vorsichtsmaßnahmen getroffen werden – wird dessen Code aus der IT security Perspektive zu einer unmittelbaren Belastung. Mit Python ist es im Grunde möglich, alles auf dem Rechner zu machen, auf dem das Python-Skript läuft. Python ordnungsgemäß in einer Sandbox unterzubringen, ist in der Praxis ein höllisch kompliziertes Problem. Insbesondere ist jede vom Python-Skript erzeugte Zeichenkette ein potenzieller Injektionsvektor. Während SQL-Injektionen berüchtigt sind, erkennen (leider) zu wenige Menschen, dass selbst einfache Flachtextdateien wie CSV anfällig für Injektionsangriffe sind. Envision liefert ein Maß an Sicherheit, das mit Python einfach nicht reproduziert werden kann. Datenlecks nehmen zu, und das Herumwerfen von Python-Codefragmenten wird der IT security keinerlei Nutzen bringen.

Transparente Performance: Wenn ein Programm unpraktikabel langsam läuft, dann sollte es erst gar nicht kompiliert werden. Wird ein Programm um nur eine Zeile verkürzt, so sollte es schneller laufen. Wird nur eine einzige Zeile geändert, so sollte nur diese Zeile bei der erneuten Ausführung des Programms über dieselben Daten neu berechnet werden. Beim Kompilieren sollte der Compiler nicht auf irgendeine bestimmte Maschine zielen, sondern auf eine cloud von Rechenressourcen, die eine automatische, datengesteuerte Parallelisierung ermöglicht. Envision geht einen großen Schritt in Richtung der Bereitstellung all dieser Eigenschaften standardmäßig und ohne jeglichen Programmieraufwand. Im Gegensatz dazu erfordert es einen massiven Einsatz spezialisierter Bibliotheken in Python, um auch nur annähernd solche Eigenschaften zu erreichen.

Transparentes Upgrade: Der aktuelle Stand der Technik ist im Bereich Software ein sich ständig bewegendes Ziel. Im Jahr 2010 war das beste Machine-Learning-Toolkit SciPy (arguably). Im Jahr 2013 war es scikit. 2016 war es Tensorflow. 2017 war es Keras. 2019 war es PyTorch. Es gibt ein Sprichwort im Software Engineering, dass man das Geburtsjahr eines Softwareprojekts an dessen Software-Stack und Abhängigkeiten ablesen kann. Tatsächlich, sobald Sie Ihre eigenen Python-Skripte ausrollen, binden Sie mehrere Abhängigkeiten ein, die nicht gut altern. Im Gegensatz dazu nutzen wir mit Envision umfangreich automatisierte Code-Neuschreibungen, um die „legacy“ Skripte mit einer sich ständig verändernden Sprache aktuell zu halten.

Packaged stack: Python-Skripte können nicht in einem Vakuum existieren. Der Code muss versioniert werden (z. B. Git) mit Zugriffsrechten (z. B. GitHub). Sie benötigen eine Umgebung zum Ausführen, die nicht Ihr eigener Rechner ist (z. B. eine Linux VM in der cloud). Ein Scheduler wird benötigt, um die Datenpipeline zu orchestrieren (z. B. AirFlow). Eine verteilte, spaltenorientierte Speicherlösung wird für die Datenvorbereitung benötigt (z. B. Spark). Ein Machine-Learning-Toolkit wird für predictive analytics benötigt (z. B. TensorFlow). Ein Optimierungstoolkit wird benötigt, um sich mit supply chain combinatorischen Problemen auseinanderzusetzen (z. B. GLPK). Die Rohdaten müssen irgendwo für eine spätere Verwendung bereitgestellt werden (z. B. SFTP-Server). Andere supply chain practitioners müssen in der Lage sein, das Geschehen zu überwachen (z. B. eine Web-Benutzeroberfläche). Zugriffsrechte müssen durchgesetzt werden (z. B. Active Directory), usw. Envision bündelt all dies in einer einzigen Meta-App und nimmt Ihnen die Last ab, Dutzende von Softwarekomponenten zusammenstellen zu müssen, um selbst die einfachste App bereitzustellen.

Dann, obwohl es eine ausgezeichnete Sprache ist, ist Python nicht ohne Tadel:

• Die Rechenleistung ist schlecht, und es ist ein mühsamer Kampf, jede einzelne Berechnung durch die richtige Bibliothek (z. B. NumPy) zu leiten, um eine katastrophal schlechte Performance bei datenintensiven Aufgaben zu vermeiden. Außerdem führt die Verwendung mehrerer Bibliotheken häufig zu erheblichen Reibungsverlusten, wenn Daten von einer in die nächste bewegt werden müssen.
• Die Speicherleistung ist ebenfalls schlecht, und insbesondere ist die referenzzählende Garbage Collection von Python veraltet – und alle neueren Programmiersprachen wie Java, C# oder JavaScript verwenden stattdessen Tracing. Bei speicherintensiven Aufgaben mit Big Data tut dies weh.
• Das Paketmanagement in Python war ein Chaos seit langem und es bedarf eines Paket-Spezialisten, um es richtig hinzubekommen. Außerdem wurde dieses Problem durch Upgrades der Programmiersprache mit hoher Reibung noch verschärft.
• Die meisten (wenigen) Korrektheitsprüfungen erfolgen nur zur Laufzeit, wenn das Programm ausgeführt wird, was bei der Verarbeitung großer Datenmengen zu endloser Frustration führt. Offensichtliche Probleme zeigen sich erst nach mehreren Minuten Ausführung, was die Produktivität mindert.

Zusammenfassend, obwohl Python großartig ist (das ist es), ist es keine befriedigende Lösung für die supply chain-Optimierung. Es ist zwar durchaus möglich, eine produktionsreife Machine Learning App in Python zu entwickeln und zu warten, aber die Kosten sind erheblich, und sofern Ihr Unternehmen nicht bereit ist, zumindest ein kleines Software-Engineering-Team für die Wartung dieser App bereitzustellen, wird das Ganze keine zufriedenstellenden Ergebnisse für Ihre supply chain liefern.

Die Entwicklung von Envision, einer domänenspezifischen Programmiersprache, die der prädiktiven supply chain-Optimierung gewidmet ist, war nicht unsere erste Wahl. Es war nicht einmal unsere zehnte Wahl. Es war vielmehr die einzige funktionierende Lösung, die wir nach einer langen Liste konventioneller Alternativen über fünf Jahre hinweg fanden. Sieben Jahre später und nach vielen Kundenunternehmen überrascht uns jeder neue Kunde immer noch, auf die eine oder andere Weise, mit einem weiteren Twist in ihrer supply chain, den wir mit einem klassischen enterpriseware-Ansatz niemals hätten bewältigen können. Programmierbarkeit war erforderlich, aber Python war nicht die Lösung, die wir benötigten.