Warum Spring Boot?

Bei Mischok gibt es keine Mitarbeitergespräche sondern eine gelebte Kultur des Peer-Feedbacks durch die KollegInnen. Heute Morgen saßen wir mit einem Werkstudenten zusammen. Ich erlebte einen heftigen Flashback in meine Studienzeit: Ein Kollege lobte den Werkstudenten mit den Worten, er stelle oft die richtigen Fragen zu richtigen Zeit. Auch wenn das damals nicht auf dem Plan stand, war das eine wichtige Kompetenz, die ich still und heimlich im Studium gelernt habe. Warum ich das schreibe?  Die Auflösung gibt es am Ende des Posts ;-)

Vorab: Disclaimer

Das hier ist keine (schon gar nicht bezahlte) Werbung für Spring Boot. Ich bin sicherlich auch nicht der Meinung, dass Spring Boot das einzige Framework ist, mit dem man vernünftige Software schreiben kann. Es gibt im Java Bereich viele sehr gute Alternativen. Auch versuche ich, regelmäßig über den Tellerrand zu schauen und exploriere immer wieder Konkurrenten und Mitbewerber.

Warum schreibe ich also nun über Spring Boot? Ich glaube, vielen von Euch geht es wie mir: Die ersten Schritte mit Spring Boot waren ein derartiger Aha-Moment, geradezu eine Offenbarung. Ich kam aus einer Welt, wo ich viel Zeit damit verbracht habe, in vielen Projekten die gleichen Hilfsklassen und -konstrukte zu verwenden. Natürlich haben wir diese irgendwann in eine Bibliothek gepackt, aber auch die braucht Pflege. In Spring Boot lief auf einmal fast alles wie von selbst und ich habe mich gefragt, warum ich das nicht schon früher probiert habe.

Aber das war nur der Start, die berechtigte Frage ist, warum ich dabei geblieben bin. Die beantworte ich Euch gerne in diesem Post. Dadurch gibt es weniger technischen Input und gar keinen Code zu sehen, aber ich hoffe, dass ich Euch die Spring-Boot Philosophie etwas näherbringen kann.

Quickstart

Um die ersten Schritte mit Spring Boot zu machen, reichen ein paar Minuten aus. Detaillierter habe ich das im Post „Spring Boot Tutorial für Einsteiger“ beschrieben. Und seit meinen ersten Schritten wurde das Framework immer noch weiter vereinfacht.

Warum mir das gefällt? Ich bin wirklich schnell, irgendetwas auszuprobieren. Durch den mitgelieferten Webserver und den Maven-Wrapper (bzw. natürlich auch Gradle) kann ich eigentlich auf fast jeder Umgebung erstmal loslegen, ohne weitere Abhängigkeiten zu haben.

Klar, wie oft haben wir diesen Fall realistisch gesehen? Wie viele Greenfield-Projekte machen wir tatsächlich pro Monat oder pro Jahr? Definitiv weniger als wir gerne würden. Aber darum geht es  aus meiner Sicht auch gar nicht: Spring Boot hat den schnellen Start konsequent zu einem Grundprinzip des Library-Designs gemacht. So funktioniert nicht nur der Einstig, sondern auch vieles andere wirklich blitzschnell!

Das Zauberwort ist „Convention over Configuration“. Es reicht aus, dass Bibliotheken auf dem Classpath liegen (meist durch Hinzufügen der Dependency), damit sie einfach mit der Grundkonfiguration ausgeführt werden. Du brauchst ein Tool zur Datenbankmigration? Füge die Dependency auf Flyway ein, lege ein SQL Skript an die definierte Stelle und beim nächsten Start wird es ausgeführt!

Der einfache Start bezieht sich also nicht nur auf das Aufsetzen, sondern auch auf die Erweiterung und das Ausprobieren. Und das bietet das fortlaufende, hohe Tempo!

Langer Atem

