Das #Softwarepicknick ist deine digitale Mittagspause mit den Experten der open knowledge GmbH. Bei diesem meet und eat bringen wir dir hilfreiche Codesnacks und aktuelle Thesen der modernen Softwareentwicklung direkt auf den Tisch und schaffen eine Wiese für deine konkreten Fragen aus dem Projektalltag. Die etwa 30-minütigen Aufzeichnungen der Talks und die wichtigsten Fragen haben wir dir in diesem Blogpost zusammengefasst.
Alles an Metaprogrammierung, was eine klassische Enterprise Java Applikation zur Startup Zeit macht, können wir bereits vorher erledigt haben. Doch wie geht das? Und was können wir von Quarkus in dieser Richtung lernen?
Ja. Besonders unter Anbetracht der Tatsache, das die meisten Modernen IDEs häufig im Hintergrund Dateien rekompilieren. Das sorgt dafür, dass die Last auf kleine, unabhängig laufende Compiler Zyklen verteilt wird. Wir müssen also nicht einmal „lange“ warten, sondern können die sowie im Hintergrund laufenden Zyklen nutzen. Plus natürlich der Fakt, dass der Compiler alles das was wir sonst händisch machen würden, bereits erledigt hat.
Im Grunde liegt dies vermutlich daran, dass Standards auf Laufzeit Verarbeitung ausgelegt sind. Diese Standards existieren zumeist schon länger, als die statische Metaprogrammierung in Java. Diese Standards müssten jetzt umgeschrieben und neu aufbereitet werden, was allerdings sehr viel Zeit braucht, nicht nur um diese neu zu definieren, sondern auch um bestehende Applikationen an diese neuen Standards anzupassen. Quarkus hingegen ignoriert diese Standards „bewusst“. Es biegt sehr viele Standards so hin, dass es auch zur Compile Time funktioniert. Und das kostet natürlich Zeit.
Es existiert ein sehr großes Ökosystem an JEE Frameworks und APIs, die wir uns auch tag täglich zu Nutzen machen. Alle diese sind auf die Standards ausgelegt, dass zur Laufzeit Berechnungen durchgeführt werden können. Halt dynamische Metaprogrammierung. Diesen Standard zu ändern würde bedeuten alle Frameworks, alle APIs und dann auch alle Applikationen anzupassen. Und das ist Arbeit an laufenden Systemen. Vielleicht erklärt hier der Leitspruch „never touch a running system“ die Lage.
Nicht so unglaublich, wie man vermutlich denken würde. Achtung: Selbstverständlich hängt das davon ab, wie wir den Annotation Processor designen! Wenn wir einen unglaublich großen und komplexen Annotation processor bauen, der lange rechnet, dann dauert das auch dementsprechend länger. Standardmäßig allerdings ist das nicht so viel mehr. Die IDE recompiliert Dateien, die sich geändert haben, immer wieder während wir arbeiten neu. Manchmal allerdings auch erst alles auf einen Schlag. Wir haben dann zwar beim Kompilieren eine etwas größere Last auf den Rechner, allerdings hätten wir diese auch, wenn die Applikation hoch fahren würde. Wann das ganze ins Gewicht fällt, ist wenn wir sehr sehr viele Annotation Processor haben. Allerdings lässt sich dieses mit geschicktem Design auch umgehen.
Ja und Nein. Es gibt einige Wenige Anwendungsfälle, die einen Microservice in wenigen nano Sekunden bräuchten. Es stimmt allerdings, dass dies normalerweise nicht wirklich relevant wird. Systeme wie Kubernetes nutzen health checks, um zu schauen ob eine Applikation läuft. Ist dieser auf 10 Sekunden eingestellt, dann macht es keinen Unterschied ob der Microservice in 0.01 MS oder 5 Sekunden hochgefahren ist. Wo es sich auswirkt und was wirklich ins Gewicht fällt, ist allerdings die Entwicklungszeit.
Ja, aber entsprechend des Vortrages statische im Gegensatz zu Dynamischer. Dann würden unsere Applikationen schneller hoch fahren, es ist „hot deployment“ möglich (also die laufende Applikation kann geänderte und neu Kompilierte Dateien einfach annehmen) und für uns wird es wesentlich übersichtlicher, was dort im Hintergrund passiert. Keine schwarze Voodoo Magie mehr, sondern einfacher, klassischer Code in den wir hinein gucken können.
Die Slides zum Talk sind auf Slideshare verfügbar.
Die weiteren Talks aus der #Softwarepicknick Reihe findest du auf unserem Blog:
API Versionionierung - aber richtig
Von less server zu serverless - Eine Reise durch die Cloud
Hier waren wir auf der OOP. Zusammen mit Saxonia Systems waren alle Teilnehmer in den Pausen dazu eingeladen zum Stand zu kommen, um Informationen in kurzen und kompakten Tracks zu erhalten. Dazu haben wir erfrischende Getränke und kleine Snacks bereitgestellt, um zusätzlich für die passende Picknick Atmosphäre zu sorgen, klick dich rein.
Alles an Metaprogrammierung, was eine klassische Enterprise Java Applikation zur Startup Zeit macht, können wir bereits vorher erledigt haben. Doch wie geht das? Und was können wir von Quarkus in dieser Richtung lernen?
Ja. Besonders unter Anbetracht der Tatsache, das die meisten Modernen IDEs häufig im Hintergrund Dateien rekompilieren. Das sorgt dafür, dass die Last auf kleine, unabhängig laufende Compiler Zyklen verteilt wird. Wir müssen also nicht einmal „lange“ warten, sondern können die sowie im Hintergrund laufenden Zyklen nutzen. Plus natürlich der Fakt, dass der Compiler alles das was wir sonst händisch machen würden, bereits erledigt hat.
Im Grunde liegt dies vermutlich daran, dass Standards auf Laufzeit Verarbeitung ausgelegt sind. Diese Standards existieren zumeist schon länger, als die statische Metaprogrammierung in Java. Diese Standards müssten jetzt umgeschrieben und neu aufbereitet werden, was allerdings sehr viel Zeit braucht, nicht nur um diese neu zu definieren, sondern auch um bestehende Applikationen an diese neuen Standards anzupassen. Quarkus hingegen ignoriert diese Standards „bewusst“. Es biegt sehr viele Standards so hin, dass es auch zur Compile Time funktioniert. Und das kostet natürlich Zeit.
Es existiert ein sehr großes Ökosystem an JEE Frameworks und APIs, die wir uns auch tag täglich zu Nutzen machen. Alle diese sind auf die Standards ausgelegt, dass zur Laufzeit Berechnungen durchgeführt werden können. Halt dynamische Metaprogrammierung. Diesen Standard zu ändern würde bedeuten alle Frameworks, alle APIs und dann auch alle Applikationen anzupassen. Und das ist Arbeit an laufenden Systemen. Vielleicht erklärt hier der Leitspruch „never touch a running system“ die Lage.
Nicht so unglaublich, wie man vermutlich denken würde. Achtung: Selbstverständlich hängt das davon ab, wie wir den Annotation Processor designen! Wenn wir einen unglaublich großen und komplexen Annotation processor bauen, der lange rechnet, dann dauert das auch dementsprechend länger. Standardmäßig allerdings ist das nicht so viel mehr. Die IDE recompiliert Dateien, die sich geändert haben, immer wieder während wir arbeiten neu. Manchmal allerdings auch erst alles auf einen Schlag. Wir haben dann zwar beim Kompilieren eine etwas größere Last auf den Rechner, allerdings hätten wir diese auch, wenn die Applikation hoch fahren würde. Wann das ganze ins Gewicht fällt, ist wenn wir sehr sehr viele Annotation Processor haben. Allerdings lässt sich dieses mit geschicktem Design auch umgehen.
Ja und Nein. Es gibt einige Wenige Anwendungsfälle, die einen Microservice in wenigen nano Sekunden bräuchten. Es stimmt allerdings, dass dies normalerweise nicht wirklich relevant wird. Systeme wie Kubernetes nutzen health checks, um zu schauen ob eine Applikation läuft. Ist dieser auf 10 Sekunden eingestellt, dann macht es keinen Unterschied ob der Microservice in 0.01 MS oder 5 Sekunden hochgefahren ist. Wo es sich auswirkt und was wirklich ins Gewicht fällt, ist allerdings die Entwicklungszeit.
Ja, aber entsprechend des Vortrages statische im Gegensatz zu Dynamischer. Dann würden unsere Applikationen schneller hoch fahren, es ist „hot deployment“ möglich (also die laufende Applikation kann geänderte und neu Kompilierte Dateien einfach annehmen) und für uns wird es wesentlich übersichtlicher, was dort im Hintergrund passiert. Keine schwarze Voodoo Magie mehr, sondern einfacher, klassischer Code in den wir hinein gucken können.
Die Slides zum Talk sind auf Slideshare verfügbar.
Die weiteren Talks aus der #Softwarepicknick Reihe findest du auf unserem Blog:
API Versionionierung - aber richtig
Von less server zu serverless - Eine Reise durch die Cloud
Hier waren wir auf der OOP. Zusammen mit Saxonia Systems waren alle Teilnehmer in den Pausen dazu eingeladen zum Stand zu kommen, um Informationen in kurzen und kompakten Tracks zu erhalten. Dazu haben wir erfrischende Getränke und kleine Snacks bereitgestellt, um zusätzlich für die passende Picknick Atmosphäre zu sorgen, klick dich rein.
