Du möchtest das Video an jemanden weiterleiten, die oder der aber lieber liest? Dann findest Du den passenden Artikel zum Video bei Heise Developer: www.heise.de/blog/Risiko-Microservices-Vor-und-Nachteile-einer-verteilten-Architektur-9800271.html
Ich glaube das "Vorurteil" gegen Microservices ist aufgrund eines Trends (viell. im Zuge des Cloud Computing) alles direkt als Microservice zu planen, weil es "modern" ist und Monolithen u.ä. "veraltet" ist. Ich habe oft genug Monolith als Antipattern gehört, auch wenn es oft absolut Sinn macht. Eventuell ähnlich wie mit JS-Frameworks Frontend wie react/vue/etc. die für simple Formulare und CRUD-Seiten verwendet werden, wo simples HTML via Templates direkt vom Backend vollkommen ausreichend wäre.
Ich kann mich noch an Zeiten erinnern wo man quasi gelyncht wurde wenn man nur das Wort Monolith oder Modulith erwähnt hat und sofort die Microservices als absolut korrekte Lösung hingestellt wurden. Nach ein paar Jährchen ist halt jetzt wieder eine Trendumkehr zu spüren. In ein paar Jahren wird die nächste Generation wieder die gleichen Gedankenspiele haben. Es wiederholt sich halt immer wieder in gewisser Weise.
Ich habe an sich nichts gegen Micro-Services und sie haben auch ihre Anwendungsbereiche. Ich bin allerdings der Meinung, dass oft von vornherein gedacht wird man bräuchte auf Grund der komplexen Anforderungen einen Micro-Service-Ansatz und man in der Regel oft nicht bei ersten Versuch alle Domänengrenzen richtig schneidet und es deshalb in meinen Augen besser ist erstmal einen MODULAREN-Monolithen zu bauen und wenn sich gut isolierbare Module herauskristallisieren dann dazu übergeht diese als eigenen Service auszulagern.
Genauso sehe ich das auch. Und das ist auch der Ansatz, den ich als Software-Architekt bei unserem aktuellen Projekt verfolge: Einen modularen Monolithen bauen, der sich mit recht überschaubarem Aufwand auch später noch zu mehreren Microservices zerlegen ließe. Ja klar, es gibt dabei bestimmte Besonderheiten und Einschränkungen, die ich aber nicht als Nachteil sehe, eher im Gegenteil. Man setzt halt von vornherein auf einen einzelnen Entwicklungsstack, dafür tut sich das oder die Teams dann deutlich leichter beim Entwickeln der unterschiedlichen Bounded Contexts auf immer ähnliche Weise. Und durch die Kombination der Möglichkeiten von Sprache, Frameworks und Build Tools lässt sich auch ganz gut sicherstellen, dass die Boundaries auch innerhalb des Modulithen nicht verletzt werden.
Ich denke "Verteilung von Verantwortung, fachliche Grenze und unterschiedliche Teams" ist wirklich ein sehr wichtiger Aspekt, der leider tatsächlich öfter mal vergessen wird. Ich glaube manche Entwickler neigen dazu simple Probleme zu schnell mit komplexen Lösungen zu erschlagen, ähnlich wie DRY oder manche Softwarepatterns bin ins Kleinste verfolgt werden, selbst wenn dies am Ende zu einer höheren Komplexität führt. Es ist aber zugegeben ab und an schwer den richtigen Zeitpunkt zu finden, zu dem man etwas refactoren sollte, um schwer wartbaren Spagetticode zu vermeiden. Aktuell bin ich in der Phase "Simple Lösung bis ca. 50-100 Zeilen Code/Config/Template" - danach aufspalten (Natürlich gibt es immer Ausnahmen, aber auch configs kann man dann zumindest gruppieren). Vorher ist es zu einfach falsche Schlüsse zu ziehen.
Eventuell sollte man noch erwähnen, dass Microservices auch eine große Herausforderung für ein gutes und funktionierendes IT-Security Konzept sind. Das sollte man natürlich beim Risk-Assessment entsprechend berücksichtigen.
inwiefern? Das deployment erfolgt hinter einem reverse proxy, der als einziger Container mit dem Internet verbunden sein muss. Via Netzwerkseparierung sorgt man dafür, dass der RP zusätzlich in einem separaten Netzwerk mit den Services läuft. Die Services und deren Datenbanken laufen wieder in einem eigenen Netzwerk, dass gänzlich von Reverse Proxy entkoppelt ist. Das ist absolut kein Aufwand und hat keinerlei Auswirkung auf die IT-Security.
Schätze die Art wie Du Deine Überlegungen anstellst, also nicht nur der Inhalt, der hier dargestellt wird, sondern auch die Klarheit, Mechanik und Emo-Bias-Free Überlegungen. Denn ich habe oft festgestellt, dass letzteres besonders wichtig ist.
Ja, es ist immer wieder erschreckend und gleichzeitig auch belustigend, wie bei solchen Tech-Trends (oft mit Multi-Mio-Dollar Marketingschlachten der Tech-Giganten gepusht) der gesunde Menschenverstand und das Vertrauen auf die eigene Einschätzung flöten zu gehen scheint. 😀 Golo hat das hier m.E. sehr gut dargestellt. Microservices sind dann eine tolle Sache, wenn es TECHNISCH, FACHLICH und ORGANISATORISCH (alle drei, also UND, nicht ODER!) Sinn macht. Sonst nicht. Punkt. Ansonsten ist der modulare Monolith die logische Wahl. Auch hier können die Module durch entsprechende APIs und Kommunikationsmechanismen sehr unabhängig voneinander entworfen und auch entwickelt werden (minimale Kopplung, maximale Kohäsion). Und eine spätere Auslagerung einzelner Module als Microservices ist dann eine durchaus überschaubare Angelegenheit - WENN denn die obigen Bedingungen tatsächlich vorliegen bzw. erfüllt sind.. Meine Meinung.
Das beste Argument dafür, das ich je dafür gehört habe, warum eventual consistency durchaus akzeptabel ist, war, dass große Geschäftssysteme sowieso immer mit Fremdsystemen (z.B. beim Kunden oder Lieferanten) kommunizieren und diese Daten schließlich auch konsistent gehalten werden müssen.
Microservices machen vor Allem mit kubernetes schon ziemlich viel Sinn. Insbesondere, da es ja für viele Probleme schon Open Source Lösungen gibt. Beispielsweise für JobScheduling kann man einfach einen pod mit cronicle hochziehen, anstatt das alles Selbst zu programmieren. Mit k8s geht das dann halt super schnell
Hmm.. final war es kein Video das das Thema differenziert betrachtet, sondern am Ende hast du nur jedes Argument gegen MS weggewischt und es schließlich (ja, so kam es bei mir an) so aussehen lassen, als wären MS doch das Gelbe vom Ei. Für mich kein gutes Video, da gab es schon deutlich bessere.
Ihre Äusserungen sind richtig. Ich empfehle, die Teams auch als Microservices zu sehen - genauer die unterschiedlichen Human Factors innerhalb der Teams in deren Variation.
Wie immer, ein super Video mit sehr hohem Informationsgehalt. Danke dafür. Ich verstehe die Kritiker. Microservices können die Hölle werden, wenn es sich um ein großes Projekt handelt. Aber, ist das bei Monolithen nicht auch so?? Ich tendiere zu Microservices hauptsächlich wenn es entweder die nicht-funktionalen Anforderungen erfordern oder wenn sich die Fachlichkeit innerhalb des Projekts stark unterscheidet. Also, wenn es klare Domänen gibt und sich Begriffsdefinitionen je Domäne unterscheiden. So oder so ist es bei großen Projekten komplex und man darf sich nicht prinzipiell dagegen wehren. Viele denken immer in einer idealen Welt. Monolithen werden optimal modularisiert, jeder hält sich an Vererbungshierachien etc... Das ist in der Praxis selten bis nie der Fall. Zeitdruck, Abgang von know-how Trägern etc. bringen da schnell Chaos rein. Da liegt für mich das Hauptproblem.
hi, in welchem video habt ihr über HTTP methoden gesprochen, und dass ihr in manchen projekten einfach nur GET und POST benutzt? das hatte glaub ich auch ein akronym mit C am anfang oder so. liebe grüße ✌️
Mich würde interessieren, woher die konkrete Limitierung von maximal grob 5 Microservices pro Team kommt. Meiner Erfahrung nach eher unrealistisch in allen Projekten an denen ich beteiligt war. Aber wenn es gute Gründe dafür gibt, oder Erfahrungen die man teilen könnte, würde mich das interessieren.
Um es kurz zu machen: Persönliche Erfahrung. Natürlich hängt das immer noch vom Team, den konkreten Services, und sonstwas ab … aber fünf Services sind IMHO noch ganz gut machbar (wenn sie nicht zu groß bzw komplex sind). Aber wie gesagt: Letztlich ist das eine Schätzung aus dem Bauchgefühl …
Sehr gut, dass der Punkt mit der Skalierung der Teams angesprochen wurde. Für mein Dafürhalten sollte man auch generell entsprechende Datenmengen oder Anfragezahlen haben, dass es ein einziger großer Server nicht mehr schafft und man technisch gesehen nicht an einem Verteilten System vorbei kommt. Es wäre zudem noch gut dazuzusagen, dass Unabhängigkeit wirklich bedeutet, dass jeder Service mit sämtlichen Versionen der anderen Services funktionieren muss, damit man neue Dienstversionen releasen kann, ohne sich groß abzustimmen. Das ist nämlich den meisten Leuten, die auf Microservices umsteigen wollen, nicht bewusst.
Bzgl. Skalierung. Ich frage mich, von welchen Entwicklern diese Aussage kommt. Also von Entwicklern, die Ruby on Rails, PHP, NodeJS, Python verwenden oder von Entwicklern, die tatsächlich auf effiziente Technologien setzen wie .Net, Java, Go, Rust. Ich bin übrigens kein Webentwickler, sondern stelle nur diese Frage in den Raum. Hab nämlich als Werkstudent mal Android-Entwicklung betrieben und die Firma neben an hat mit Performance-Problemen gekämpft, weil sie Ruby on Rails eingesetzt haben. - Da denke ich mir, das Problem fängt da schon mit der Technologie an und nicht mit der Architektur.
@@StefaNoneD Ja das ist auf jeden Fall ein valider Punkt. Und genau solche Rewrites sind nur dann möglich, wenn man kleine Services hat, die man in 1-2 Wochen in ner anderen Sprache neu schreiben kann. Also ja, umso mehr ein Grund, auf Microservices zu gehen. Man kann mit nem inperformanten Design anfangen, um einen Prototyp in kurzer Entwicklungszeit rauszuhauen und dann die kritischen Komponenten auslagern, sobald man Probleme bekommt.
"Microservices wegen Unabhängigkeit". Meiner Meinung nach ist das der größte Irrglaube über Microservices. Man entwickelt Software ja nicht zum Spaß. Man möchte Business-Prozesse realisieren/unterstützen. Ein Business-Prozess besteht aus mehreren, verschiedenen Aufgaben/Entitäten, die strenggenommen in verschiedene Microservices gehören. Business-Prozesse sind aber nicht starr. Sie verändern sich ständig. Mit neuen oder veränderten Anforderungen muss man nun Änderungen in verschiedenen Microservices durchführen. Das Kann man aber nicht, weil man nicht der Owner ist. Man muss also das zuständige Team darum bitten die Änderung zu implementieren. Was nicht so einfach geht, weil potentiell andere Prozesse von diesem Microservice abhängig sind. Man ist also gezwungen einen neuen Microservice zu entwickeln, zu deployen, zu pflegen,... Dieser läuft in seinem eigenen Container, wo wir jetzt beim "Deployment und Infrastruktur" sind... Natürlich macht es keinen Unterschied, ob man 10 oder 100 Container überwacht, steuert. Aber ist das effizient? Jeder Container kommt mit Overhead. Bei Java Anwendungen ist das einfach die ganze JVM. Jetzt hat man eine JVM die mehr Ressourcen im K8s verbrennt, was in keinem Verhältnis zum Mehrwert der Änderung darstellt. Ist der Microservice zustandsbehaftet, so hat man auch eine Datenbank mehr. Man hat also nicht "nur" einen Microservice mehr. Die Behauptung, dass Strong Consistency nur in den wenigsten Fällen benötigt wird, kann ich so nicht stehen lassen. Ich würde sogar sagen: die meißten Anwendungen brauchen die starke Konsistenz. Die meißten heißt nicht die größten. Klar interessiert es keinen, wenn eine Twitter Nachricht bei User A eine Minute später ankommt als bei User B. Aber die meißten Systeme sind nicht Twitter oder Facebook. Und sobald Geld im Spiel ist, kommt man um C(-A)P nicht herum. Auch im genannten Beispiel wäre das nicht zu unterschätzen. Klar hat man beim Design die Nutzer des Systems befragt und sie sagten, es sei kein Problem. Wir erinnern uns aber, Business-Prozesse sind nicht starr, es kommt eine neue Anforderung, wo plötzlich die starke Konsistenz benötigt wird, was dann? Dann entsteht ein neuer Microservice der im Inneren die Funktionalität derer abbildet, die ein Problem für die Konsistenz darstellten. Oder es wird ein Layer drüber gepackt, der solange blockiert, bis die Konsistenz erreicht ist und der Prozess weitergehen kann. Später kommt mehr Traffic auf das System, die Kommunikation zwischen den Microservice steigt, Kunden beschweren sich, dass die Anwendung so langsam reagiert, Management beschwert sich, dass die AWS Rechnung so hoch ist, es kann ja nicht sein, dass eine so simple Anwendung so hohe Kosten verursacht... Wo bei einem Monolithen die Funktion kurz in den Arbeitsspeicher muss oder vielleicht sogar auch nur in den CPU Cache, muss sie bei einer Microservice Architektur plötzlich übers Netzwerk, über Proxies, sich mehrmals authentifizieren... Keiner redet über den Umweltschaden der dadurch entsteht. Heißt das, dass Microservices schlecht sind und man soll nur noch Monolithen bauen? Natürlich nicht, man sollte aber nicht damit beginnen, sich zu überlegen ob das Eine oder Andere das Richtige sei, sondern, welche Business-Prozesse hat mein System zu erfüllen. Und dann legt man los und baut es nach bestem Wissen und Gewissen, so dass es a) funktioniert und b) es effizient tut. Man sollte sich nicht für die eine oder andere Architektur entscheiden müssen. Sie entsteht ganz natürlich mit der Zeit. Und dann weiß man, ob die eine oder andere Architektur besser wäre. Und wenn diese Erkentnis kommt, dann habt ihr alles richtig gemacht. Dann habt ihr die Produktion überlegt und euer System wird tatsächlich genutzt ;)
Ich glaube die Leute haten es einfach weils aufwendiger ist und man vieles machen muss was einem Entwickler in der Regel nicht gefällt, es ist oft nervig wenn ich angewiesen bin am Service und nur kleinigkeiten geändert brauche ich alles umstellen muss und programmieren muss.
Auch bei embedded wird mit docker gearbeitet, weniger beim deployment aber beim build und test. Da man im docker container weit näher am Zielsystem ist.
Wie immer ein sehr gutes Video und - um ehrlich zu sein - auch eine kleine Bestätigung für eine Architekturentscheidung die ich gerade erst vor ein paar Monaten getroffen habe, darum auch danke für den Wohlfühlfaktor.
Ich zitiere mal die Unix-Philosophie: "This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface." Wenn das nicht (im weitesten Sinne) Microservices sind, weiß ich auch nicht... 🤷
@@christianbaer2897 Die Philosophie gibts auch bei Großrechnern, die allerdings eine Verfügbarkeit der berühmten 5 Neuner aufweist (99,999%, also ca. 4 Minuten pro Jahr). Sobald die Entwickler-/Betreiber begreifen, dass sie selbst Microservices und schwer austauschbar sind, kommen wir weiter. Wir beide sind uns sicher einig, die Technik ist spitze. Wie die Philosophie, aber nicht "strict" angewandt, steigt das Betriebsrisiko nicht linear.
![Diggy Graves - Red Vineyard [Official Lyric Video]](http://i.ytimg.com/vi/8Ro085T0mnQ/mqdefault.jpg)
![Quando Rondo - Life Goes On [Official Music Video]](http://i.ytimg.com/vi/eIf3fhMXAow/mqdefault.jpg)
Du möchtest das Video an jemanden weiterleiten, die oder der aber lieber liest? Dann findest Du den passenden Artikel zum Video bei Heise Developer: www.heise.de/blog/Risiko-Microservices-Vor-und-Nachteile-einer-verteilten-Architektur-9800271.html
Ich glaube das "Vorurteil" gegen Microservices ist aufgrund eines Trends (viell. im Zuge des Cloud Computing) alles direkt als Microservice zu planen, weil es "modern" ist und Monolithen u.ä. "veraltet" ist. Ich habe oft genug Monolith als Antipattern gehört, auch wenn es oft absolut Sinn macht.
Eventuell ähnlich wie mit JS-Frameworks Frontend wie react/vue/etc. die für simple Formulare und CRUD-Seiten verwendet werden, wo simples HTML via Templates direkt vom Backend vollkommen ausreichend wäre.
Ich kann mich noch an Zeiten erinnern wo man quasi gelyncht wurde wenn man nur das Wort Monolith oder Modulith erwähnt hat und sofort die Microservices als absolut korrekte Lösung hingestellt wurden. Nach ein paar Jährchen ist halt jetzt wieder eine Trendumkehr zu spüren. In ein paar Jahren wird die nächste Generation wieder die gleichen Gedankenspiele haben. Es wiederholt sich halt immer wieder in gewisser Weise.
Ich habe an sich nichts gegen Micro-Services und sie haben auch ihre Anwendungsbereiche.
Ich bin allerdings der Meinung, dass oft von vornherein gedacht wird man bräuchte auf Grund der komplexen Anforderungen einen Micro-Service-Ansatz und man in der Regel oft nicht bei ersten Versuch alle Domänengrenzen richtig schneidet und es deshalb in meinen Augen besser ist erstmal einen MODULAREN-Monolithen zu bauen und wenn sich gut isolierbare Module herauskristallisieren dann dazu übergeht diese als eigenen Service auszulagern.
Genauso sehe ich das auch. Und das ist auch der Ansatz, den ich als Software-Architekt bei unserem aktuellen Projekt verfolge: Einen modularen Monolithen bauen, der sich mit recht überschaubarem Aufwand auch später noch zu mehreren Microservices zerlegen ließe. Ja klar, es gibt dabei bestimmte Besonderheiten und Einschränkungen, die ich aber nicht als Nachteil sehe, eher im Gegenteil. Man setzt halt von vornherein auf einen einzelnen Entwicklungsstack, dafür tut sich das oder die Teams dann deutlich leichter beim Entwickeln der unterschiedlichen Bounded Contexts auf immer ähnliche Weise. Und durch die Kombination der Möglichkeiten von Sprache, Frameworks und Build Tools lässt sich auch ganz gut sicherstellen, dass die Boundaries auch innerhalb des Modulithen nicht verletzt werden.
Ich denke "Verteilung von Verantwortung, fachliche Grenze und unterschiedliche Teams" ist wirklich ein sehr wichtiger Aspekt, der leider tatsächlich öfter mal vergessen wird.
Ich glaube manche Entwickler neigen dazu simple Probleme zu schnell mit komplexen Lösungen zu erschlagen, ähnlich wie DRY oder manche Softwarepatterns bin ins Kleinste verfolgt werden, selbst wenn dies am Ende zu einer höheren Komplexität führt. Es ist aber zugegeben ab und an schwer den richtigen Zeitpunkt zu finden, zu dem man etwas refactoren sollte, um schwer wartbaren Spagetticode zu vermeiden.
Aktuell bin ich in der Phase "Simple Lösung bis ca. 50-100 Zeilen Code/Config/Template" - danach aufspalten (Natürlich gibt es immer Ausnahmen, aber auch configs kann man dann zumindest gruppieren). Vorher ist es zu einfach falsche Schlüsse zu ziehen.
Eventuell sollte man noch erwähnen, dass Microservices auch eine große Herausforderung für ein gutes und funktionierendes IT-Security Konzept sind. Das sollte man natürlich beim Risk-Assessment entsprechend berücksichtigen.
inwiefern? Das deployment erfolgt hinter einem reverse proxy, der als einziger Container mit dem Internet verbunden sein muss.
Via Netzwerkseparierung sorgt man dafür, dass der RP zusätzlich in einem separaten Netzwerk mit den Services läuft. Die Services und deren Datenbanken laufen wieder in einem eigenen Netzwerk, dass gänzlich von Reverse Proxy entkoppelt ist.
Das ist absolut kein Aufwand und hat keinerlei Auswirkung auf die IT-Security.
Alles rund um Auth wird sofort komplex, wenn man eine MS Landschaft hochzieht @@agguLi
Schätze die Art wie Du Deine Überlegungen anstellst, also nicht nur der Inhalt, der hier dargestellt wird, sondern auch die Klarheit, Mechanik und Emo-Bias-Free Überlegungen. Denn ich habe oft festgestellt, dass letzteres besonders wichtig ist.
Ja, es ist immer wieder erschreckend und gleichzeitig auch belustigend, wie bei solchen Tech-Trends (oft mit Multi-Mio-Dollar Marketingschlachten der Tech-Giganten gepusht) der gesunde Menschenverstand und das Vertrauen auf die eigene Einschätzung flöten zu gehen scheint. 😀 Golo hat das hier m.E. sehr gut dargestellt. Microservices sind dann eine tolle Sache, wenn es TECHNISCH, FACHLICH und ORGANISATORISCH (alle drei, also UND, nicht ODER!) Sinn macht. Sonst nicht. Punkt.
Ansonsten ist der modulare Monolith die logische Wahl. Auch hier können die Module durch entsprechende APIs und Kommunikationsmechanismen sehr unabhängig voneinander entworfen und auch entwickelt werden (minimale Kopplung, maximale Kohäsion). Und eine spätere Auslagerung einzelner Module als Microservices ist dann eine durchaus überschaubare Angelegenheit - WENN denn die obigen Bedingungen tatsächlich vorliegen bzw. erfüllt sind..
Meine Meinung.
Das beste Argument dafür, das ich je dafür gehört habe, warum eventual consistency durchaus akzeptabel ist, war, dass große Geschäftssysteme sowieso immer mit Fremdsystemen (z.B. beim Kunden oder Lieferanten) kommunizieren und diese Daten schließlich auch konsistent gehalten werden müssen.
Microservices machen vor Allem mit kubernetes schon ziemlich viel Sinn. Insbesondere, da es ja für viele Probleme schon Open Source Lösungen gibt. Beispielsweise für JobScheduling kann man einfach einen pod mit cronicle hochziehen, anstatt das alles Selbst zu programmieren. Mit k8s geht das dann halt super schnell
Hmm.. final war es kein Video das das Thema differenziert betrachtet, sondern am
Ende hast du nur jedes Argument gegen MS weggewischt und es schließlich (ja, so kam es bei mir an) so aussehen lassen, als wären MS doch das Gelbe vom Ei.
Für mich kein gutes Video, da gab es schon deutlich bessere.
Ihre Äusserungen sind richtig. Ich empfehle, die Teams auch als Microservices zu sehen - genauer die unterschiedlichen Human Factors innerhalb der Teams in deren Variation.
Wie immer, ein super Video mit sehr hohem Informationsgehalt. Danke dafür.
Ich verstehe die Kritiker. Microservices können die Hölle werden, wenn es sich um ein großes Projekt handelt.
Aber, ist das bei Monolithen nicht auch so??
Ich tendiere zu Microservices hauptsächlich wenn es entweder die nicht-funktionalen Anforderungen erfordern oder wenn sich die Fachlichkeit innerhalb des Projekts stark unterscheidet.
Also, wenn es klare Domänen gibt und sich Begriffsdefinitionen je Domäne unterscheiden. So oder so ist es bei großen Projekten komplex und man darf sich nicht prinzipiell dagegen wehren.
Viele denken immer in einer idealen Welt. Monolithen werden optimal modularisiert, jeder hält sich an Vererbungshierachien etc... Das ist in der Praxis selten bis nie der Fall. Zeitdruck, Abgang von know-how Trägern etc. bringen da schnell Chaos rein. Da liegt für mich das Hauptproblem.
hi, in welchem video habt ihr über HTTP methoden gesprochen, und dass ihr in manchen projekten einfach nur GET und POST benutzt? das hatte glaub ich auch ein akronym mit C am anfang oder so. liebe grüße ✌️
habs gefunden: CQRS bzw das video "commands und queries statt REST"
Mich würde interessieren, woher die konkrete Limitierung von maximal grob 5 Microservices pro Team kommt.
Meiner Erfahrung nach eher unrealistisch in allen Projekten an denen ich beteiligt war.
Aber wenn es gute Gründe dafür gibt, oder Erfahrungen die man teilen könnte, würde mich das interessieren.
Um es kurz zu machen: Persönliche Erfahrung.
Natürlich hängt das immer noch vom Team, den konkreten Services, und sonstwas ab … aber fünf Services sind IMHO noch ganz gut machbar (wenn sie nicht zu groß bzw komplex sind).
Aber wie gesagt: Letztlich ist das eine Schätzung aus dem Bauchgefühl …
Sehr gut, dass der Punkt mit der Skalierung der Teams angesprochen wurde.
Für mein Dafürhalten sollte man auch generell entsprechende Datenmengen oder Anfragezahlen haben, dass es ein einziger großer Server nicht mehr schafft und man technisch gesehen nicht an einem Verteilten System vorbei kommt.
Es wäre zudem noch gut dazuzusagen, dass Unabhängigkeit wirklich bedeutet, dass jeder Service mit sämtlichen Versionen der anderen Services funktionieren muss, damit man neue Dienstversionen releasen kann, ohne sich groß abzustimmen. Das ist nämlich den meisten Leuten, die auf Microservices umsteigen wollen, nicht bewusst.
Bzgl. Skalierung. Ich frage mich, von welchen Entwicklern diese Aussage kommt. Also von Entwicklern, die Ruby on Rails, PHP, NodeJS, Python verwenden oder von Entwicklern, die tatsächlich auf effiziente Technologien setzen wie .Net, Java, Go, Rust.
Ich bin übrigens kein Webentwickler, sondern stelle nur diese Frage in den Raum. Hab nämlich als Werkstudent mal Android-Entwicklung betrieben und die Firma neben an hat mit Performance-Problemen gekämpft, weil sie Ruby on Rails eingesetzt haben. - Da denke ich mir, das Problem fängt da schon mit der Technologie an und nicht mit der Architektur.
@@StefaNoneD Ja das ist auf jeden Fall ein valider Punkt. Und genau solche Rewrites sind nur dann möglich, wenn man kleine Services hat, die man in 1-2 Wochen in ner anderen Sprache neu schreiben kann. Also ja, umso mehr ein Grund, auf Microservices zu gehen. Man kann mit nem inperformanten Design anfangen, um einen Prototyp in kurzer Entwicklungszeit rauszuhauen und dann die kritischen Komponenten auslagern, sobald man Probleme bekommt.
"Microservices wegen Unabhängigkeit". Meiner Meinung nach ist das der größte
Irrglaube über Microservices. Man entwickelt Software ja nicht zum Spaß. Man
möchte Business-Prozesse realisieren/unterstützen.
Ein Business-Prozess besteht aus mehreren, verschiedenen Aufgaben/Entitäten, die
strenggenommen in verschiedene Microservices gehören. Business-Prozesse sind aber
nicht starr. Sie verändern sich ständig. Mit neuen oder veränderten Anforderungen
muss man nun Änderungen in verschiedenen Microservices durchführen. Das Kann man
aber nicht, weil man nicht der Owner ist. Man muss also das zuständige Team darum
bitten die Änderung zu implementieren. Was nicht so einfach geht, weil potentiell
andere Prozesse von diesem Microservice abhängig sind. Man ist also gezwungen
einen neuen Microservice zu entwickeln, zu deployen, zu pflegen,... Dieser läuft
in seinem eigenen Container, wo wir jetzt beim "Deployment und Infrastruktur"
sind...
Natürlich macht es keinen Unterschied, ob man 10 oder 100 Container überwacht,
steuert. Aber ist das effizient? Jeder Container kommt mit Overhead. Bei Java
Anwendungen ist das einfach die ganze JVM. Jetzt hat man eine JVM die mehr
Ressourcen im K8s verbrennt, was in keinem Verhältnis zum Mehrwert der Änderung
darstellt. Ist der Microservice zustandsbehaftet, so hat man auch eine Datenbank
mehr. Man hat also nicht "nur" einen Microservice mehr.
Die Behauptung, dass Strong Consistency nur in den wenigsten Fällen benötigt
wird, kann ich so nicht stehen lassen. Ich würde sogar sagen: die meißten
Anwendungen brauchen die starke Konsistenz. Die meißten heißt nicht die größten.
Klar interessiert es keinen, wenn eine Twitter Nachricht bei User A eine Minute
später ankommt als bei User B. Aber die meißten Systeme sind nicht Twitter oder
Facebook. Und sobald Geld im Spiel ist, kommt man um C(-A)P nicht herum. Auch im
genannten Beispiel wäre das nicht zu unterschätzen. Klar hat man beim Design die
Nutzer des Systems befragt und sie sagten, es sei kein Problem. Wir erinnern uns
aber, Business-Prozesse sind nicht starr, es kommt eine neue Anforderung, wo
plötzlich die starke Konsistenz benötigt wird, was dann? Dann entsteht ein neuer
Microservice der im Inneren die Funktionalität derer abbildet, die ein Problem
für die Konsistenz darstellten. Oder es wird ein Layer drüber gepackt, der solange
blockiert, bis die Konsistenz erreicht ist und der Prozess weitergehen kann.
Später kommt mehr Traffic auf das System, die Kommunikation zwischen den
Microservice steigt, Kunden beschweren sich, dass die Anwendung so langsam
reagiert, Management beschwert sich, dass die AWS Rechnung so hoch ist, es kann
ja nicht sein, dass eine so simple Anwendung so hohe Kosten verursacht...
Wo bei einem Monolithen die Funktion kurz in den Arbeitsspeicher muss oder
vielleicht sogar auch nur in den CPU Cache, muss sie bei einer Microservice
Architektur plötzlich übers Netzwerk, über Proxies, sich mehrmals
authentifizieren... Keiner redet über den Umweltschaden der dadurch entsteht.
Heißt das, dass Microservices schlecht sind und man soll nur noch Monolithen bauen?
Natürlich nicht, man sollte aber nicht damit beginnen, sich zu überlegen ob das
Eine oder Andere das Richtige sei, sondern, welche Business-Prozesse hat mein
System zu erfüllen. Und dann legt man los und baut es nach bestem Wissen und
Gewissen, so dass es a) funktioniert und b) es effizient tut. Man sollte sich
nicht für die eine oder andere Architektur entscheiden müssen. Sie entsteht ganz
natürlich mit der Zeit. Und dann weiß man, ob die eine oder andere Architektur
besser wäre. Und wenn diese Erkentnis kommt, dann habt ihr alles richtig gemacht.
Dann habt ihr die Produktion überlegt und euer System wird tatsächlich genutzt ;)
Ich glaube die Leute haten es einfach weils aufwendiger ist und man vieles machen muss was einem Entwickler in der Regel nicht gefällt, es ist oft nervig wenn ich angewiesen bin am Service und nur kleinigkeiten geändert brauche ich alles umstellen muss und programmieren muss.
Wieso sagst Du immer so utopische Sachen wie "sollte sich in der Organisationsstruktur widerspiegeln"? 🙃😎
Fazit: wenn man weiß was man tut dann klappt es auch mit Microservices ...
Ich schreibe gerade meine Bachelorarbeit zu dem Thema. Bei Bedarf kann ich - wenn ich durchs Kolloqium durch bin, das ganze Teilen?
Auch bei embedded wird mit docker gearbeitet, weniger beim deployment aber beim build und test. Da man im docker container weit näher am Zielsystem ist.
Wie immer ein sehr gutes Video und - um ehrlich zu sein - auch eine kleine Bestätigung für eine Architekturentscheidung die ich gerade erst vor ein paar Monaten getroffen habe, darum auch danke für den Wohlfühlfaktor.
Was passiert mit zuviele Microservices sieht man diese Tage ganz deutlich an EBay. Da klappt gerade gar nichts mehr reibungslos.
Lotus Notes/-Domino ist ab 1996 auch eine Sammlung von Microservices. Auch SAP durch und mit ABAP kann man so sehen.
Ich zitiere mal die Unix-Philosophie: "This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface."
Wenn das nicht (im weitesten Sinne) Microservices sind, weiß ich auch nicht... 🤷
@@christianbaer2897 Die Philosophie gibts auch bei Großrechnern, die allerdings eine Verfügbarkeit der berühmten 5 Neuner aufweist (99,999%, also ca. 4 Minuten pro Jahr). Sobald die Entwickler-/Betreiber begreifen, dass sie selbst Microservices und schwer austauschbar sind, kommen wir weiter. Wir beide sind uns sicher einig, die Technik ist spitze. Wie die Philosophie, aber nicht "strict" angewandt, steigt das Betriebsrisiko nicht linear.