Kategorien
Architektur Microservices

Das Ende der Frameworks

Quarkus ist der heiße Scheiß. Zumindest, wenn man Microservices macht (das sind viele). Zumindest, wenn man Java macht (das sind auch noch viele). Also für eine erstaunlich große Menge da draußen, dürfte Quarkus der heiße scheiß sein. Wer ein bisschen Zeit hat, kann sich dazu den viel zu wenig beachteten Talk hier ansehen.

Quarkus ist der jetzt dritte Versuch Java EE (und auch Spring) Cloud tauglich zu machen. Man schreibt, je nach Talent, ziemlich normalen Java Service Code, drückt ein paar Knöpfe umd Bäm, hat man ein fertig kompiliertes Binär-Programm, das recht schlank ist und alles ist fein.

JVM ist tot

Ja, binär. JVM, JIT? Macht im Microservice keinen Sinn. Das war ganz hübsch, als man noch die Idee hatte, man könne Module zur Laufzeit im App Server dynamisch deployen. Das hat so gut funktioniert, dass wirklich jeder den Zyklus Undeploy, Restart, Deploy hatte – also gar nicht. Und die VM war auch ne schöne Idee, als jeder Hersteller noch eigene CPUs hatte. Heute gibt es zwei CPU Architekturen und ich deploye meinen eigenen Betriebssystem Stack gleich mit. JVM ist in dem Kontext also nur Ressourcenverschwendung. Wer sich mal Preise bei AWS und Co angeschaut hat, möchte das nicht mehr so gerne.

Quarkus nimmt also jetzt den Code, schmeißt alles raus, was man nicht benutzt, löst alle Injects zur Compile-Zeit auf und erstellt handliche, kleine Programme.

Wer noch klassische Spring Anwendungen kennt: Erst lädt Maven das halbe Internet runter (npm lädt die andere Hälfte) und dann werden beim ersten Aufruf der Seite alle class files der Welt dynamisch angezogen. Ein Stresstest ohne Upramp war durchaus geeignet, die Maschine bereits mit den ersten 100 Requests auf die Bretter zu schicken. So war das damals.

Keine JVM, kein Nachladen, Startzeit im Millisekunden-Bereich. Nett.

Frameworks

Damit man weiterhin mein seinen liebgewonnenen Frameworks arbeiten kann, macht Quarkus in Hintergrund ne Menge irres Zeug. Zur Compilezeit analysieren, was man tatsächlich benutzt, Injections auflösen, GraalVM konfigurieren, Klassen wegschmeißen… – und erreicht dann etwa die Effizeinz von einer Go Anwendung. Man kann sogar Kotlin oder Scala benutzen, wenn man ein bisschen Abenteuerlustig ist.

Aber was brauche ich denn an Frameworks tatsächlich in einem Microservice Umfeld?

  • JPA Sorgt meist für schlechte Queries und führt zu einer EntityBean – DTO umkopier Orgie und bringt mit NoSQL ohnehin nichts.
  • JMS Message Dienste funktionieren seit Ewigkeiten 1a über HTTP.
  • URL Mapping, Session Management Frontend läuft mit der ganzen Navigation im Browser.
  • Endpoints für Spezielle Formate (SOAP zB) Setzt man ein Sidecar vor, dass den Request entsprechend transformiert.
  • Authentication, Monitoring Sidecar. istio zB.
  • Prozesssteuerung Ist schon seit SOA Service basiert.
  • Batch wird bei 24/7 Betrieb normalerweise durch was Event basiertes ersetzt. Sprich langlaufende Prozesse werden eher direkt einzeln asynchron angestoßen, als dass man nachts einen Prozess startet, der den Schwung des Tages abarbeitet.

Da bleibt nicht mehr so wahnsinnig viel übrig. An sich noch maximal irgendwas, das Requests verarbeiten kann. Im Backend gerne gRPC, nachdem man festgestellt hat, dass kleine REST Services einen großen Teil ihrer CPU Zeit mit marshalling verbringen.

Das macht Quarkus natürlich gleich ein bisschen uncooler. Da passiert auf dem Weg von 100 Frameworks zu handlichem Binary so dermaßen viel, dass mein Wunsch, selbst einen „Hello World“ Service zu debuggen, sich in Grenzen hält. Es ist definitiv ein netter Migrationspfad von klassischen Anwendungen und, da RH/IBM, kann Full Stack supported werden bis runter zur letzten Library.

Man kann sich natürlich auch den ganzen Aufriss schenken und direkt etwas nehmen, was sich nach Native compilieren lässt und irgendwas hat, was sich über HTTP aufrufen lässt. Was? Das hat sich irgendwie noch nicht so recht abgezeichnet. Dazu vielleicht später mehr.

Zum Abschluss vielleicht noch ein netter Artikel von Russ Cox. Auch auf die Gefahr hin, dass viele den als Entschuldigung verwenden werden, unfassbare, proprietäre Frameworks zu bauen. Have fun.