Microservices schneiden - Schnitt und Architektur

Entscheidend für eine Microservices Architektur ist der Schnitt der Services. Im Gegensatz zu bisherigen Architekturen wie z.B. der Service orientierten Architektur, erfolgt der Schnitt einer Anwendung nicht mehr horizontal, sondern vertikal. Die Platzierung des Schnittes und die Größe der Services haben einen Einfluss auf die Qualität der Architektur. Erfolgt zum Beispiel der Schnitt der Services zu kleinteilig, so entstehen zwangsläufig horizontale Schnitte durch die Anwendung, die ungewollte Nachteile mit sich bringen.
Wie genau sollen der Schnitt oder das Zerlegen eines Monolithen erfolgen? Welche Anhaltspunkte für einen passenden Schnitt gibt es? Antworten auf diese Fragen liefern Architekturprinzipien sowie das Domain Driven Design.
Im Video lernst du verschiedene Arten kennen, wie eine Anwendung in Services gegliedert werden kann. Du erfährst, welche Auswirkung die Art des Schnittes auf die Architektur hat und welche grundlegenden Microservices Architekturen es gibt.
Inhalt
00:00:00 Einleitung
0:02:20 Microservice Definition
0:02:50 Monolith
0:03:05 Horizontaler Schnitt
0:04:54 Vertikaler Schnitt
0:05:40 Share Nothing
0:05:55 Datenbank Modell
0:07:48 Beispiel Datenmodell für den Schnitt
0:09:24 Erster Versuch: Gemeinsame Datenbank
0:10:40 Nachteile einer gemeinsamen Datenbank
0:12:42 Microservices mit NoSQL DB
0:14:23 Gemeinsame Services
0:14:50 Master APIs für Microservices
0:15:30 Antipattern: CRUD Services
0:16:07 Abhängigkeiten und Änderungen
0:18:40 Wiederverwendbarkeit
0:19:58 Geld sparen mit Microservices?
0:20:47 Wiederverwendbarkeit oder Flexibilität
0:22:20 CRUD Services: Probleme beim Join
0:24:05 Performance bei Joins
0:25:20 Lessons Learned from SOA
0:27:30 Microservice != Serivce Orientierung
0:27:45 Schichtung und Orchestration
0:29:08 REST + JSON + Swagger + CRUD Services = Reinkarnation der SOA
0:32:30 Kohäsion und lose Kopplung
0:33:20 Beispiel zur engen und losen Kopplung
0:35:30 Service Refactoring
0:36:45 Service Größe
0:37:37 Zerschneiden des Monolithen
0:40:20 Redundanz
0:48:24 Domain Driven Design
0:51:25 Eventbus
0:51:40 Eventually consistency
0:57:44 Amazon Beispiel
1:00:01 Was wird geteilt?
1:01:10 Bus Adapter
1:04:48 Migration zu Microservices
1:06:00 Zusammenfassung
1:08:00 Microservices Definition
1:09:54 Share Everything und Nothing
1:10:10 Fazit
Unsere Microservices Seminare
Microservices Architektur für IT-Manager und Entscheider
www.predic8.de/microservices-entscheider-schulung.htm
Microservices Grundlagen
www.predic8.de/microservices-schulung.htm
Microservices Workshop mit Docker, Spring Boot & Spring Cloud
www.predic8.de/microservices-spring-boot-docker-workshop-schulung.htm
Mehr zu uns findest du unter:
www.predic8.de
thomasub
Quellen:
Karte mit Topologie:
opentopomap.org

[@mhl1740]

Gehört zu den besten Videos zu dem Thema, die ich je gesehen habe! Danke!

[@thomas-bayer]

Danke

[@wernerzirkel2753]

Super informativ und locker. Da spricht jemand mit viel Erfahrung.

[@QBulletSconosciuto]

Das erste Microservice Video, aus dem ich etwas praktisches mitnehmen kann. Thumb up

[@kurtmullner3488]