Nur Tempo allein ist ja noch kein Erfolgsgarant. Auch wenn es langfristig auf die Strecke gebracht wird. Spring Boot hat hier zwei starke Begleiter dabei: Das Spring Framework und die Programmiersprache Java (eigentlich eher die geniale Idee der JVM). Beide werden sicherlich nicht in einem Atemzug mit hippen Startups genannt, die über Nacht eine Geschäftsidee umsetzen und reich werden. Nein, aber die unterschiedlichsten Firmen betreiben mit Java und Spring über Jahre und Jahrzehnte erfolgreiche und stabile Softwareprodukte.

Rückblickend frage ich mich, warum ich nicht schon viel früher auf den Spring-Zug aufgesprungen bin. Ich glaube, hier war mir die Hürde zu hoch. Das Lehrgeld der komplizierten, expliziten Konfiguration habe ich damals meinen Kollegen zahlen lassen…

Spring Boot hat diese beiden trägen Pferde vor den Wagen gespannt und ein Gefährt daraus gemacht, dass in einem gesunden Tempo vorwärts fährt. Die Stabilität der JVM und allen voran Java bietet die Sicherheit, Produkte auch in zehn Jahren noch betreiben zu können. Das Spring-Framwork als Basis für Spring Boot entwickelt sich nach wie vor prächtig weiter, ohne – zumindest bisher – den Fehler zu machen, zu schwergewichtig und zu kompliziert zu werden.

Daher bin ich zuversichtlich, dass auch Spring Boot seinem aktuell größten Problem, der langen Startup-Zeit, eine Lösung entgegensetzen wird. Es gibt erfolgsversprechende Ansätze in diese Richtung und ich bin sicher, dass das Framework zu groß und zu wichtig ist, um an dieser Anforderung zu scheitern.

Test-Driven-Development in der DNA

Unit-Testing in verschiedenen Ausprägungen ist mit Spring Boot so einfach, dass es keine Ausrede gibt, warum man Software ohne Tests entwickeln sollte. Einen kleinen Einblick gibt der Post „Spring Boot Tests mit H2“ und das ist wirklich nur ein kleiner Ausschnitt der Möglichkeiten des Frameworks.

Weil es eigentlich keinen Grund gibt, nicht testgetrieben zu entwickeln, kann ich eine so gute Testabdeckung generieren, dass ich die Applikation problemlos per Pipelines deployen kann – bis in Produktion.

Wenn ich ehrlich bin, ist genau das für mich das zentrale Argument. Das Framework, dass mich überzeugen will, muss mir in jedem Fall die flüssige Einbindung all der Fremdbibliotheken bieten wie Spring Boot und sollte ein mindestens so ausgefuchstes Konfigurationssystem mitbringen. Ich kann mich an keinen Anwendungsfall erinnern, der sich nicht durch einen vernünftigen Unit-Test hat absichern lassen. Auch wenn ich dafür manchmal etwas kämpfen musste.

Zurück zur Ausgangsfrage: Warum Spring Boot?

Was hat das ganze jetzt damit zu tun, die richtigen Fragen zu stellen? Ich weiß einfach nicht, ob die Frage mit „Warum Spring Boot?“ zielführend gestellt ist. Aus meiner Sicht müsste es viel eher heißen „Warum nicht Spring Boot“? Ein wichtiges und in jedem Fall valides Gegenargument habe ich oben mit den Startzeiten bereits angeführt. Aber darüber hinaus? Und was sind die Alternativen?

Ich erhalte mit Spring Boot ein ambitioniertes Framework, für das Weiterentwicklung immer mit Vereinfachung einhergeht. Das ganze läuft in einer Programmiersprache, die sich langsam aber nachhaltig weiterentwickelt. Eigentlich die besten Voraussetzungen, um mein Projekt nachhaltig betreiben und weiterentwickeln zu können, oder?

Warum also nicht Spring Boot verwenden?

‍