Braucht jemand einen JEE Standard?

[schap23]

J2EE war eine Katastrophe. Irgendwelche Softwareingenieure auf Drogen hatte sich ein unheimlich komplexes Gewirr aus Interfaces ausgedacht. Ehe "Hello World" lief, hatte man massenweise Dateien erstellt. Das ganze konnte man nur in den Griff bekommen mit Tools, die einem den Mist generierten.

Dann kam Spring und zeigt, daß das ganze viel, viel einfacher und dabei noch besser ging. J2EE hat dann die 2 eingebüßt und übernahm im Prinzip den Ansatz von Spring.

Heute ist aber der Applicationserver auch weitestgehend Geschichte. Die Leute Deployen nicht mehr Enterprise Beans sondern es werden Microservices entwickelt, die in Containern wie Docker laufen und mit Software wie Kubernetes koordiniert werden. Dabei ist man auch nicht mehr auf Java angewiesen, sondern verwendet die Programmiersprache und Umgebung, die am Besten zu dem Problem paßt.

Insbesondere die Zeit der teueren Java-Applicationserver sollte vorbei sein, ebenso wie die Zeit der großen Server von Sun, IBM, etc. auf denen die liefen. Das sieht man auch daran, daß Oracle offensichtlich Solaris auslaufen läßt.

[Plasma]

Es gibt dann noch das große Gespenst der sog. "Legacy"-Software.

[werpu]

Microservices eignen sich nicht für alle applikationstypen, sie werden halt gerade massiv gehyped.

[werpu]

Ah iwo... Microservices und App Server schliessen sich nicht aus. Im Gegenteil im Regelfall liegen in den sogenannten Microservices auch mini app server embedded. Gewisse Anforderunge hat man immer die sowohl in einer großen App vorhanden sind als auch in einem kleinen Microservices.

Ich sehe Microservices mit gemischten Gefühlen, nichts anderes als was man jetzt probiert hatte man schon in den 90igern mit Corba danach mit Remote EJBs und später mit Cross Server Soap Kommunikation mit Soa. Man verschiebt halt die Komplexität jetzt weg von der eigentlichen App hin zum Kommunikations und deployment Layer. Sprich das Modulbinding wird reduziet, dafür wir der Netzwerk Wartungsaufwand erhöht und irgendwann weiss keiner mehr wass passiert wenn ein Service ausfällt über das über Netzschnittschellen 3 andere Services zugreifen auf die 5 weitere Services zugreifen. Sowas dann auszudebuggen ist die Hölle. Wo es wirklich was löst ist im NodeJS Umfeld, dass wegen der Single Thread Prolematik inherent schlecht skaliert ab einen bestimmten Punkt, wobei man hier vermutlich auch mit einem Cluster weniger Resourcen brauchen würde als mit einem Microservice Ansatz.

Ad Reduktion der Modulkomplexität, bei einem ordentlichen modularen service orientierten Ansatz hat man die Komplexität auch bei einem Single server deployment in Griff. Es ist halt ein gewisser Hype so wie SOA vor einigen Jahren, Nur im Gegensatz zu Soa gibt es halt einige Szenarien wo es Sinn macht. Man sollte immer erst abwarten wieviele sich die Finger verbrennen bevor man auf sowas aufspringt.

Ad Oracle, das grosse Geld liegt in der Tat nicht mehr bei den App Servern sondern in der Cloud. Darum gehts hier eigentlich.

[redmord]

Ich schreib mal kurz wie ich bisher das Thema aufgenommen habe ...

Microservices, orchestriert mit z.B. Kubernetes, haben vor allem den Vorteil, mit simpler Mechanik robuste Systeme bauen zu können. Nicht eine Instanz, sondern viele kleine Instanzen laufen. Wenn eine Abschmiert fällt's nicht auf und wird automatisch und kontrolliert neu gestartet. Deployment ist auch geregelt.

Robustheit durch Redundanz und Lastverteilung sind besondere Vorteile dieser "Denkart". Gleichzeitig nutzt man von beginn an eine Architektur, die eben extrem gut skalieren kann und zwar punktuell und gezielt.

[werpu]

Das Problem liegt im Detail. Microservices sind im Prinzip kleine app server (meist Embedded) die wenig spezialisierte Funktionalität bereitstellen (Do one thing do it right) und über Netzwerkverbindungen verbunden bzw. aufgerufen werden.
Das funktioniert recht gut solange es nicht zuviele Dependencies zwischen den einzeilnen Services gibt. Bzw. die vergrösserte Deployment Komplexität durch Tools abgefangen werden kann. Es gibt aber mehr als wenige Applikationsklassen wo eben diese Komplexität der Modul/Servicebindung durch die Business Logik bedingt eben doch relativ stark ist bzw. wo man eben nicht viele kleine Teams hat die sich um jeweils einen Aspekt der Applikation kümmert und dann schneidet man sich mit Microservices ins eigene Fleisch. Ein weiterer Aspekt ist für Business Applikationen braucht man nunmal einen gewissen Satz an Basisfunktionalität (DB Verbindungen, meist irgendein ORM Layer, ein Kommunikationslayer ein DTO Layer in irgendeiner Form, oft noch etwas lokales Caching, app weites caching kann meist über ein eigenes Microservice gesteuert werdne) das wird dann auf jede Server instanz neu reinrepliziert, sprich der Ressourcen Bedarf steigt enorm pro Instanz). Es stellt sich halt dann die Frage welche Vorteile bietet es. Ausfallssicherheit ? Würde sagen die ist nicht wirklich viel besser als bei einem echten Cluster. Bessere Performance auch nicht wirklich gegenüber einem Cluster. Weniger Probleme wenn ein Teilaspekt der App niedergeht. Das hängt von der Stärke der Modulkopplung ab, kann sein meist ist es aber nicht gegeben. Der Wesentliche Vorteil ist halt man kann Teilaspekte der App durch den Austausch eines Services upgraden ohne gleich die gesamte App zu gefährden. Das erkauft man sich aber dadurch, dass man eine massiv erhöhte Komplexität im Deployment und Administrations Bereich hat und auch einen massiv erhöhten Aufwand im Bereich Testing und Unit Testing.

Wie gesagt für größere Deployments mit Teams von duzenden bis hunderten Entwicklern eventuell ein gangbarer Weg. Aber bei einem mittleren Deployment mit 5-15 Entwicklern würde ich abhänging von der Applikation und Budget 2x überlegen so einen Weg zu gehen.

Es ist wie letztendlich alles derzeit ein Riesenhypethema wo sich viele gerade die Finger verbrennen und in 3-4 Jahren wird man zu einer realistischeren Meinung kommen wo man es einsetzt. Ist halt der übliche Technologieschweinezyklus der halt alle 5-10 Jahren durchs Dorf getrieben wird.

[Benjamin_Damm]

@werpu Danke! Endlich mal jemand der es genau auf den Punkt bringt.