Der Aufbau deiner Präsentation war extraklasse.

[@Murray2000]

Ich musste ziemlich häufig schmunzeln, als es an die historischen Architekturen ging. Das habe ich teils "am eigenen Leib" erlebt bzw. bei Kundenprojekten gesehen. Vielen Dank für die Super-Übersicht und die Ideen dahinter.

[@thomas-bayer]

Hallo Danny, danke für das Feedback und deinen Kommentar.

[@tharoncaldas9676]

Vielen Dank für dieses tolle, informative und gut strukturierte Video! 👍 Ich habe sehr viel gelernt und jetzt erst Microservices "richtig" verstanden 😎

[@thomas-bayer]

Hallo Tharon, danke für den Kommentar und das Feedback.

[@frankoppermann1877]

Super Video. Besonders den Konflikt zwischen Wiederverwendbarkeit und Flexibilität hast Du sehr gut verdeutlicht.

[@denizg571]

Top Präsentation Thomas!

[@peterweinmann7483]

Sympathisch, kurz und bündig, jetzt habe ich endlich kapiert um was es bei MS geht! Danke!

[@naheliegend5222]

Richtig gute Präsentation. Die Gradd-Services aka CRUD, werde ich nie wieder vergessen :D

[@thomas-bayer]

Danke für dein Feedback.

[@josefkreulich5735]

Super Sache, super erklärt und mit einem Ansatz versehen

[@predic8]

Danke Josef für deine positives Feedback.

[@bagorolin]

Sehr interessantes und informatives Video! Danke! Nur das abrupte Ende ist etwas schade

[@kohlerpeter1140]

Sehr interessant und informativ. Vielen Dank dafür!

[@abergy87]

Sensationelles Video! Bin noch nicht lange Abonnent, deshalb die Frage: Gibt es schon ein Video das den Microservice am Ende (UI+Logik+DB++Listener) skalierbar macht? Mir hat das Video gerade sehr viele AHA-Effekte gebracht. Aber die Frage ist für mich am Ende noch offen geblieben. Was mache ich, wenn ich zwei von diesen MS habe, die dieselbe Datenbank nutzen? Dann Microservice-Interne Transaktionen?

[@thomas-bayer]

Hallo Alexander, Microservices können auf verschiedene Arten skaliert werden. Eine elegante Möglichkeit ist Instanzen aus (UI, Logik, Listener und DB) über einen Message Bus zu synchronisieren. Die Anzahl der Instanzen kann dann mit der Last skaliert werden. Dadurch, dass jeder Microservice eine DB hat, skalieren auch die Datenbankabfragen. Im letzten Drittel des Videos wird der Setup beschrieben, allerdings erwähne ich nicht, dass man neben verschiedenen Microservices auch die Instanzen eines Microservice darüber skalieren kann. Eine ausführlichere Beschreibung findest du in den Videos zu Eventsourcing mit Apache Kafka kzbin.info/www/bejne/h5utopZrdrGjgdU . Eventsourcing löst viele Probleme bei der Konsistenz und dem Zugriff auf die Datenbank. Es bleiben allerdings die Einschränkungen der „Eventual Consistency“, mit denen man aber oft ganz gut auskommen kann.

[@abergy87]

Hallo Thomas. Vielen Dank für die Antwort. Habe mir die kurze Videoreihe zu Eventsourcing und Kafka angeschaut. Für mich gibt es demnach zwei Möglichkeiten. 1. Ich skaliere den MS mit Datenbank und die Daten werden bei Start aus dem Eventbus gelesen. Dann ist die Datenbank eigentlich der Eventbus, wenn mal alle MS abgeschaltet sind. ODER 2. Ich skaliere nur den MS und nicht die Datenbank, damit ich die Events nicht bei der Skalierung jedes Mal neu einlesen muss.

[@predic8]

