Quarkus 2 versus Quarkus 1

Yonko Todorov, Softwareentwickler bei sidion

Vor ein paar Tage hat die Quarkus Gemeinschaft eine neue Hauptversion veröffentlicht – Quarkus 2.

Quarkus 1 ist ausgezeichnet. Nicht nur wegen der Features die es beinhaltet, sondern hauptsächlich wegen der Tatsache, wie einfach es ist dadurch Software zu entwickeln. Jetzt kommt Quarkus 2 und bringt die Entwicklererfahrung nochmal auf ein anderes Level.

Verbesserung des Dev Modus

In Quarkus 1 ist der Hot-Code-Ersatz schon gebrauchsfertig. Das ist ein riesiger Vorteil im Vergleich mit den non-Quarkus Umgebungen, wo man kämpfen muss, bis ein Hot-Code-Ersatz funktioniert. Oft wird das durch den Einsatz von Drittanbieterwerkzeugen erreicht, welche aber nicht immer zuverlässig funktionieren.

Technisch gesehen gibt es keinen direkten Hot-Code-Ersatz in Quarkus, sondern eher einen Neustart, wenn der Code geändert wird und wir mit der Anwendung interagieren.

Wir, die Entwickler sind damit mehr als zufrieden. Gibt es aber noch etwas, was man in dieser Richtung machen kann? Offensichtlich ja, denn das Quarkus-Team kann noch mehr bieten. In Quarkus 2 ist der Dev Modus ein

Interaktiver Dev Modus

Gestartet wird der Modus wie folgt:

./mvnw compile quarkus:dev

Quarkus 1 würde die Anwendung kompilieren und starten. Danach würde es bei einer Interaktion nach Änderungen überprüfen und bei Bedarf die Anwendung neu starten. Ist der Dev Modus gestartet kann man APIs aufrufen, sich zum Debuggen verbinden oder den Dev Modus unterbrechen (durch Ctrl-C).

Quarkus 2 Dev Modus hat hier noch viel mehr zu bieten.

Dev Modus Menu

Beim Starten des Dev Modus taucht ein einfaches, aber sehr hilfreiches Menü auf:

Die Tests fangen nicht sofort an, was absolut Sinn macht. Es könnte sein, dass sie einerseits viel Zeit in Anspruch nehmen, andererseits brauchen wir die Ergebnisse vielleicht im Moment nicht. Falls wir sie doch benötigen, könnten wir sie mir der Taste "r" jederzeit starten lassen.

Beim nächsten Mal, wenn wir uns entscheiden, die Tests durchzuführen und wir die Taste "r" drücken, werden nicht alle Tests wieder ausgeführt, sondern nur diese, die entweder: 1) geändert wurden, 2) neu erstellt wurden oder 3) dessen getesteter Code verändert wurde. Das macht Sinn, insbesondere wenn es viele Tests gibt.

NOTIZ: Dieses Feature hat bestimmte Abweichungen in den verschiedenen 2.x Versionen. In manchen Versionen muss man Tests [p]ause und danach [r]esume damit man eine neuen Code erhält oder der Test-Code neu geladen wird.

Das sind bei weitem nicht die einzigen Verbesserungen. Um alle Möglichkeiten und Optionen zu sehen, die im Dev Modus zur Verfügung stehen, einfach die Taste "h" drücken um das Hilfe-Menü zu öffnen:

 

Eingebettete Abhängigkeiten starten

Eine Anwendung benötigt seine Abhängigkeiten, um richtig funktionieren zu können. Bedeutet das, dass wir lokal sowohl eine Datenbank, als auch ein Kafka Broker und so weiter brauchen? Bei Quarkus 1 ja, unbedingt. Zum Glück ist dies bei Quarkus 2 jedoch nicht der Fall. Es wird sich um alle Abhängigkeiten kümmern, es sei denn wir möchten unbedingt einen bestimmten externen Server verwenden. In dem Fall können wir die Verbindungsdaten, wie bei Quarkus 1 in application.properties für die Dev Umgebung definieren.

Durch Testcontainer schafft Quarkus ein Kafka Broker mit Zookeeper, eine Datenbank und alles, was unsere Anwendung benötigt. Wenn wir zum Beispiel in Quarkus 1 keinen Kafka-Broker für Dev angeben, würde Quarkus versuchen, sich mit localhost:9092 zu verbinden. Wenn Kafka darauf nicht hört bzw. reagiert, schlägt dies natürlich fehl. In Quarkus 2 ist das Standardverhalten bzw. die Vorgabe, ein Kafka Broker zu starten. So wird es sowohl für Dev Modus, als auch für Tests funktionieren.

Wenn also die Dev Umgebung schon läuft, könnten wir dazu parallel Tests starten und zwar in der gleichen JVM. Zusätzlich startet Quarkus 2 seine eigene DB und Kafka. Wenn ich bereits mit meiner API gespielt und den DB-Inhalt verändert habe, wären die Ergebnisse der automatischen Tests möglicherweise unzuverlässig, oder? Das Quarkus Team hat auch das in Betracht gezogen, daher lautet die Antwort „Keine Sorge“.

Es stimmt zwar, dass die Dev und Tests im gleichen JVM laufen, aber sie befinden sich in isolierten Classloadern. Die Inhalte der DB werden nicht verdorben, da die Tests ihre eigenen DB-Container starten würden. Ab einem gewissen Punkt werden alle Abhängigkeiten doppelt laufen – 2 DB Container, 2 Kafka Brokern usw. Das wird höchstens so lange dauern, bis die Tests beendet sind und das ist absolut in Ordnung.

Allgemeine Bemerkungen

Quarkus 2 ist eine Hauptversion aufgrund von inkompatiblen Änderungen. Für eine Migration ist zwar ein gewisser Aufwand nötig, das ist aber keine große Sache. Das Team hat darauf geachtet, dass man seinen Code relativ einfach aktualisieren kann. Sie stellen eine gut dokumentierte Migrationsprozedure zur Verfügung.

Sowohl die Bibliotheken und die Spezifikationen die aktualisiert wurden, als auch die Voraussetzungen (JDK, Docker, Maven, Gradle…) sind gut dokumentiert und müssen hier nicht nochmal erwähnt werden. Jedoch ist es erwähnenswert, dass manche von ihnen sich noch in einer "Experimental- oder Vorschauphase" befinden.

Ist Quarkus 2 Produktionsbereit? Wie so oft lautet die Antwort: "Es kommt darauf an". Wenn man keine der experimentellen oder Vorschau Features verwendet und sich sicher ist, dass seine Microservice gut getestet sind und alle Eckfälle abdecken, inkl. Performancetesting, dann vielleicht ja. Für die meisten Projekte, besonders für die geschäftskritischen, wäre es aber vermutlich nicht schlau sofort zu migrieren. Da das Projekt noch in einer aktiven Entwicklungsphase ist, ist die Wahrscheinlichkeit auf ein Bug zu stoßen recht hoch.

Hut ab vor jedem einzelnen Mitglied der Quarkus-Community. Die Ideen sind nicht nur wirklich erstaunlich, sondern werden auch noch richtig umgesetzt. Mit einer so starken und progressiven Community hat Quarkus hohe Chancen, die bevorzugte Plattform für die Entwicklung von Microservices in JVM-Welt zu werden.

 

Weiterführende Links:

Englische Version des Beitrags