Fragt ihr euch auch manchmal, wie es eigentlich kommt, dass neue Technologien zum Einsatz kommen? Das Altbekannte ist doch viel weniger risikobehaftet und ganz nach dem Motto „Schuster bleib bei deinen Leisten“ könnte man davon ausgehen, dass es gar nicht so einfach ist, unbekannte Technologie einzusetzen. Wir möchten euch daher heute unsere Quarkus-Geschichte weitergeben…
Im Herbst 2019 stand unser Entwicklungsteam vor der Aufgabe, die bestehende Ormera-Applikation weiter zu skalieren. Das Startup Ormera bietet eine smarte und automatisierte Abrechnung von Energie-Daten in Zusammenschlüssen zum Eigenverbrauch (ZEV). Glücklicherweise sind im Verlauf des Jahres 2019 laufend weitere Kunden und damit Messpunkte ans System angeschlossen worden. Dies führte dazu, dass in unserer bestehenden Lösung verschiedene Flaschenhälse ersichtlich wurden. Unser Ziel im Spätherbst: Nicht einfach Symptombekämpfung betreiben, sondern das System so umbauen, dass es auch mit einem Ausbau um Faktor 50-100 möglich bleibt. Der Entscheid, alles noch stärker in eine Microservice Architektur zu überführen, war schnell getroffen. Eigentlich könnte unsere Geschichte hier enden, wenn nicht – wie immer – die grösseren Herausforderungen bei der Umsetzung warten würden.
Stehst du am genau gleichen Punkt? Vielleicht hilft dir unser AMM Programm?
Startzeit der Services
Ein Microservice mit Spring Boot und Apache Wildfly benötigt ziemlich lange, um zu starten. Da wir unsere Services in der Entwicklung oft neu starten müssen, wurde dies irgendwann zu einem echten Nerven-Killer. Die Zwischenrufe anderer Teams – man hätte halt doch besser Java EE mit MicroProfile einsetzen sollen – machte das Ganze nicht besser. Und wie immer, wenn zwei sich streiten, lacht ein Dritter. In einer Nacht- und Nebel-Aktion ist der erste Quarkus PoC entstanden. Denn Quarkus verspricht genau die Probleme zu lösen, die das Entwickeln mühsam machten. Schnellere Startupzeiten und ein minimaler Memory Footprint, halt einfach supersonic subatomic Java :-). Und hey, abgesehen davon ist es eine der neusten Technologien und es macht doch immer Spass, sich mit Neuem zu befassen.
supersonic subatomic Java
Wie jede Pionierarbeit war die Anfangsphase für das Team sehr aufregend. Quarkus war damals noch kurz vor dem ersten offiziellen Release. Die meisten Probleme unseres Entwicklungsteams waren neu für die ganze Java-Community. In diesem Moment wussten wir, dass wir technologisch am Puls der Zeit sind. Puzzle ITC strahlte schon immer in der Containerwelt, denn wir waren sehr früh in der containerisierten Domäne unterwegs. Bis dahin hinkten jedoch die Java Applikationen immer ein wenig hinterher. Die von der Cloud-native Community gepredigten Dogmen konnten in der Java-Welt bis anhin nicht wirklich eingehalten werden. Container hatten lange Startzeiten und trotz microservice-ähnlichen Ansätzen eine zu lange Lebendsdauer.
Mit Quarkus hat sich das auf einen Schlag geändert. Nativ kompilierte Microservices starteten in wenigen Millisekunden und benötigten einen Bruchteil des Speichers gegenüber ihren Vorgängern.
Was Frontend-Entwickler gefühlt schon seit Ewigkeiten besitzen, bringt Quarkus nun endlich in die Java-basierte Backend-Entwicklung: Den Dev-Mode. Änderungen im Source Code werden automatisch mit der nächsten API Abfrage neu kompiliert und ohne Unterbrüche bereitgestellt. Dies erlaubt dem Entwickler eine unterbrechungsfreie und effizientere Arbeitsweise. Dies hat unsere Produktivität massiv beeinflusst und viel Quality of Life Verbesserungen mit sich gebracht.
Teamentscheid
Nachdem der erste Proof of Concept zur Verfügung stand, waren wir in der Lage, die Systeme in einem Direktvergleich laufen zu lassen. Die Ergebnisse konnten sich zeigen lassen. Dank Einsatz einer message-oriented Middleware (Artemis ActiveMQ) wurde von einem synchronen REST basierten Ansatz auf eine asynchrone messaging Vorgehensweise gewechselt. Durch den Dogmenwechsel konnte ein kommender Workload besser verteilt und bewältigt werden. Nach Vorstellung der neuen Ansätze und Techniken im Team war allen klar, dass der neue Ansatz mit Hilfe von Quarkus die Zukunft unserer Ormera-Applikation sein wird. Eine Woche später konnten wir das neue System live schalten und die Unterschiede in der produktiven Umgebung bestaunen.
Seit diesem Entscheid setzen wir auf Quarkus und bereuen es keinen Moment. Durch den Technologiewechsel konnte unser Team viel Neues in Erfahrung bringen, der abrupte Architekturwechsel zieht sich durch jeden technischen Aspekt der Software und jegliche Ansätze und Praktiken wurden diskutiert und evaluiert. Somit konnten wir im Entwicklungsteam ein enormes Know-how bezüglich allgemeiner Microservice Architektur aufbauen.
Hast du ähnliche Herausforderungen und suchst ein kompetentes Team? Wir helfen gerne. Melden dich bei uns.
Ormera skaliert!
Auf den ersten Blick wirkt Quarkus wie ein weiteres Tool, um Java Backend-Entwicklung zu betreiben. Wenn man sich jedoch ein wenig vertiefter in die Materie einliest, merkt man, dass viel mehr dahinter steckt als ein simples Framework. Durch den ressourcensparenden cloud-native Ansatz wird man selbst von dem Ressourcengeiz angesteckt. Man hinterfragt ständig, wie man seine Microservices so klein und effizient wie möglich entwirft und baut. Dank dem schon vorher angesprochenen Dev-mode müssen in der Entwicklungsumgebung Module nicht neu kompiliert und gestartet werden. Änderungen im Code werden beim nächsten Request automatisch ausgerollt und man kann in gewohnter Frontendmanier ohne Unterbrüche entwickeln. Durch den Einsatz von Vert.x als Engine im Hintergrund werden neue Ansätze von reaktivem Programmieren empfohlen. Blockierende, synchrone Prozesse können durch reaktive Programmierflows ersetzt werden, der Code liest sich schöner und wird effizienter.
Befasse dich mit neuer Technologie und sprich darüber
Um das neu erlernte und angesammelte Wissen optimal zu nutzen, möchten wir das Know-How weitergeben. Wir konnten an unserem jährlichen Techworkshop bereits eine erste interne Quarkus-Schulung anbieten. Dabei konnten unsere Members beim Erstkontakt mit der neuen Technologie instruiert und begleitet werden. Wir befassten uns mit den Grundlagen im neuen Framework, Deployments und Delivery der Microservices mit Hilfe von Tekton, Openshift 4 und vieles mehr. Aufgrund des positiven Feedbacks haben wir uns entschlossen, noch weiter in die Tiefen der Materie zu tauchen. Neu bieten wir in einem zweitägigen Training interessierten Engineers, einen optimalen Start in einen neuen Techstack sowie Eindrücke und Erfahrungen aus erster Hand von unseren Quarkus-Experten.
Anmelden für Microservices Archtecture Lab