Generelle Frage zu Mikroservices (Spring Boot?), Docker...

[internet]

Hallo zusammen,

ich habe eine generelle Frage zur heutigen Applikationsarchitektur.

Aktuell habe ich ein recht großes Projekt aus Basis von JAVA EE, JSF, Hibernate, JPA.
Am Ende des Tages generiere ich durch Maven ein .war - File, welches ich dann auf meinen Applikationsserver (Wildfly) deploye.

Nun gibt es ja seit einigen Jahren "Microservices". Ich habe mich damit noch nicht wirklich beschäftigt.
Ich sehe aber die Vorteile mein bestehendes Projekt in verschiedene "Services" (Bestellverwaltung, Userverwaltung etc.) zu unterteilen.

Nun habe ich hierzu einige Fragen:
- Mit was für einem Aufwand muss ich generell rechnen um ein JAVA EE - Projekt auf Mikroservices zu migrieren?
- Mit welchen Libraries muss ich mich befassen? Ist das dann Spring Boots?
- Im Moment habe ich ein Java Projekt. Brauche ich dann pro Microservice ein eigenes Java Projekt? Oder habe ich (wie heute) ein einziges Projekt, in welchem verschiedene Services sind
- Kann ich Wildfly als Applikationsserver weiter verwenden?
- Benötige ich nun pro Microservice einen laufenden Applikationsserver?
- Gibt es empfehlenswertes Tutorial, um in the Thematik zu kommen?
- Was hat es mit "Docker" auf sich? Was genau ist das? Welche Software benötigt man dazu?
- Was muss man sonst beachten?

Vielen Dank für jede Hilfe

 

[Tarrew]

Du solltest beachten, dass Microservices nicht immer die richtige Lösung sind. Hast du echten Bedarf deine Architektur umzustellen? Das könnten sein:
- Skalierungsprobleme
- Schlechte Wartbarkeit
- Verschiedene Teams, die aktuell an gleicher Codebasis arbeiten
- Geringe Zuverlässigkeit
- ...

Wenn nichts davon zutrifft, würde ich mal in Frage stellen, ob eine Microservice-Architektur wirklich sinnvoll ist. Microservices können einige Vorteile haben, aber die Grundarchitektur ist erstmal komplexer, da man typischweise zusätzliche Infrastruktur braucht (Service Discovery, Load Balancer, API-Gateway, ...).

Zu deinen Fragen:
1. Der Aufwand hängt von der Göße des Projektes ab und wie viel Erfahrung du in der Dekomposition hast. Wenn man einen Monolithen schlecht aufteilt, hat man am Ende einen verteilten Monolithen, der keinen Vorteil bringt. Man muss schon drauf achten, dass alle Services maximal voneinander entkoppelt sind (Domain-Driven Design kann da ggf. helfen).
2. Spring Boot ist so der Klassiker, Quarkus sieht man ab und zu auch noch.
3. In der Regel ist jeder Service eigenständig und dementsprechend ein eigenes Projekt.
4. Du kannst Wildfly verwenden, aber Spring Boot kommt mit einem eingebetteten Tomcat, macht Sinn den zu verwenden.
5. Jeder Service hat seinen eigenen Webserver
6. Die Seiten von Martin Fowler und Chris Richardson sind ganz gut, um einen groben Überblick zu bekommen und Pattern nachzuschlagen. Von Sam Newman gibt es auch zwei gute Bücher zum Thema Microservices und Migration eines Monolithen. Ein richtiges "Tutorial" kenne ich jetzt nicht.
7. Docker ist ein Tool, welches die Containerisierung unterstützt. Prozesse laufen isoliert in einem Container in der immer gleichen Umgebung. Dadurch wird z. B. die Portabilität erhöht. Ist insbesondere mit DevOps Praktiken sehr verbreitet und definitiv zu empfehlen.
8. Essenziell ist eine gute Aufteilung der Services. Jeder Service soll eigenständig sein und möglichst eine Sache gut selbst erledigen können. Synchrone Interprozess-Kommunikation nach Möglichkeit vermeiden. Microservices stattdessen lose koppeln (über eines EventBus). Stichwort Kafka, RabbitMQ, ... Jeder Microservice hat seine eigene Datenbank, das bringt einige Herausforderungen mit sich (CAP Theorem). In der Regel hat man deswegen "nur" Eventual Consistency.

Microservices können sehr geil sein, man sollte sich aber gut überlegen, ob sich die steigenede initiale Komplexität für den eigenen Use-Case lohnt.

 