Hi Alexander, du kannst auch bei Möglichkeit 1. Microservices mit Datenbank skalieren und den Status in der DB halten. Ist die DB eines MS leer, liest er alle Daten vom Bus, ansonsten liest er nur die, die er verpasst hat. Jeder MS hat seine DB und greift beim Lesen darauf zu. Über den Bus informiert er Änderungen ( CQRS Muster).

[@joseafv]

Vielen Dank dafür, sind sie einfach genial!!!

[@robertkorth605]

15:32 "Kreativer Feldmissbrauch" - grossartig LoL Schöner Überblick. Du sprichst offenkundig aus deiner Projekterfahrung. Mir hat auch gefallen, dass du es so direkt ansprichst: Nur weil man WebServices und HTTP und NoSQL nutzt, heisst das noch nicht, dass man eine passende und angemessene Architektur umsetzt. Wie oft werden da alte Weine durch neue Schläuche umgeleitet. Am Rande - du sprichst es ja auch an: Der vertikale Schnitt ist auch notwendig, wenn man seine Softwareprojekte agiler handhaben möchte. Ich wollte damit nur den Kreis von der Entwicklung zur Projektierung schließen :-) 19:01 "Das ist der Deal: Wir tauschen Wiederverwendbarkeit gegen Änderbarkeit und Schnelligkeit! Aber diese Wiederverwendbarkeit, die steckt so in den Köpfen drin..." Grossartigst! Softwareentwicklung ist auch Politik und Psychologie. Dieses Recycling-Pattern ist wie eine Seuche und tatsächlich kaum aus den Köpfen zu kriegen. Vielen Dank, Thomas!

[@predic8]

Hallo Robert, danke für das Feedback und schön zu sehen, dass man mit seinen Erfahrungen nicht allein ist.

[@timschannel247]

Super Beitrag. Großes Dankeschön. Darf ich einen Ratschlag geben? Die Verwendung des Wort "Schneidens" kommt bei vielen Menschen, die nicht wissen worum es geht als negatives Wort an. Zudem sind Software Architekten ja keine Schneider oder Video Cutter. Nennt es doch einfach Separieren, aufteilen oder abstrahieren. ;-)

[@predic8]

Hi Tim, danke für den Tip.

[@kunoSchlonz]

Schöner und leicht verständlicher Vortrag. Habt ihr nicht ein einfaches Beispiel was man sich mal herunterladen kann und ein bisschen experimentieren kann? Gerade das Thema Eventbus habe ich so noch nirgends gesehen. Klingt aber super spannend.

[@thomas-bayer]

Hallo Kuno, zur losen Kopplung von Microservices mit Apache Kafka als Eventbus haben wir eine kleine Reihe ( kzbin.info/www/bejne/h5utopZrdrGjgdU ). In der Beschreibung findest du einen Link zum Code. Für Microservices mit Micronaut, MicroProfile mit Quarkus und Spring Boot findest du bei uns auch Videos mit Codebeispielen.

[@klauswerner]

Großes Lob vom einem IT-Saurier - ich habe es trotzdem verstanden

[@josefpharma4714]

Gutes Video. Was macht ihr, wenn sich die benötigten Artikel-Daten in einem Service ändern. Replay aller vorhandenen Daten Nachrichten? Wer löst das aus?

[@rudioppliger8356]

Vielen Dank. Das ist sehr interessant. Noch eine kleine Frage bez. dem Aufteilen der Entität Artikel in farbige Cluster Blau, Grün, Gelb und Rot. Ist es korrekt, dass dann evt nicht alle Microservices (Cluster) so einen Artikel anlegen können, weil die Muss-Felder nicht vorhanden sind?

[@predic8]

