Ein Pfad trägt die Last nicht mehr. Das ist kein Grund, alles neu zu bauen.

Nein, und das ist der Punkt. Ihr PHP bleibt das System, in dem der Alltag stattfindet. Daneben steht ein Dienst, der genau eine Sache tut, und zwar die, für die das Ausführungsmodell von PHP schlecht passt. Wenn dieser Dienst morgen wieder verschwindet, läuft der alte Pfad weiter, solange das Feature Flag steht.

Meistens nicht, und das ist der häufigste Fall. Wenn die Zeit in einer Abfrage ohne passenden Index verbraucht wird, in einem N+1 im ORM, in einer Datenbank an ihrer Grenze oder in der Wartezeit auf einen fremden Dienst, dann wartet ein Go-Dienst genauso lange wie das PHP davor, nur mit mehr beweglichen Teilen. Ohne Messung ist die Sprachfrage ein Münzwurf. Deshalb steht sie hier hinten und die Messung vorn.

Wenn die Zeit im eigenen Code verbraucht wird und nicht im Warten: viele gleichzeitige, langlebige Verbindungen; Arbeit, die parallel laufen könnte, es im Anfrage-pro-Prozess-Modell aber nicht tut; Serialisierung oder Rechnerei in großen Mengen; ein Aufruf, der im einstelligen Millisekundenbereich beantwortet werden muss. Das sieht man in der Ablaufverfolgung, nicht in der Diskussion.

Weil beides zusammengehört, und der PHP-Weg meistens der billigere ist. Ein richtig eingestellter OPcache, Preloading und vor allem aufgeräumte Abfragen holen bei den meisten Pfaden mehr heraus als ein zweiter Dienst. Der JIT gehört ausdrücklich nicht in diese Aufzählung: Er hilft dort, wo tatsächlich gerechnet wird, und das ist selten der Engpass, weil typische Webanwendungen an Ein- und Ausgabe hängen und nicht an der CPU. Dazu kommt, dass sich das Ausführungsmodell selbst ändern lässt, ohne die Sprache zu wechseln: RoadRunner, FrankenPHP und Swoole halten den PHP-Prozess am Leben und gehen damit genau die drei Schwächen an, die oben stehen, nämlich langlebige Verbindungen, Nebenläufigkeit und Aufrufe im einstelligen Millisekundenbereich. Wer noch auf PHP 7 oder älter steht, für den ist ohnehin das Upgrade der erste Hebel, und dafür gibt es hier eine eigene Seite. Go lohnt sich erst dort, wo auch das nicht reicht. Fällt Ihr Fall in eine der Gruppen davor, sage ich das und Sie sparen sich diese Seite.

Das entscheidet Ihr Team mit, und Ihre Laufzeit entscheidet mit. gRPC mit Protocol Buffers ist die bessere Wahl, wenn die Aufrufe häufig sind, ein verbindlicher Vertrag zwischen beiden Seiten helfen soll und auf PHP-Seite ein dauerhafter Prozess läuft, etwa RoadRunner oder FrankenPHP. Unter klassischem PHP-FPM ist der Prozess kurzlebig, der Kanal überlebt die Anfrage nicht, und damit fällt der eigentliche Vorteil von gRPC weg, nämlich die wiederverwendete HTTP/2-Verbindung. Dort und überall, wo Ihre Leute mit REST vertrauter sind, ist schlichtes REST mit Keep-Alive die ehrlichere Wahl. Ein Werkzeug, das im Betrieb niemand versteht, ist kein Fortschritt.

Entweder das, mit klar geregeltem Zugriff, oder eine eigene Grenze mit einem definierten Weg der Daten. Beides funktioniert. Was nicht funktioniert, ist das Dazwischen: zwei Systeme, die dieselben Tabellen nach eigenem Gutdünken schreiben. Welcher der beiden Wege es wird, gehört in den Schnitt und steht fest, bevor gebaut wird.

Das entscheidet der Zuschnitt Ihres Problems und nicht das Alter des Codes. Hier geht es um genau einen Pfad, der unter Last einbricht, während der Rest seinen Dienst tut. Ist dagegen der Bestand selbst das Problem, weil ihn niemand mehr anfassen will, weil es keine Tests gibt und jede Änderung an drei Stellen weh tut, dann ist die Legacy-Modernisierung der passendere Einstieg, und dann sage ich das. Sie hat hier eine eigene Seite unter den Leistungen.

Beide Einstiege kosten 1.900 Euro fest, dauern eine Woche, liefern einen Zweig und belegen mit derselben Case Study. Die Frage ist nur, was bei Ihnen bricht. Geht es um das Mandantenmodell, die Abrechnung oder die Nutzungsmessung, also um den Zuschnitt der Plattform selbst, dann ist die Seite zu SaaS-Plattformen die richtige. Bricht dagegen nicht das Mandantenmodell, sondern ein einzelner Pfad, während der Rest der Plattform trägt, sind Sie hier richtig.

Diese Frage stellt sich vor der Produktivstellung und nicht danach, und das ist der Vorteil des kleinen Zuschnitts: Nach der Woche liegt der Dienst in einem Zweig, der Weg in den Betrieb liegt schriftlich daneben, und erst dann entscheiden Sie. Deshalb bleibt es auch ein Dienst und kein Ökosystem: ein Binary, wenige Abhängigkeiten, dieselben Metriken und dieselbe Auslieferung wie beim Rest. Sagt Ihr Team, es will das nicht betreiben, haben Sie einen Zweig verworfen und keinen zwölften Monat eines Rewrites.

Die Messung mit dem herausgelösten Pfad kostet 1.900 Euro netto, das Ergebnis liegt nach einer Woche vor. Das ist ein Festpreis und kein Startpreis, und der Grund steht im Zuschnitt: Was in dieser Woche entsteht, ist eine Messung und ein Zweig in Ihrem Repository. In Ihrer Produktivumgebung wird nichts angefasst, also hängt der Aufwand auch nicht an fremden Freigaben, Umgebungen und Terminen. Nicht enthalten ist die Produktivstellung, also Anbindung, Umschaltung des Verkehrs und Betrieb. Die wird nach dem Ergebnis angeboten, ebenfalls zum Festpreis, bevor sie beginnt, denn erst dann weiß man, was sie umfasst. Zeigt die Messung, dass ein Go-Dienst nicht das Mittel ist, endet es dort. Bezahlt haben Sie dann eine Woche und eine Antwort, die Ihnen ein Vorhaben von zwölf Monaten erspart, und das ist der billigste Ausgang von allen.