Low-Code-Plattformen: ein Allheilmittel oder eine riskante Wette?

Low-Code-Plattformen (Low Code Application Platform, LCAP) entstanden als Reaktion auf die Komplexität und Vielfalt moderner Softwareentwicklungstools.


Einer der bekanntesten Akteure in diesem Bereich ist laut Gartner Mendix . Der Verkauf von Siemens für 700 Millionen US-Dollar bestätigt dies. Ich werde diese Plattform als Beispiel verwenden, obwohl ähnliche Schlussfolgerungen für Outsystems, Appian, Kony, Betty Blocks und andere gelten.


Bild


Da der Vertrieb auf Top-Manager ausgerichtet ist, versprechen Anbieter von Low-Code-Plattformen, dass auch normale Benutzer in der Lage sein werden, Geschäftsanwendungen selbst zu erstellen.


Das heißt, Entwickler werden nicht mehr benötigt ?!


Nun ... nach ein paar Jahren muss Mendix zugeben:


text
"Jetzt brauchen Entwickler mehr denn je."


Das ist eine Wendung!


Es scheint, dass Mendix erkannt hat, dass für etwas, das schwieriger ist als die grundlegende Arbeit mit Daten, immer noch ein professioneller Entwickler erforderlich ist, genau wie ein professioneller Mechaniker, der ein Auto wartet.


Leider sind moderne Low-Code-Plattformen einfach nicht für Entwickler gedacht, und auf lange Sicht ist es für Unternehmen riskant, sich auf sie zu verlassen. Wenn Ihr Unternehmen ernsthaft den Einsatz von Low-Code-Plattformen im industriellen Betrieb in Betracht zieht, lohnt es sich, diese Lösung erneut abzuwägen. Im Folgenden werde ich versuchen, dies zu argumentieren.


Tolles Werkzeug für das Prototyping


Mendix ist eine großartige Option zur Automatisierung einfacher Prozesse oder Prototypen, die Analysten oder fortgeschrittenen Anwendern zur Verfügung steht.


Mit dem visuellen Editor können Sie das Datenmodell beschreiben, mit einer Reihe von Widgets und Vorlagen schnell Bildschirme erstellen und sogar die Logik mit den sogenannten Mikroflows beschreiben :


text


Nach Abschluss können Sie Ihre Anwendung mit einem Klick in der Mendix-Cloud bereitstellen und mit der Arbeit beginnen. So einfach, dass es nach Magie klingt! Und es sieht so aus, als würde es sich gut verkaufen.


Nach dem Durchlaufen der Prototypenphase ist die Interaktion des Systems mit dem Benutzer und der Geschäftslogik jedoch fast zwangsläufig kompliziert. Um das Projekt weiterzuentwickeln, ist ein Fachmann erforderlich. Schauen wir uns also Mendix mit den Augen eines Entwicklers an.


Langsame Entwicklung


Jede Logik - sei es Computing oder Benutzerinteraktion - sollte in einem Ablaufdiagramm wie oben dargestellt beschrieben werden.


Hier gibt es mehrere Probleme.


Erstens ist es eine lange Zeit . Offensichtlich ist es in einer guten IDE schneller, 10 Codezeilen zu schreiben, als Dutzende von Blöcken per Drag & Drop zu verschieben, anzupassen und zusammenzufügen.


Zweitens die Lesbarkeit . Blöcke sehen wunderschön aus, aber was bedeutet diese Sub_RegistrationValidation ? Es ist unmöglich, dies zu verstehen, ohne in den Block zu fallen. Sobald die Anzahl der Blöcke auf einige zehn ansteigt, wird es äußerst schwierig, die Logik zu verstehen.


Als Alternative für komplexe Fälle unterstützt Mendix Java-Codeaufrufe von Microflows. Sie können Code in Eclipse schreiben, was im Allgemeinen gut ist, obwohl viele eine populärere IDE bevorzugen. Der Nachteil ist die mangelnde Transparenz: Alle Eintrittspunkte befinden sich in Mikroflüssen, sodass die Logik auf zwei lose gekoppelte Umgebungen verteilt ist. Daher ist das Debuggen und Verfolgen von Abhängigkeiten schwierig.


Das Letzte, was ich erwähnen wollte, war die Versionskontrolle.


