„IT als Übfeld der permanenten Revolution?“

Leser fragen – Danisch sieht das ein wenig anders.

Leseranfrage:

IT als Übfeld der permanenten Revolution?

Lieber Herr Danisch;

Sie haben schon oft auf diese krude Theorie namens “Anhalten der permanenten Revolution bedeutet Kristallisation in Richtung Nazi” hingewiesen.

Kann es sein, daß diese ganzen ominösen Methoden wie DevOps, Agilität, Scrum, täglicher Framework-Update bzw. -Umschmiß, die ja aus den kommunistisch unterwanderten Universitäten und Milliardenunternehmen der USA kamen und kommen, genau dieser Agenda folgen?

Mir fiel das jetzt beim “Krieg” zwischen JSON/REST und gRPC/Protocol Buffers auf. Kaum durchgesetzt im letzten Jahrzehnt, schon muß es wieder ersetzt werden (durch alte Sachen, aber Hauptsache ersetzen!). Google ist nicht dein Freund…

Erste Antwort mal nur bis „Agenda folgen“: Jain.

Dieser Agenda scheinbar folgen, denn ich glaube nicht, dass die das machen, um Nazis abzuwehren, sondern das eher ein Auswuchs dieser linken Sichtweise ist, dass alles nur soziales Konstrukt und jederzeit zu ändern ist.

Vor allem geht es natürlich darum, den Leuten ständig irgendwas Neues anzudrehen. Scrum ist ein ziemlicher Scheiß – aber die, die den Firmen Scrum beibrachten, die Unternehmensberater, haben sich damit dumm und dämlich verdient und Wahnsinnshonorare bekommen. Man verkauft den Leuten halt, was sie einem auch abkaufen. Und linke Ideologie und Grundausrichtung, die sich an ständige Änderungen gewöhnt hat und die gut findet, ist dafür eben sehr anfällig.

Die Realität ist, dass man irgendwann 100% seiner Arbeitsleistung damit verbringt, sich an die ständigen Änderungen anzupassen, und gar nichts mehr gebacken bekommt. In der Informatik ganz schlimm, ging mir gegen Ende auch so. Das hat weniger mit Kampf gegen Nazis zu tun, sondern mit dieser Moden-Affinität und schlicht und einfach auch der Dummheit. Man hat immer ein paar Jahre Kritikruhe, wenn man mit etwas Neuem kommt, bis die merken, dass es nichts taugt. IT ist immer auch ein Marktplatz der Betrüger und Snake-Oil-Händler.

Dazu kommt ein anderer Aspekt:

Scrum bietet – pro forma – die Möglichkeit, Leute, die kaum oder keine Ahnung von IT haben, in ein IT-Team zu „integrieren“, Scrum-Master. Ich habe da Leute erlebt, die ich niemals eingestellt hätte. Es bietet aber die Möglichkeit, Geisteswissenschaftler, Quereinsteiger, Quotenfrauen mit IT-Gehältern zu versorgen – die natürlich die anderen mit ernähren müssen.

Die Universitäten haben damit meines Erachtens aber nur insoweit zu tun, dass sie Leute als „Informatiker“ produzieren, die in Wirklichkeit miserabel ausgebildet sind und immer weniger können. Und Scrum dient eben auch dazu, Leute zu dressieren, die von sich aus überfordert wären.

Zu JSON/REST vs. gRPC/Protocol Buffers:

Kann ich noch nicht sagen, weil ich mit gRPC/Protocol Buffers noch nichts selbst gemacht habe. Ich habe dazu gerade keine Zeit und habe das auf die nächste Ubuntu LTS-Release verschoben, weil ich mir das zusammen mit HTTP/3 und QUIC anschauen und implentieren will, und deshalb noch etwas reifen lassen möchte. Ich wende gerade schon jeden Tag viel Zeit für Bug Reports und Tests auf, und bin an der Oberkante, das können dann auch mal andere Testen.

Aber:

Es ist nicht (unbedingt) so, dass das Technikwechsel um des Wechselns Willen sind.

Das World Wide Web und RPCs haben sich in den letzten Jahren enorm gewandelt, die Anforderungen haben sich drastisch gesteigert. Früher war eine Webseite eine HTML-Seite, in der Regel noch ein Style Sheet – fertig. Heute ist alles voll mit JavaScript, dynamisch erzeugten Inhalten, die nachgeladen werden müssen, Graphiken, Videos, Websockets, weiß der Teufel was nicht alles. Und dazu sind HTTP und TCP nicht mehr so fit, denn besonders TCP ist eben auch schon 50 Jahre alt, HTTP fast 35 Jahre. Das ist zu langsam für heutige Anwendungen.

Insofern ist das durchaus nachvollziehbar, dass man sich neue Protokolle und Paradigmen anschaut. Das darf man nach 50 bzw. 35 Jahren durchaus mal.

Ob das jetzt aber besser ist, kann ich weder allgemein, noch speziell sagen, weil ich mir das noch nicht näher angesehen habe und nicht weiß, worauf sich die Frage bezieht.

Aber: gRPC setzt auf HTTP/2 auf, oder unterstützt es zumindest, und das ist, je nach Anwendungsfall, durchaus ein Vorteil, weil es multiplexen und pushen kann.

Ich denke aber, dass das erst mit HTTP/3 richtig interessant wird, wobei ich HTTP/3 aber nicht nicht ausprobiert, darüber nur gelesen habe, und auch noch keine HTTP/3-taugliche Software habe.

Und was JSON und Protocol Buffers angeht: JSON ist ein Text-Format für kleine Daten. Protocol Buffers ist ein Binärformat für beliebige Daten. Und sowas ist – hängt natürlich von der Anwendung ab – sehr sinnvoll, wenn man Binärdaten übermittelt, und das tut man eben immer öfter.

Vorbehaltlich, es mir näher anzuschauen und auszuprobieren: Nach meinem derzeitigen Wissensstand erscheint mir das sehr sinnvoll, aber nicht in jedem Fall, sondern in bestimmten Fällen.

Ich habe aber erst für nächstes Jahr vor, mir das anzusehen, zusammen mit HTTP/3 und QUIC.

Und ich denke, besonders Mobilapplikationen werden davon merklich profitieren. Diese Protokolle bringen Verbesserungen, die sich gerade auf Handys bemerkbar machen sollten.