Gute Frage Rudi. Jede Farbe steht für eine Sub-Domäne und jede Sub-Domäne bringt Pflichtfelder mit, die es oft in den anderen Services nicht gibt. Das führt dazu, dass meist nur die Id und der Name ein Pflichtfeld sind. Die anderen sind dann die "optionalen Pflichtfelder". So war das auch bereits beim Enterprise Data Modelling früher. Wenn man eine Datenstruktur für das gesamte Unternehmen über mehrere Anwendungen hinweg erstellt, dann kann man nicht einfach jedes Feld zum Pflichtfeld für alle machen. Ein Weg aus dem Dilemma sind Default-Werte für die Pflichtfelder in anderen Systemen.

[@hongle-jc3ff]

klare Erklärung, vielen Dank

[@timschannel247]

Sry, noch ein wichtige Frage: Graph QL???? Haben wir also DIE Lösung für viele Probleme nutzen können. Swagger (OPEN API?), JSON und noch viel mehr wird mitgeliefert. Gerade für komplexe CMS Systeme auf der Creator Seite unschlagbar, Bro!

[@predic8]

Hi Tim, ich stimme dir zu. GraphQL wäre oft die passendere Alternative. Leider wird zu oft zur "Default" Lösung REST-artige Schnittstelle gegriffen.

[@ThomasPoth]

Thomas, Danke, Danke, Danke! Endlich mal ne richtig gute Erläuterung. Mich würde noch interessieren, wann ich Deiner Meinung nach ne UI in den Microservice integrieren sollte und wann nicht? Nach der reinen Lehre sollte eine UI ja immer Bestandteil eines Microservice sein, richtig? An dieser Stelle im Video kzbin.info/www/bejne/Z4OomKyoh9SqhNk (54:10) sieht man aber auch das ein Microservice einfach "nur" eine API enthalten kann. Hast Du ggf. dazu noch einen Leitsatz um hier die richtige Entscheidung zu treffen? Top Video, nochmal Danke

[@predic8]

Hallo Thomas, du stellst eine der schwierigsten Fragen zu den Microservices. Wie immer in der IT kommt es darauf an. Es gibt viele Möglichkeiten, die alle Vor- und Nachteile haben: z.B. der "Display Monolith", Microfrontends oder serverseitige Komposition. Wenn man die Idee der Microservices am konsequentesten verfolgt, ja dann sollte jeder Microservice seine UI mitbringen. Technologisch kann man viel machen, wenn man sehr gute JavaScript oder UI Entwickler im Team hat. Leider gibt es hier aber oft einen Engpass. Auch wenn die UI integriert wird, spricht viel dafür, eine API dazwischen zu plazieren. Einen einfachen Leitsatz habe ich leider nicht. Aber schau mal in den Vortrag zu Microfrontends von Thorsten Maier von der OIO: www.oio.de/m/konf/wjax2017/Microservice-UI_WJAX2017.pdf

[@ThomasPoth]

@@predic8 Vielen Dank für Deine ausführliche Antwort und den Link. Am Ende wird es auch bei mir wieder im Tagesgeschäft auf einen pragmatischen Ansatz hinauslaufen. Ressourcen wachsen ja leider nicht auf dem DevOps Baum. Dennoch fühlt man sich ja auch der Lehre verpflichtet und möchte sich weiterentwickeln. ;-)

[@m1cannas]

Super

[@marcm3623]

1:03:48 gemeinsamer Bus, Architektur. 1:04:17 Arten von Mikroservice Architekturen = gemeinsame DB oder gemeinsame Services oder gemeinsamer bus Regel Architektur: es gibt immer etwas gemeinsames 1:06:28 mikroservicedefinition als architekturstil und kultur 1:08:19 1:08:31 fazit: das was geteilt wird bestimmt den Service schnitt

[@Xeinoz]

schon mal daran gedacht den computer aus zu lassen und ein buch zu schreiben? seit die Hoffnung gestorben ist. Und jetzt schreibst ein Buch? Nicht nur ein Buch ein Grimoire.

[@predic8]

Hi Cradaxas, daran habe ich tatsächlich schon gedacht. Ich befürchte, mir fehlt die Zeit ;-)

[@jochenthomas7332]

Vielen Dank für dieses tolle Video!