Die gute Nachricht ist, dass er es ist. Das Schlimme ist, dass es sich um eine abgespeckte Version von Subversion handelt. Vergiss den Git Flow.


Fehlende Kontrolle


Jeder, der mit dem Java-Ökosystem vertraut ist, kann die Leistungsfähigkeit von Open Source nicht unterschätzen. Wenn irgendwo auf dem Stapel ein Fehler auftritt, sehen Sie, in welchem ​​Teil des Codes dies passiert ist. Der Code kann debuggt werden, um genau zu verstehen, was gerade passiert. Sie können die Lösung googeln. Sie können eine Pull-Anfrage senden. In extremen Fällen können Sie die Bibliothek verzweigen. Sie haben die volle Kontrolle über das Projekt.


Mit Mendix können Sie das vergessen. Dies ist ein geschlossener kommerzieller Rahmen, und was sich darin abspielt, ist eine echte Black Box. Alles, was Ihnen bleibt, ist, bezahlten Support zu kaufen oder auf jemanden zu warten, der in einem Forum mit ca. 200 Fragen pro Monat hilft (vergleiche mit dem #spring-Tag bei stackoverflow !).


Herstellerabhängigkeit


Mendix wirft das wahrscheinlich ziemlich oft vor. Sie haben sogar einen Artikel veröffentlicht, der besagt, dass es wirklich keine Sucht gibt. Wenn Sie zwischen den Begriffen lesen, heißt es:


Sie können Ihre Daten, DDL-, UI-Ressourcen und Code abrufen (Microflow wird magisch in Java-Code konvertiert).


Wird es ohne Laufzeit und API Mendix ausgeführt oder kompiliert? Kann dies beibehalten und weiterentwickelt werden? Fragen sind rhetorisch. In der Tat müssen Sie alles komplett neu schreiben. Sie sind auf eine proprietäre Plattform angewiesen. Sie besitzen das von Ihnen erstellte System nicht.


Eingeschränkte Skalierbarkeit


Mendix-Marketing konzentriert sich auf die größten Unternehmen, sodass der Begriff „Skalierbarkeit“ in Marketingmaterialien ständig aufleuchtet.


Im Jahr 2017 führte Mendix die zustandslose Laufzeit ein, dh alle Sitzungsinformationen werden entweder auf der Clientseite oder in einem dauerhaften Speicher gespeichert.


Theoretisch bedeutet dies eine unbegrenzte horizontale Skalierbarkeit. Es hört sich toll an, aber wie immer gibt es eine Nuance - die Datenbank.


Eine Datenbank stellt sich fast immer als Engpass in einer Unternehmensanwendung heraus. Was speichert der Datenspeicher hinter vielen zustandslosen Mendix-Servern? Keine Überraschungen - dies ist eine gute alte relationale Datenbank. In der Cloud Mendix - PostgreSQL. Außerdem ist die generierte Mendix-DDL, gelinde gesagt, nicht ganz optimal. Ich habe zum Beispiel eine Zwischentabelle gesehen, die häufig zum Modellieren von N: M-Beziehungen verwendet wird und für eine 1: N-Beziehung erstellt wurde.


Das Problem mit der Skalierbarkeit könnte durch Standardmethoden gelöst werden: Optimieren der Datenbankstruktur, Zwischenspeichern oder sogar Verwenden von Lösungen wie Citus. Aber natürlich gibt es keine solche Möglichkeit.


Die einzige Möglichkeit zum Skalieren der Datenbank besteht im Skalieren mithilfe von Lesereplikaten (z. B. Amazon RDS). Aber für die Aufzeichnung wird dies nicht funktionieren.


Zusammenfassend hat Mendix eine grundlegende Einschränkung der Skalierbarkeit und keine Möglichkeit, die Leistung zu optimieren.


HR-Problem


Die Suche nach qualifiziertem Personal ist immer eine schwierige Aufgabe. Es scheint, dass in dieser Mendix der Traum eines jeden Managers ist, weil die Qualifikationsanforderungen stark reduziert werden.


Tatsächlich haben wir bereits herausgefunden, dass die meisten Projekte ein professionelles Team erfordern, unabhängig vom Werkzeug. Es ist jedoch unwahrscheinlich, dass ein Entwickler mit Selbstachtung einer Zusammenarbeit mit Mendix zustimmt, da dies eine offensichtliche Sackgasse in seiner Karriere darstellt.


Preise


Last but not least. Die Kosten für eine Lizenz für eine Anwendung beginnen bei 1875 USD pro Monat. Bei einem Abonnement für drei Jahre ist die Lizenz auf 50 interne Benutzer beschränkt.


Der Preis für eine Unternehmenslizenz mit der Möglichkeit der lokalen Bereitstellung beginnt bei 7.825 USD, was fast 100.000 USD pro Jahr entspricht.


Ein mittelständisches Unternehmen mit mehreren hundert Nutzern zahlt jährlich Rechnungen in zweistelliger Millionenhöhe.


Vergessen Sie nicht, dass es sich um relativ einfache Anwendungen handelt, wie Sie aus den obigen Ausführungen ersehen können. Für mich ist das verrückt. Dieses Preismodell macht es auch praktisch unmöglich, die von Ihnen erstellten Anwendungen zu replizieren.


Warum sind LCAPs dann immer noch beliebt?


Meiner Meinung nach liegt der Grund in der Enttäuschung bestehender Prozesse. Die Verwaltung eines Entwicklungsteams in einer großen Organisation - sei es ein internes Team oder ein Outsourcing - ist zu kompliziert.


Budgetplanung, endlose Genehmigungen, Mangel an Menschen, die bereit sind, Verantwortung zu übernehmen - ich denke, das ist vielen vertraut.


Das Witzige ist, dass das Erste, was mir einfällt, wenn sich IT-Projekte zu langsam entwickeln, darin besteht, noch mehr Entwickler und natürlich Manager einzustellen. Das verschlechtert natürlich nur die Situation. Ich kenne ein paar Banken mit mehr als 10.000 (!!!) Entwicklern, von denen mindestens die Hälfte nutzlose Arbeit leistet.


In ihrer Verzweiflung suchen Unternehmensleiter nach einer Lösung in solchen "Zauberstäben" wie LCAP, die angeblich in der Lage sind, alle Probleme zu lösen.


Wie Sie diesen Teufelskreis verlassen können, erfahren Sie in einem separaten Artikel. Dies ist jedoch eine Frage des Managements und nicht der Technologie.


Wenn Sie es schaffen, ein kleines, qualifiziertes Team von 3 bis 10 Personen zusammenzustellen, das vollständig in das Projekt eingebunden ist, und direkten Kontakt mit dem Entscheidungsträger haben, werden Sie schneller und kostengünstiger als erwartet hervorragende Ergebnisse erzielen.


Was sind die Alternativen?


Jetzt gibt es eine riesige Auswahl an Tools und Frameworks für Entwickler.


Beispielsweise ist das Spring Framework die beliebteste Open-Source-Technologie zum Erstellen von Unternehmenssoftware, die gut mit Webframeworks wie React oder Angular zusammenarbeitet. Tools wie Spring Initializr und JHipster haben die Projekterstellung in den letzten Jahren erheblich vereinfacht.


Wenn Sie das Ergebnis schneller erhalten möchten, sollten Sie RAD-Tools wie die CUBA-Plattform in Betracht ziehen.


Es basiert auf demselben Spring Framework und wird durch visuelle Entwicklungstools und eine Vielzahl von Standardkomponenten ergänzt. Möglicherweise ist dies die nächstgelegene Alternative zu LCAP und bietet Flexibilität und einen komfortablen Entwicklungsprozess.


Die endgültige Auswahl sollte von der Aufgabe sowie den Fähigkeiten des Teams und Ihren Vorlieben abhängen.


Fazit


Low-Code-Plattformen eignen sich hervorragend für das Prototyping. Sie verringern die Kluft zwischen Geschäftsbenutzern und IT, sodass Sie schnell einen funktionierenden Prototyp erhalten und sich eine Vision für das zukünftige System bilden können.


Da es nur sehr wenige Benutzer von Prototypen gibt, sind die Kosten in dieser Phase ebenfalls gering. Und es lohnt sich in diesem Moment anzuhalten!


Wenn Sie mit LCAP ein komplettes System entwickeln, sinkt zwangsläufig die Arbeitsgeschwindigkeit, und Sie sind abhängig von der teuren proprietären Plattform, die Sie einschränkt.

Source: https://habr.com/ru/post/de483258/


All Articles