And the Winner is: Spring (Boot)

[rsaddey]

Als EE 7 mit CDI rauskam, dachte ich noch: Das wars wohl mit Spring. Erst die Pleite mit Grails und jetzt völlig redundant.

Weit gefehlt!

Ein verbindliche Sammlung von Standards und deren Implementierungen kann nur hoffnungslos veraltet und gleichzeitig zu teuer sein, wenn sie alles was potenziell nutzbar sein soll, berücksichtigt. Da hilft auch die Fragmentierung in Profiles nicht wirklich.

Spring geht den umgekehrten Weg: Statt alles wie in Gesetzen für alle vorzuschreiben, bietet es ein schlankes Fundament und Regelwerk, um (fast) beliebige Technologien aus beliebigen Quellen so zu einer individuellen Lösung zusammenzufügen, dass sie überall auf der Welt (wo eine spezifizierte Java VM existiert) die gleichen reproduzierbaren und skalierbaren Ergebnisse liefert.

Zum Stein der Weisen in drei Schritten:

1. Zu Anfang wurde unwartbarer Code durch unwartbares XML ersetzt, Teufel gegen Beelzebub getauscht.

2. Dann kam die Ära der Annotationen. Beide Aspekte, Implementierung und Konfiguration konnten wieder innerhalb einer Sprachwelt ausgedrückt werden, erforderten aber totales Wissen über alles, bis auch nur eine flache Chat-Anwendung mit User-Verwaltung läuft.

3. Zuletzt kam Spring Boot, um die fachlichen (selbst implementierten) Mosaiksteinchen einer Anwendung automagisch mit einer Fülle gängiger Aspekte zu einer lauffähigen Anwendung zu verkleben. Zusammen mit Coding by Convention ist durch Spring Boot der Paradiesvogel Grails obsolet geworden und (gleich zusammen mit seiner IDE) weit wech geworfen worden.

Back to the roots: java -jar rules :-)

Auch hier: https://trends.google.com/trends/explore?date=today%205-y&geo=US&q=grails,spring%20boot,java%20ee

EE ist untot, wie ehedem der Cobol-Vampir, aber absehbar headed for the Cliff. Was für einen gewinnorientiertes Unternehmen wie Oracle nur bedeuten kann: Giftig, sofort abstoßen, für einen Dollar verkaufen.

[werpu]

Spring boot ist in der Tat ein guter Ansatz auch in Hinsicht einer Micro Service Architektur, da man in der Tat nur das einbindet was man wirklich braucht und boot kümmert sich in Koimbination mit Maven um die notwendigen Dependencies. Es gibt im JEE Umfeld übrigens ein ähnliches Projekt. Ich sehe Spring boot halt als nächsten Schritt im EE Umfeld.

Btw. ich halte Microservices nicht für den heiligen Gral als der es gerade gepusht wird. Man verschiebt nur die Fehleranfälligkeit von einer instanz die halbwegs handzuhaben ist in viele serverinstanzen und die Administration.
Dafür steigt der Ressourcenbedarf enorm weil man viele kleine Serverinstanzen mit denselben libs ausrollen muss. Der Admin Aufwand steigt auch enorm weil man anstatt eines servers der geclustered wird plötzlich 20 hat die man clustern muss.
Der Ansatz ist gar nicht so unähnlich wie man es früher mit remote EJBs gemacht hat und davor noch mit Corba bzw. dazwischen dann mit SOAP und SOA. Man ist jedesmal für viele Projekte nicht glücklich damit geworden.
Wo Microservices wirklich viel lösen ist im NodeJS Sektor wo man damit das Single Threaded Problem umgehen kann bei hoher Last.

[rsaddey]

werpu schrieb:
--------------------------------------------------------------------------------
…
> Btw. ich halte Microservices nicht für den heiligen Gral als der es gerade
> gepusht wird. Man verschiebt nur die Fehleranfälligkeit von einer instanz
> die halbwegs handzuhaben ist in viele serverinstanzen und die
> Administration.
> Dafür steigt der Ressourcenbedarf enorm weil man viele kleine
> Serverinstanzen mit denselben libs ausrollen muss. Der Admin Aufwand steigt
> auch enorm weil man anstatt eines servers der geclustered wird plötzlich 20
> hat die man clustern muss.
> Der Ansatz ist gar nicht so unähnlich wie man es früher mit remote EJBs
> gemacht hat und davor noch mit Corba bzw. dazwischen dann mit SOAP und SOA.
> Man ist jedesmal für viele Projekte nicht glücklich damit geworden.
> Wo Microservices wirklich viel lösen ist im NodeJS Sektor wo man damit das
> Single Threaded Problem umgehen kann bei hoher Last.

Microservices sind kein Stein der Weisen für "Dumme" (nicht mehr als x Klassen und y Zeilen), sondern Architektur-Regeln, die die Neigung von (selbst state-of-the-art SOA) Monolithen zur krakenhaften "alles-hängt-von-allem-ab" (und das durch alle Schichten bis hinunter zur Persistenz) Monstern wieder in wart- und skalierbare, und weitgehend abgeschlossene Teilsysteme propagiert.

Dabei treten (bereits bekannte) Problemklassen erneut in den Vordergrund, z.B. Konfiguration und Orchestrierung, die im klassischen SOA-Umfeld noch durch ESB abgedeckt werden konnten, aber nun ob der schieren Fülle von Services nicht mehr ausschließlich manuell (von Admins in der Rolle von Fluglotsen) beherrscht werden können.

Wie das Konzept der Microservices konkret realisiert wird, ist nicht von Gott auf ewig vorgegeben. Die von Dir kritisierte Ressourcenverschwendung durch redundante Artefakte kennzeichnet eine bestimmte Vorgehensweise, z.B. "Das machen wir mit Docker oder Kuberxyz". Aber auch hier tut sich etwas, z.B. "Serverless Computing", was ich anfangs und verbatim völlig missverstanden hatte :-)

Für mich selbst sind Microservices ein Regelwerk, das es erlaubt, komplexe (wachsende) Systeme in handhabbare (vor allem Wart- und Skalierbarkeit) Einheiten zu zerteilen. Als Musterbeispiel sehe ich Amazon (die Verkaufsplattform): https://www.tigerteam.dk/wp-content/uploads/2015/02/Composite-UI-Amazon.png

[Lord Gamma]

werpu schrieb:
--------------------------------------------------------------------------------
> ... Maven ...

Gradle vs Maven: Performance Comparison: [gradle.org] ;-)

"This GIF shows the clean build scenario side-by-side so you can get a feel for the difference (without build cache)."
links gradle, rechts maven:




1 mal bearbeitet, zuletzt am 24.08.17 22:16 durch Lord Gamma.