Warum FTP anstatt REST
Die Lokad-Plattform ist auf die Verarbeitung von Terabyte-Datenmengen ausgelegt und für prädiktive supply chain optimization konzipiert. Allerdings müssen wir zunächst Daten importieren, um diese auswerten zu können. Die meisten Webanwendungen verfügen über Web-APIs, die im REST-Stil gestaltet sind, doch Lokad bietet FTPS und SFTP, was überraschen mag1. Diese Wahl war nicht zufällig, sondern wurde durch Anforderungen an die Datenübertragungsleistung bestimmt. Obwohl diese Entscheidung vor einem Jahrzehnt auf bisherigen Erfahrungen beruhte, sind die Argumente zugunsten von FTP nach wie vor so stark wie eh und je.

Lassen Sie uns den Anwendungsfall von Lokad verdeutlichen. Ein typisches Kundenunternehmen muss eine vollständige Kopie von 10 bis 100 Datenbanktabellen, mit 5 bis 500 Feldern pro Tabelle, an sein Lokad-Konto übertragen. Diese Daten repräsentieren den Inhalt seines ERP, MRP, WMS, POS etc. Im Zeitablauf müssen die Kopien stets aktuell bleiben, in der Regel nicht älter als vom gestrigen Tag. Die Gesamtmenge der beteiligten Daten – bei Annahme unkomprimierter, flacher Textdateien (d.h. CSV) – reicht von 1 GB für ein mittelständisches Unternehmen bis zu 10 TB für ein großes Unternehmen. Durch die Einführung inkrementeller Datenübertragungen für die größeren Tabellen liegt das tägliche Transfervolumen typischerweise zwischen 100 MB und 10 GB.
Das Kundenunternehmen – oder dessen Softwareanbieter, oder der Integrator des Anbieters – muss in der Lage sein, die relevanten Daten zu Lokad zu übertragen. In den meisten Fällen erhält Lokad tatsächlich niemals IT-Zugriff auf ein Produktionssystem. Das ist nachvollziehbar: Aus Sicherheitsgründen sollten Drittfirmen, die Analysen durchführen, keinen direkten Zugriff auf Produktionssysteme haben. Das Kundenunternehmen muss als Wächter die Kontrolle über die aus seinem System fließenden Daten behalten. Ein zusätzlicher Vorteil ist, dass dadurch jedes einzelne Stück personenbezogener Daten herausgefiltert werden kann, welches ein Dritter wie Lokad ohnehin nicht benötigt.
In der Theorie kann REST beliebig leistungsfähig gemacht werden. In der Praxis ist dies jedoch nicht der Fall. Bei REST führt die zuverlässige Übertragung von 100 MB fein granulärer relationaler Daten täglich zwangsläufig zu enormen Performance-Overheads, sofern nicht ein erstklassiges Software-Engineering-Team beteiligt ist. Zwei Aspekte müssen mit äußerster Sorgfalt behandelt werden: die Anzahl der Netzwerkaufrufe (Chattiness) und Wiederholungsversuche (Retries). Mit “Chattiness” ist die Anzahl der Aufrufe über das Netzwerk gemeint. Mit “Retries” sind Verhaltensweisen gemeint, die notwendig sind, um mit temporären Netzwerkfehlern umzugehen. Beides ist schwierig und in der Praxis außerordentlich anspruchsvoll.
Im Unternehmensbereich schaffen es die meisten Softwareanbieter bekommen das Paging nicht einmal richtig hin für ihre eigenen APIs. Die Vorstellung, dass dieselben Anbieter, die eine schnelle und schlampige Integration von Lokad durchführen, plötzlich erstklassige Software-Engineering-Talente einsetzen, ist nicht realistisch. Meine Erfahrungen bei Lokad zeigen, dass eilige IT-Projekte das Beste sind, was Lokad erwarten kann. Das ist in Ordnung. Es gibt unzählige IT-Herausforderungen zu meistern. Realistischerweise kann nicht damit gerechnet werden, dass die Datenintegration von Lokad der eine Kampf ist, bei dem man die Elitekräfte einsetzen muss.
In der Praxis, wenn man unter dem Druck steht, eine anständige Leistung zu erzielen, verfallen Web-APIs in flache Dateiübertragungen über HTTP. Dieser Rückschritt adressiert den zuvor erwähnten “Chattiness”-Aspekt. Dennoch bleibt der “Retries”-Aspekt unberührt. Sobald auch dieser Aspekt behoben ist, herzlichen Glückwunsch – die API hat letztlich ein File Transfer Protocol (alias FTP) neu erfunden.
Dieses improvisierte FTP ist jedoch bei weitem nicht so umfassend ausgestattet wie das Original. FTP wird von allen gängigen Betriebssystemen unterstützt. Beide verfügen über umfangreiche Open-Source-Tooling-Unterstützung. Die entsprechenden Implementierungen sind seit Jahrzehnten produktionsreif. Zugegeben, es gibt Eigenheiten, und diese Protokolle mögen nicht mehr “in Mode” sein, aber wenn es darum geht, die Aufgabe innerhalb weniger Stunden zu erledigen, ohne Rockstar-Ingenieure einzubeziehen, kommt nichts dagegen.
Aus diesem Grund hat Lokad FTP übernommen, um sowohl eingehende als auch ausgehende Datenübertragungen zu unterstützen. Darüber hinaus hat ein Jahrzehnt Betrieb bewiesen, dass diese Wahl die richtige war. Selbst IT-Firmen mit gering qualifizierten, kostengünstigen, ausgelagerten Mitarbeitern schaffen es, große Mengen relationaler Daten schnell und zuverlässig per FTP an Lokad zu übertragen – was während all der Jahre, in denen wir eine Web-API angeboten haben, kein einziges Mal der Fall war.
-
Im Folgenden bezeichnet FTP, der der Kürze halber, stets “FTPS und SFTP”. Diese beiden Protokolle sind zwar sehr unterschiedlich, aber für diese Diskussion sind diese Unterschiede unerheblich. Die Bevorzugung eines Protokolls gegenüber dem anderen ist hauptsächlich eine Frage der Abstimmung mit den bereits bestehenden IT-Praktiken im betreffenden Unternehmen. ↩︎