Ich arbeite selbst in einer Microservice Architektur und könnte mir in unserem Fall keinen Monolithen vorstellen, da es ein ziemlich großes Projekt ist. Services, die sich untereinander per REST Schnittstelle aufrufen wären bei uns aber ein absolutes no-go, das kann sehr schnell zu gröberen Performance Problemen und einer starken Kopplung der Services untereinander führen. Wir arbeiten deshalb mit einem Eventbus und unsere Services wissen nichts voneinander. Nach oben hin gibts pro Service nur ein GraphQL Schema, welches im Api Gateway (oder backend for frontend :) ) gestitcht wird. Dieses bietet dann wiederum nur einen großen Graphen nach oben an. Ich bin sehr glücklich mit dem Projekt weil wir einen spannenden und aktuellen Technologie-Stack im Einsatz haben.
Hi Cedric, vielen Dank für deine Videos, der Content ist wirklich super. Was meiner Meinung nach hier etwas zu kurz kam: 1. Natürlich sind Micro Services modern und haben viele Vorteile. Es gibt hier aber auch Nachteile, bzw. bringt diese Art Architektur auch Kosten mit sich. Die Ganze Infrastruktur/ServiceMesh/Logging/ggfl. Transaktionalität wird um einiges Komplexer als in einem Monolithen/modularen Monolithen. 2. Unter anderem durch Punkt 1 bedingt würde ich nicht sagen, dass Monolithen quasi die "alte Welt" und Microservices die "neue Welt" sind. Es kommt hier immer auf den Anwendungsfall an (das hast du ja am Ende des Videos noch angeschnitten). Es gibt durchaus auch heute noch viele Fälle wo die Kosten so einer hochverteilten Architektur einfach nicht Lohnen. Hier gibt es auch viele Mischformen, also dass man, wie du gesagt hast mit einem Monolithen startet und dann im Strangler Verfahren Services ausgliedert, bei denen die Skalierbarkeit etc. eventuell sehr relevant ist. 3. Ein weiterer großer Vorteil von Microservices ist meiner Meinung nach die Technologieunabhängigkeit. Also ich kann meinen Service in Python Coden und du in Java, denn wir laufen ja in dem Beispiel nicht wie ein Monolith z.B. in der selben VM. 4. Die Skalierbarkeit und Ausfallsicherheit ist natürlich auch beim Monolithen möglich. Natürlich nur Horizontal aber dennoch, nur weil in einem Monolithen etwas ausfällt muss nicht gleich alles weg sein. Der Monolith kann z.B. auch 10 mal gehostet und per Load Balancer angesteuert werden. Danke und viele Grüße!
Wieder einmal ein tolles Video! 👌 Aktuell boxe ich mich durch deine Angular-Playlist durch und finde es sehr interessant. Nachdem ich dieses Video auch gesehen habe, wäre es als für mich die Kirsche auf dem Sahnehäubchen, wenn du erklären könntest, wie deratige Services im Angular-Umfeld eingesetzt werden können.
Na ja. Am Ende ist es eine Definitionssache. Ich zum Beispiel habe Django Anwendungen (Monolithen) an verschiedenen Cloud Datenbanken (Microservice) sowie einem S3 Storage die alle außerhalb des Django Servers liegen und unabhängig von der Webanwendung skaliert werden können. Ich kann also trotzdem noch recht horizontal Skalieren ohne in eine klassische Microservice Struktur zu fallen. Auch kann man die Apps innerhalb Djangos unabhängig voneinander gestalten. In einem Monolithen also Modular programmieren. Steigert die Wiederverwendbarkeit und unterschiedliche Teams können an unterschiedlichen Modulen arbeiten. Haben aber Zugriff auf das ganze Backend - der Ansatz ist also eher monolithisch. Das Problem beim Hype um die Microservices (und das erörterst du in deinem Video nicht): 1. Sie arten schnell in Nanoservices aus 2. du kannst sie auf verschiedene Techstacks aufbauen, brauchst aber gleichzeitig immer jemanden der diesen Stack beherrscht 3. man hat hart abgegrenzte Arbeitsbereiche - wird ein Bug reportet, muss man erst die Zuständigkeit abklären und den Bug an das richtige Team weitergeben (wenn es denn noch existiert, falls der Microservice bereits abgeschlossen ist) 4. Bugfixing allgemein wird verkompliziert - bekommst du in deinem Backend for Frontend ein invaliden Response musst du überlegenen wo der Bug entsteht - ist es das Microservice welches am Backend for Frontend angeschlossen ist, ist es ein anderes Microservice, welches worauf das genutzte Microservice zugreift, oder (und hier kann ich die Verschachtelung weiter führen) Ja - LinkedIn, Facebook, RUclips und sogar About You, Zalando, Parship & Co. nutzen Microservices. Die haben aber auch weit über 100 Mitarbeiter in der IT. Hast du ein Entwicklerteam von weniger als 20 Leuten, würde ich eher auf wenige Kompetenzbereiche setzen und einen monolithischen Ansatz wählen. Und nur weil ich auf AWS, Azure oder Google Cloud hoste und verschiedene Datenbanken nutze, habe ich noch keine Microservice Struktur. Da gehört schon mehr zu :)
@@TheMorpheusTutorials Sehr gerne - und natürlich noch ein Punkt: Datenkonsistenz. Man muss über die Systeme hinweg einen konsistenten Datensatz haben. Ist in einem verteilten System nicht immer ganz einfach. Und dann kommen wir in den Bereich der DB Design Patterns
@@TheMorpheusTutorials In dem Sinne - was hältst du denn von einem "Constructive destructives" Video in dem du mal auf einen Cool klingenden Ansatz aufmerksam machst und fast ausschließlich die Contras und Schwierigkeiten in den Vordergrund stellst und wie man diese Probleme eventuell lösen kann?
Mich würde das Thema moderne Streaming und Messaging-Technologien interessieren, ich werfe da mal einen ganzen Strauß an Buzz-Words in die Schale: Message Broker, Kafka, MQTT, RabbitMQ, Redis, PubSub, Firebase, Websockets, WebRTC, GraphQL, NATS, gRPC usw.
Mich würde interessieren, wie man die ganzen Backends praktisch untereinander synchronisiert. Wie skaliert man Datenbanken??? Welche (neuen) Datenbanken gibt es, die Cloud- und Skalierungs-tauglich sind.
Leider einige Fehler (vielleicht der Simplifizierung geschuldet) aber insgesamt eine schöne Erklärung. Ich würde das Video durchaus Nicht-Informatikern empfehlen, um zu verstehen worum es grob geht. Einem Programmierer wiederum würde ich das Video allerdings nicht empfehlen, weil ich befürchten würde dass er/sie sich Halbwissen aneignet, das zu Problemen führt. PS. Ich spreche die "Fehler" hier nicht gezielt an, weil die zugehörigen Erklärungen vermutlich den Rahmen eines Kommentares sprengen würden. Falls Interesse besteht, können wir uns allerdings gerne via Mail austauschen und hier vielleicht sogar eine simpel formulierte Erklärung zu entsprechenden Punkten anfügen. Dinge simpel zu erklären ist nämlich leider nicht meine Stärke. Es wäre allerdings schön, falls es zu einem Austausch zwischen uns kommt, die Leute hier am Ergebnis teilhaben zu lassen.
Was ich mir wünschen würde, wären dazu Themen wie CQS/CQRS, Event Sourcing, Aggregates, (distributed) Transactions, Multi Tenancy, Idempotence, Event Broker (Kafka) etc. :) "Reine" Ressourcen zu diesen Themen sind leider sehr rar, weil die meisten die ganzen Themen mischen und nicht differenzieren. Wenn du da Hilfe brauchst, könnte ich dir eventuell bisschen Ressourcen etc. empfehlen, welche halt nicht immer nur ein Thema behandeln
Dieses Video war, auch für jemanden, der die PLaylist nicht gesehen hat, so nice anzuschauen! Bin ein risen Fan von der "Präsentaion" mit den ganzen Folien. Nur mal so aus Interesse: Wie heisßt das Programm, mit dem du das machst?
@@TheMorpheusTutorials Oh, ich hatte keine Ahnung, dass die Noch so lang weitergeht! Hatte bis jetzt nur den Anfang gesehen freue mich jetzt aber auf den Rest! 😂
Lass' uns mal kurz über das Backend for Frontend reden - definitionsgemäß müsste das doch ein API Gateway sein, richtig? Nun redest du gerne über Python Flask als Microservice / SPA. FRAGE: Kennst du ein Standalone API Gateway in Python welches du empfehlen kannst? Bei meiner Recherche kam ich da nur an AWS Lambda vorbei. Das möchte ich aber nur ungerne nehmen. Ansonsten wird gerne noch Spring Boot Eureka + Zuul genannt - ist halt Java. Mit Nginx geht das auch, aber Nginx ist mir in dem Kontext zu statisch. Gibt es etwas abseits der genannten Services die du aus der Python Welt empfehlen kannst?
Und was macht man wenn die API ausfällt? Dann sind die Services doch auch nicht mehr erreichbar für den Kunden. Oder kann man die API auch skalieren?!😅
Genau deshalb nutzt man etwas wie AWS und Co. Man hat pro service nicht den einen Server, sondern ein verteiltes System (Nodes). Fällt eins aus hast du noch weitere parallel laufen die den Ausfall auffangen können
Ja, und nochmals sorry, dass ich da vorher VERSEHENTLICH!! so einen Negativkommentar losgetreten habe: da kam vorher so eine doofe, ellenlange Werbung, die ich als solche erst mal gar nicht erkannte, die mich dann so genervt hat, dass ich während dieser dann diesen Kommentar auf diese doofe Werbung bezogen, losschrieb... Aber es kommt ja dann das 1A!: Und das bezieht sich wirklich auf dieses Video (von The Morpheus Tutorials!)
Also ich habe jetzt die Werbung gemeint, sorry: Die vorgeschaltete Werbung, die vor der großen Krise warnt....! Das Video schaue ich mir jetzt gleich an....
@@TheMorpheusTutorials Ja, und nochmals sorry: da kam vorher so eine doofe, ellenlange Werbung, die ich als solche erst mal gar nicht erkannte, die mich dann so genervt hat, dass ich während dieser dann diesen Kommentar losschrieb... Weiter oben aber steht ja dann das 1A!: Und das bezieht sich wirklich auf dieses Video
So ein blödsinn. Der tut ja so, als ob man monolithische Anwendungen nicht skalieren kann z.B. zwecks usfallsicherheit oder performance Steigerung. Das ist natürlich falsch. Man kann das alles auch mit monlithischen Anwendungen machen. Nur halt nicht so granular wie mit Microservices.
Ich bezweifle schwer, das größere Microservice-Architekturen heutzutage im Backend untereinander noch über REST APIs kommunizieren. REST hat viel zu viel Overhead, ist langsam und unflexibel. Selbst bei der Frontend Kommunikation ist immer mehr GraphQL im Kommen. Google nutzt meines Wissens *gRPC* im Backend.
sehr einseitige Sicht, es macht nicht immer Sinn auf Microservices zu setzen und die Nachteile der Monolithen sind leicht ausgleichbar. Hätte von dir als RUclipsr und Experten mehr erwartet
Danke für das interessante Video. Gerne mehr zu so Software/System-Architektur sowie Design-Patterns.
Desing-Patterns gibt es schon
Vielen Dank für dieses Video. Ich versuche schon seit langer Zeit zu verstehen wie Microservices funktionieren. Danke!!!
Ich liebe dich Morpheus! Du erklärst einfach immer alles easy und sehr zielgerichtet. Danke für deine Arbeit!
Am Freitag Software Engineering Klausur genau dazu :D das nenn ich Just in Time.
Ich arbeite selbst in einer Microservice Architektur und könnte mir in unserem Fall keinen Monolithen vorstellen, da es ein ziemlich großes Projekt ist. Services, die sich untereinander per REST Schnittstelle aufrufen wären bei uns aber ein absolutes no-go, das kann sehr schnell zu gröberen Performance Problemen und einer starken Kopplung der Services untereinander führen. Wir arbeiten deshalb mit einem Eventbus und unsere Services wissen nichts voneinander. Nach oben hin gibts pro Service nur ein GraphQL Schema, welches im Api Gateway (oder backend for frontend :) ) gestitcht wird. Dieses bietet dann wiederum nur einen großen Graphen nach oben an.
Ich bin sehr glücklich mit dem Projekt weil wir einen spannenden und aktuellen Technologie-Stack im Einsatz haben.
Top! Passt zu meinem Modul Anwendungssysteme/ Informationssysteme welches ich gerade berarbeite.
Hi Cedric,
vielen Dank für deine Videos, der Content ist wirklich super.
Was meiner Meinung nach hier etwas zu kurz kam:
1. Natürlich sind Micro Services modern und haben viele Vorteile.
Es gibt hier aber auch Nachteile, bzw. bringt diese Art Architektur auch Kosten mit sich. Die Ganze Infrastruktur/ServiceMesh/Logging/ggfl. Transaktionalität wird um einiges Komplexer als in einem Monolithen/modularen Monolithen.
2. Unter anderem durch Punkt 1 bedingt würde ich nicht sagen, dass Monolithen quasi die "alte Welt" und Microservices die "neue Welt" sind. Es kommt hier immer auf den Anwendungsfall an (das hast du ja am Ende des Videos noch angeschnitten). Es gibt durchaus auch heute noch viele Fälle wo die Kosten so einer hochverteilten Architektur einfach nicht Lohnen. Hier gibt es auch viele Mischformen, also dass man, wie du gesagt hast mit einem Monolithen startet und dann im Strangler Verfahren Services ausgliedert, bei denen die Skalierbarkeit etc. eventuell sehr relevant ist.
3. Ein weiterer großer Vorteil von Microservices ist meiner Meinung nach die Technologieunabhängigkeit. Also ich kann meinen Service in Python Coden und du in Java, denn wir laufen ja in dem Beispiel nicht wie ein Monolith z.B. in der selben VM.
4. Die Skalierbarkeit und Ausfallsicherheit ist natürlich auch beim Monolithen möglich. Natürlich nur Horizontal aber dennoch, nur weil in einem Monolithen etwas ausfällt muss nicht gleich alles weg sein. Der Monolith kann z.B. auch 10 mal gehostet und per Load Balancer angesteuert werden.
Danke und viele Grüße!
Wieder einmal ein tolles Video! 👌 Aktuell boxe ich mich durch deine Angular-Playlist durch und finde es sehr interessant. Nachdem ich dieses Video auch gesehen habe, wäre es als für mich die Kirsche auf dem Sahnehäubchen, wenn du erklären könntest, wie deratige Services im Angular-Umfeld eingesetzt werden können.
Na ja. Am Ende ist es eine Definitionssache.
Ich zum Beispiel habe Django Anwendungen (Monolithen) an verschiedenen Cloud Datenbanken (Microservice) sowie einem S3 Storage die alle außerhalb des Django Servers liegen und unabhängig von der Webanwendung skaliert werden können. Ich kann also trotzdem noch recht horizontal Skalieren ohne in eine klassische Microservice Struktur zu fallen. Auch kann man die Apps innerhalb Djangos unabhängig voneinander gestalten. In einem Monolithen also Modular programmieren. Steigert die Wiederverwendbarkeit und unterschiedliche Teams können an unterschiedlichen Modulen arbeiten. Haben aber Zugriff auf das ganze Backend - der Ansatz ist also eher monolithisch.
Das Problem beim Hype um die Microservices (und das erörterst du in deinem Video nicht):
1. Sie arten schnell in Nanoservices aus
2. du kannst sie auf verschiedene Techstacks aufbauen, brauchst aber gleichzeitig immer jemanden der diesen Stack beherrscht
3. man hat hart abgegrenzte Arbeitsbereiche - wird ein Bug reportet, muss man erst die Zuständigkeit abklären und den Bug an das richtige Team weitergeben (wenn es denn noch existiert, falls der Microservice bereits abgeschlossen ist)
4. Bugfixing allgemein wird verkompliziert - bekommst du in deinem Backend for Frontend ein invaliden Response musst du überlegenen wo der Bug entsteht - ist es das Microservice welches am Backend for Frontend angeschlossen ist, ist es ein anderes Microservice, welches worauf das genutzte Microservice zugreift, oder (und hier kann ich die Verschachtelung weiter führen)
Ja - LinkedIn, Facebook, RUclips und sogar About You, Zalando, Parship & Co. nutzen Microservices. Die haben aber auch weit über 100 Mitarbeiter in der IT. Hast du ein Entwicklerteam von weniger als 20 Leuten, würde ich eher auf wenige Kompetenzbereiche setzen und einen monolithischen Ansatz wählen.
Und nur weil ich auf AWS, Azure oder Google Cloud hoste und verschiedene Datenbanken nutze, habe ich noch keine Microservice Struktur. Da gehört schon mehr zu :)
Vielen Dank für die Ergänzung!
@@TheMorpheusTutorials Sehr gerne - und natürlich noch ein Punkt: Datenkonsistenz. Man muss über die Systeme hinweg einen konsistenten Datensatz haben. Ist in einem verteilten System nicht immer ganz einfach.
Und dann kommen wir in den Bereich der DB Design Patterns
@@TheMorpheusTutorials In dem Sinne - was hältst du denn von einem "Constructive destructives" Video in dem du mal auf einen Cool klingenden Ansatz aufmerksam machst und fast ausschließlich die Contras und Schwierigkeiten in den Vordergrund stellst und wie man diese Probleme eventuell lösen kann?
Super.Sehr leicht erklärt
Hab’s noch nicht gesehen aber gutes Video 💯👍
😂❤️
@@TheMorpheusTutorials Mach mal was zur Hexagonale Architektur
Good job, cedric!
Mich würde das Thema moderne Streaming und Messaging-Technologien interessieren, ich werfe da mal einen ganzen Strauß an Buzz-Words in die Schale: Message Broker, Kafka, MQTT, RabbitMQ, Redis, PubSub, Firebase, Websockets, WebRTC, GraphQL, NATS, gRPC usw.
Mich würde interessieren, wie man die ganzen Backends praktisch untereinander synchronisiert. Wie skaliert man Datenbanken??? Welche (neuen) Datenbanken gibt es, die Cloud- und Skalierungs-tauglich sind.
🔥🔥
Leider einige Fehler (vielleicht der Simplifizierung geschuldet) aber insgesamt eine schöne Erklärung. Ich würde das Video durchaus Nicht-Informatikern empfehlen, um zu verstehen worum es grob geht. Einem Programmierer wiederum würde ich das Video allerdings nicht empfehlen, weil ich befürchten würde dass er/sie sich Halbwissen aneignet, das zu Problemen führt.
PS. Ich spreche die "Fehler" hier nicht gezielt an, weil die zugehörigen Erklärungen vermutlich den Rahmen eines Kommentares sprengen würden. Falls Interesse besteht, können wir uns allerdings gerne via Mail austauschen und hier vielleicht sogar eine simpel formulierte Erklärung zu entsprechenden Punkten anfügen. Dinge simpel zu erklären ist nämlich leider nicht meine Stärke. Es wäre allerdings schön, falls es zu einem Austausch zwischen uns kommt, die Leute hier am Ergebnis teilhaben zu lassen.
Und wie synchronisiert man die DBs miteinander ?
Was ich mir wünschen würde, wären dazu Themen wie CQS/CQRS, Event Sourcing, Aggregates, (distributed) Transactions, Multi Tenancy, Idempotence, Event Broker (Kafka) etc. :)
"Reine" Ressourcen zu diesen Themen sind leider sehr rar, weil die meisten die ganzen Themen mischen und nicht differenzieren. Wenn du da Hilfe brauchst, könnte ich dir eventuell bisschen Ressourcen etc. empfehlen, welche halt nicht immer nur ein Thema behandeln
Schreib mir sehr sehr gerne mal ne Mail oder per discord 👍
Entsprechen die "Module" in den Abbildungen jetzt einen Service oder eine Datenbank? Oder ist die Datenbank im Service integriert?
Dieses Video war, auch für jemanden, der die PLaylist nicht gesehen hat, so nice anzuschauen! Bin ein risen Fan von der "Präsentaion" mit den ganzen Folien.
Nur mal so aus Interesse: Wie heisßt das Programm, mit dem du das machst?
PowerPoint 😂
Hallo Danke! Ein Thema das sehr wichtig ist bitte mehr davon. Wie wäre es Microservices anhand von Code zu veranschaulichen
Wie funktioniert die API? Ist das ein extra Server der die Requests einfach weiterdelegiert oder wie muss man das verstehen?
Das geht dann auch mit normaler Anwendungssoftware und nicht nur bei Websiten, oder ?
Dazu wären Beispiele auch mal spannend!
Python Flask playlist 😉
@@TheMorpheusTutorials Oh, ich hatte keine Ahnung, dass die Noch so lang weitergeht! Hatte bis jetzt nur den Anfang gesehen freue mich jetzt aber auf den Rest! 😂
1A!
Netflix nutzt auch zum Teil Spring Boot
Lass' uns mal kurz über das Backend for Frontend reden - definitionsgemäß müsste das doch ein API Gateway sein, richtig?
Nun redest du gerne über Python Flask als Microservice / SPA.
FRAGE: Kennst du ein Standalone API Gateway in Python welches du empfehlen kannst? Bei meiner Recherche kam ich da nur an AWS Lambda vorbei. Das möchte ich aber nur ungerne nehmen. Ansonsten wird gerne noch Spring Boot Eureka + Zuul genannt - ist halt Java. Mit Nginx geht das auch, aber Nginx ist mir in dem Kontext zu statisch.
Gibt es etwas abseits der genannten Services die du aus der Python Welt empfehlen kannst?
Und was macht man wenn die API ausfällt?
Dann sind die Services doch auch nicht mehr erreichbar für den Kunden.
Oder kann man die API auch skalieren?!😅
Kann man 😁 das kommt aber in späteren Reihen
Genau deshalb nutzt man etwas wie AWS und Co. Man hat pro service nicht den einen Server, sondern ein verteiltes System (Nodes). Fällt eins aus hast du noch weitere parallel laufen die den Ausfall auffangen können
Ja, und nochmals sorry, dass ich da vorher VERSEHENTLICH!! so einen Negativkommentar losgetreten habe: da kam vorher so eine doofe, ellenlange Werbung, die ich als solche erst mal gar nicht erkannte, die mich dann so genervt hat, dass ich während dieser dann diesen Kommentar auf diese doofe Werbung bezogen, losschrieb... Aber es kommt ja dann das 1A!: Und das bezieht sich wirklich auf dieses Video (von The Morpheus Tutorials!)
Kein Thema 😂❤️
du kannst die werbung nicht von einem morpheus video unterscheiden UND findest die werbung nervig?
Also ich habe jetzt die Werbung gemeint, sorry: Die vorgeschaltete Werbung, die vor der großen Krise warnt....! Das Video schaue ich mir jetzt gleich an....
Magst du das kurz in das andere comment rein editieren? 😅 Sonst könnte man es falsches verstehen, danke dir
@@TheMorpheusTutorials Ja, und nochmals sorry: da kam vorher so eine doofe, ellenlange Werbung, die ich als solche erst mal gar nicht erkannte, die mich dann so genervt hat, dass ich während dieser dann diesen Kommentar losschrieb... Weiter oben aber steht ja dann das 1A!: Und das bezieht sich wirklich auf dieses Video
So ein blödsinn. Der tut ja so, als ob man monolithische Anwendungen nicht skalieren kann z.B. zwecks usfallsicherheit oder performance Steigerung. Das ist natürlich falsch. Man kann das alles auch mit monlithischen Anwendungen machen. Nur halt nicht so granular wie mit Microservices.
Ich bezweifle schwer, das größere Microservice-Architekturen heutzutage im Backend untereinander noch über REST APIs kommunizieren. REST hat viel zu viel Overhead, ist langsam und unflexibel. Selbst bei der Frontend Kommunikation ist immer mehr GraphQL im Kommen. Google nutzt meines Wissens *gRPC* im Backend.
sehr einseitige Sicht, es macht nicht immer Sinn auf Microservices zu setzen und die Nachteile der Monolithen sind leicht ausgleichbar. Hätte von dir als RUclipsr und Experten mehr erwartet
Bis jetzt: 20 Minuten Gelabere, wie schlimm alles ist bzw. wird..... Wann kommen jetzt endlich die 4 Schritte....
Wovon redest du?