Spring Boot erscheint als eine natürliche Weiterentwicklung des Spring-Frameworks. Das Spring-Ökosystem hat seit jeher das Ziel, die Entwicklung von serverseitigen Anwendungen zu vereinfachen und immer mächtigere Funktionalität zur Verfügung zu stellen.
Das Spring-Framework ist für mich deswegen unentbehrlich. Spring Boot verwende ich trotzdem ungerne.
In einem Aspekt führt Spring Boot nämlich wieder zurück in die schlechten alten Zeiten der Application-Server. Application-Server bieten eine homogene Umgebung, in der alle Teile zusammenpassen. Dafür ist es schwierig und aufwändig, eine bestehende Anwendung in eine neuen Version des Application-Servers zu migrieren. Denn jeder noch so kleine Sprung der Versionsnummer eines Servers kann eine Vielzahl von abhängigen Bibliotheken aktualisieren. Und erhöht damit das Risiko, dass die eigene Anwendung nicht mehr funktioniert.
In einer klassischen Spring-Anwendung hingegen habe ich die volle Kontrolle darüber, welche Bibliotheken ich in welcher Versionsnummer einsetze. Spring bietet bei den meisten integrierbaren Bibliotheken die Möglichkeit, auch relativ alte Versionen dieser Bibliotheken zu nutzen. Solange mein eigener Code die verwendeten Bibliotheken nicht aneinander koppelt, kann ich sie weitestgehend unabhängig voneinander und in beliebig kleinen oder großen Sprüngen aktualisieren.
So kann ich zum Beispiel in einer Anwendung erst Hibernate auf eine neue Version migrieren, anschließend Spring Security und zum Abschluss die verwendeten XMl- und JSON-Mapper-Bibliotheken. Und nach jeder einzelnen Migration kann ich meine Anwendung vollständig testen und jede Änderung getrennt produktiv setzen.
Sprint Boot – und in letzter Instanz die Spring IO Plattform – bieten eine vollintegrierte Plattform für die Anwendungsentwicklung. Alle integrierten Bibliotheken sind aufeinander abgestimmt, und viele Entscheidungen sind dem Entwickler abgenommen, sodass man in kürzester Zeit das Basisgerüst einer neuen Anwendung aufsetzen kann.
Wehe aber, man möchte nur einen Teil des Ökosystems aktualisieren. Dies ist mit Spring Boot nicht vorgesehen. Vielmehr bedeutet ein Versionssprung von Spring Boot – wie bei den Application-Servern –
Versionssprünge vieler integrierter Bibliotheken auf einmal. So wurde z.B. von Spring Boot 1.2 auf 1.3 nebst anderen Abhängigkeiten der Wechsel von Spring Security von 3.x auf 4.x vollzogen. Schon diese eine Teil-Migration ist nicht trivial.
Ob man sich erneut in die Abhängigkeit eines Rund-um-sorglos-Pakets wie Spring-Boot begeben möchte, hängt vermutlich stark vom Anwendungsfall ab. Zum schnellen Ausprobieren von neuen Spring-Funktionen ist Spring-Boot bestens geeignet. Auch für kurzlebige Anwendungen und schlanke Micro-Services bietet Spring Boot eine Infrastruktur, mit der man in kürzester Zeit produktiv arbeiten kann. Zudem gibt es sehr hilfreiche Erweiterungen von Spring Boot wie Spring Actuator und die Integration der Netflix-Bibliotheken, die sich ohne Spring Boot als Basis nur schwer einbinden lassen. Und schließlich bietet Spring Boot eine flache Lernkurve für alle, die sich neu in die Spring-Welt einarbeiten möchten.
Jedoch ziehe ich es für größere Projekte mit einem langfristigen Fokus weiterhin vor, Spring klassisch aufzusetzen. Ich behalte die Kontrolle über alle Abhängigkeiten und entscheide selber, welche Bibliotheken ich in welchen Versionen nutzen möchte. Diese Kontrolle kostet zu Beginn einige Zeit, um die Projektstrukturen aufzusetzen. Sie spart aber langfristig Zeit, weil ich meine Anwendung in kleinen Schritten und mit mehr Kontrolle und weniger Risiko aktuell halten kann.