[internet]

Vielen Dank schon Mal für die ausführliche Antwort.
Generell ist der Bedarf eher gering bzw. ich weiß nicht, ob es dem Aufwand gegenüber dem Nutzen wirklich gerecht wird.

Aktuell habe ich eine recht große Applikation mit über 100 Entities.
In der Applikation kann ein User dann Rechnungen, Angebote erstellen, Kunden verwalten, Belege sammeln (also ein schlankes ERP und teilweise CRM System).
Zudem habe ich in dem Monoliten aber hier auch meinen eigenen Adminbereich eingebaut.
Dies beinhaltet dann ebenfalls die Rechnungserstellung, Verträge usw....
Das heißt in dem Fall eben auch, wenn ich an meinem Adminbereich oder meiner eigenen Abrechnung etwas ändere und etwas deployen möchten,
ist die Nutzung für meine eigenen Kunden zeitweise nicht erreichbar.... (sehe ich aktuell als den größten Nachteil an)

Prinzipiell wäre eventuell eine Lösung, dass ich meinen Adminbereich (insbesondere meine Abrechnungs und Vertragsverwaltung) separiere und in ein anderes Projekt umführe.
Somit wäre ich etwas freier in der Entwicklung und unabhängig. Allerdings auch nur bedingt.
Denn bspw. müsste der Service meiner Abrechnungs / Vertragsverwaltung / Userverwaltung zB bei einer Neuanmeldung auch verfügbar sein.
Die Kommunikation der zwei Projekte könnte ja dann via REST erfolgen, in dem ich Funktionen für Vertrag anlegen usw.

Aber im Endeffekt stellt sich eben für mich die Frage, ob sich dieser Aufwand wirklich lohnt, insbesondere auch das Aufziehen von einer zweiten Datenbank, Applikation usw.

 

[LimDul]

Mal so ins Blaue geschossen - Wenn das Hauptproblem die Verfügbarkeit während Deployments ist, da gibt es auch andere Lösungen: Load-Balancer und 2 Applicatin Server und entsprechendes Deployment-Verfahren.

Dann ist von außen die Anwendung immer erreichbar über den Load-Balancer

So arbeitet hier im Projekt die Vor-Produktion & Produktion unserer Anwendung.

 

[M.L.]

Zum Thema Docker könnte man hier mal schauen: thenativeweb Docker in 100 Minuten

 

[AndiE]

Ich erlebe das bei "Spring Boot" ein wenig anders, als Tarrew das erklärt hat. Wenn man das installiert hat, kann man sich vorbereitete Anwendungen auf "spring.io" holen, u.a. auch komplette Projekte, wie "petclinic". Das Projekt unterteilt sich in verschiedene Bereiche, u.a. model. Dort werden eine Anzahl gleichartiger Dinge erzeugt, die immer aus Controler, Respository und einer weiteren Klasse bestehen, die das Objekt darstellt. Der Controler stellt dabei nach meinem Wissen den (Mirco-)Service bereeit, wobei es auch "Unterservices" geben kann. So habe ich das auch in dem Buch von "Ajay Kumar" verstanden, in dem es um DDD mit Spring Boot geht.

Sicher ist das DDD nur eine Variante, mit Microservices umzugehen. Ich habe aber dazu noch das Buch von Vaughn Vernon gelesen, wo er das recht gut erklärt.

 

[M.L.]

Zum Thema Docker könnte man hier mal schauen:

EDIT: (richtiger Link, evtl. kann ein Admin korrigieren)

(thenativeweb, Docker in 100 Minuten)

 

[mrBrown]

Ich erlebe das bei "Spring Boot" ein wenig anders, als Tarrew das erklärt hat. Wenn man das installiert hat, kann man sich vorbereitete Anwendungen auf "spring.io" holen, u.a. auch komplette Projekte, wie "petclinic". Das Projekt unterteilt sich in verschiedene Bereiche, u.a. model. Dort werden eine Anzahl gleichartiger Dinge erzeugt, die immer aus Controler, Respository und einer weiteren Klasse bestehen, die das Objekt darstellt. Der Controler stellt dabei nach meinem Wissen den (Mirco-)Service bereeit, wobei es auch "Unterservices" geben kann. So habe ich das auch in dem Buch von "Ajay Kumar" verstanden, in dem es um DDD mit Spring Boot geht.

Das ganze "Spring Boot Projekt" ist ein Microservice.
Alles darin ist nur ein Implementierungsdetail, und kann gelöst werden, wie man will.