AWS, Azure & Google finden Microservices gut. Damit machen die einfach mehr Umsatz / Gewinn. Wenn ein einzelner Server / Monolith für viele Probleme eine gute Lösung ist, verursacht ein Cluster gerne das x-fache an Kosten. Das wären der Network Overhead, zusätzliche administrative Services die man nur braucht weil man Microservices benutzt, höherer Aufwand für Dev-Ops. Und dann noch Service-Leichen die Kosten verursachen, weil schlicht der Überblick verloren gegangen ist. Die FAANG Truppe wird sich hüten kosteneffiziente Lösungen zu promoten. Eigentlich alle gesponserten Developer Konferenzen auf RUclips loben Microservices. Oder noch besser: Gerne auch auch eine AWS Lambda order Cloud Function die fürs Warten auf die Datenbank bezahlt wird. Der Cloud-Anbieter wird dann für schlechte DB Antwortzeiten auch noch belohnt :D
Zunächst mal vielen Dank für ein weiteres top Video. Euer Kanal macht einfach Spaß und ist hochinformativ! Man merkt, dass ihr aus der Praxis kommt. Die Architektur muss in erster Linie das Geschäftsziel unterstützen und Komplexität verringern. Wenn ich ein recht stabiles Geschäftsmodell habe, was gut planbar ist und wenig unvorhergesehene Ereignisse aufweist, dann fahre ich mit einem gut strukturierten Monolithen aus meiner Erfahrung gar nicht schlecht, da ich viele nicht-funktionale bzw. nicht werttreibende Aktivitäten sehr elegant bündeln kann und es sich auch für den Endanwender wie aus einem Guss anfühlt. Das geht natürlich auch mit Microservices, aber bringt dann auch wieder wieder Komplexität rein, da ich dies ggfs. zentral steuern muss. So oder so kann ich mich den Aussagen des Videos nur anschließen: Es kommt drauf an :)
Was mir als Tester auffällt, wo ich eine Microservice Architektur dahinter erkenne, ist wenn gleiche Funktion in einem Teil der Anwendung funktioniert, und in einem anderen Teil nicht, z.B. Aus dem Einkaufswagen Artikel auf die Wunschliste setzen geht, aus der Artikelartei selbst nicht. Man "zerreisst" die Anwenderfunktion an der technischen Grenze. Und das macht mir Sorgen. Mittlerweile kann fast hinter jeder UI komponente ein microservice liegen der diese mit daten beliefert. Das Testen jeden einzelnen Services wird zwar einfacher, aber man testet weniger im Verbund, weil es für den Verbund nun niemanden mehr gibt der sich ausreichend drum kümmert. Alle sind ja jetzt in Microservice Teams. Man kann richtig Inverse Conway's Law beobachten.
Naja, es gibt noch einen weiteren Nachteil bei Microservices: Man hat nen Payload: Ich habe mal für so mit dem grössten Online-Klamotten-Shop Deutschlands gearbeitet und da war immer die Anforderung: Ein API Request darf nicht länger als 500ms dauern. Wenn sich aber der API Request anhand von 3 Microservice Requests bediente, gingen da mal schnell 200ms von drauf wegen Netzwerktraffic und eben auch der Microservice Payload selber (Framework bootstrappen, Security / IP Check, db Connection starten, ...). Weshalb wir da dann auch teilweise zu übergegangen sind, diese Microservices nicht zu nutzen, sondern unser eigenes Ding zu schreiben, damit wir die 500ms einhalten konnten. Und das ist halt son typisches Beispiel von "in einer heilen Welt als Idee super" vs "Realität".
Danke für das Video. Meine Anmerkungen zu Mikroservices.. Aha, im Leben ist es überall anzuwenden (#ironie). Wir können Reifen von einem Flugzeug an unsere PKWs wechseln, wenn dort Neue erschienen sind. Wir können Gamer-Sitze auch im Bus für die alten Menschen verwenden. Sobald ein neues Modell erschienen ist, können wir den Motor von dem Hubschrauber auch sofort in dem Küchen-Mixer integrieren. Es sind Millionen von Möglichkeiten, die abstrakt-artig-gesehen durch Mikroservices "abgedeckt" werden, jedoch die Welt funktioniert doch anders. Egal, wie klein oder groß man "schneidet" - es kann immer passieren, dass zwar Modulare-Aufbau stattfindet, jedoch kein selbstverständlicher Austausch der einzelnen Komponente durch andere möglich wird, sondern nur die von dem gleichen Typ. Daher ist dieser Hype um Mikroservice genauso schlecht für die Qualität gewesen wie pures Agil, der überall propagiert wird. Denn beide suggerieren, dass man die "alten" Methoden wegschmeißen kann, doch mit sich bringen sie nichts außer Demagogie. Hier sind nur zwei/drei Beispiele - Das Projektmanagement leidet gewaltig, denn eine gute und Termin-treue Planung nicht möglich sei - nur Gerede drum herum - Wenn ein großes Projekt erst eine stabile Architektur benötigt, diese aber angeblich in iterativen Schritten gebaut werden will - das Fundament wird instabil - Wenn eine banale Datei-Speicherung doch nicht durch S3 Buckets ersetzt werden will - Wenn der Ersatz einer CSV-Datei durch einer JSON-Datei bevorzugt wird, egal ob die CSV-Datei bereits 3GB groß ist und der Importer diese kaum "verdauen" kann. - Wenn das gesamte BigData auf Dezentralität setzt, doch für die Realisierung von Data Lake alle Daten angeblich zentral gespeichert werden sollen. Viele von diesen "Trend"-Erscheinungen pure-artig verschlechtern das Gesamtbild und bringen eine bestimmte Kultur der "Alles Egal" - Mentalität. Gesagt wird was anderes, jedoch erleben wir genau das Gegenteil von dem, was propagiert wird. Und das finde ich bedauerlich für die Szene, denn es entstehen Tonnen von schlechtem und nicht langlebendem Code, Architektur usw. Alle diese Themen wie Mikroservices und Agilität sollten als Ergänzungen verstanden werden, jedoch wer macht das schon...
Es liegt daran, dass Golo mehr zu Go, TypeScript, Docker und JS was erzählt und sehr wenig wie in diesem Video für allgemeine Themen. Auch, wenn mich die og. Themen gar nicht angehen - bin ich trotzdem hier. Denn. Die Art, wie er die Themen erzählt, finde ich einmalig - sehr authentisch, freundlich, wortbegabt, nicht herablassend - wie ein kluger Kumpel, dem man gerne zuhört. Aber eben - er geht sehr eng spezifische Themen an (aus meiner Sicht). Er sollte mehr aufgreifen - Software Engineering, Projektmanagement, Daten-Modellierung und und und - die Welt wartet nur auf solche Beiträge 🙂 - und dann wird auch die Community größer.
Eigentlich überspringe ich bei Texten und Videos immer die Einleitung. Aber ich muss sagen, dass die Einleitung in diesem Video extrem gut strukturiert worden ist und Interesse für das Thema erweckt. RIchtig gutes Video :)
Ein Problem was ich häufig sehe ist die starke Koppelung bzw. Verkettung einzelner Microservices aneinander. Da wird ein HTTP call über 10 Services geschickt und sobald irgendwas nicht klappt der 500er nach oben geworfen. Gut umgesetztes Async calls, retry, Queues, Events oder CQRS sieht man selten.
Ich bin nicht mit dir einverstanden, dass die "Technische Komplexität im Ops-Bereich" die weniger dramatische ist. Im Gegenteil - ich habe die Erfahrung gemacht, dass je mehr Teil-Komponenten zum Einsatz kommen umso komplexer wird das ganze "Bild" und in der Regel gibt oft selbst in laufenden Projekten kaum jemanden, der auf Anwendungsseite noch irgendwas überblickt geschweige denn die Gesamt-Architektur. Das Ergebnis ist dann oft ein Incident der "Meine Anwendung ist langsam" und dann ist die Kacke am Dampfen ... das Ops-Team muss dann herausfinden was derjenige eigentlich mit "meine Anwendung" meint. Eine Katastrophe ... Aufgrund der kleineren "in sich geschlossenen" Teil-Komponenten ist die Fluktuation im Dev-Team oft wesentlich größer als im Ops-Team. Manchmal kommt es dann zu solchen fragwürdigen Situationen, dass das Ops-Team sich dann irgendwann besser mit dem "Anwendung-Teilchen-Chaos" auskennt als der die Anwendungsentwicklung. Die ganze MS-Architektur funktioniert nur, wenn man auf beiden Seiten (Dev und Ops) gute und vor allem beständige Teams hat ... und komme jetzt bitte nicht mit Themen wie "ordentliche Übergabe" oder "Know-How-Transfer" ... 🙂
Vielen Dank für das Video! Firmen, die ein überschaubares Geschäftsmodell verfolgen, können vielleicht eine reine Microservice Strategie verfolgen. Komplexere Firmen mit einer Vielzahl an wirklich komplexen Geschäftsmodellen im Kontext einer Vielzahl von soziotechnischen Vernetzungen ist eine reine Microservice Strategie wohl kein Erfolgsgarant sondern eher das Gegenteil. Eine Microservicestrategie ist hier eher als ein Nischenansatz einzuordnen, zum Beispiel für Integrationsaufgaben. Zeiterfassung ist ein gutes Beispiel einer als Paket von Geschäftsfunktionen zu schaffenden Lösung. Insbesondere über den DDD-Ansatz ergeben sich gute Ansätze, Pakete von Geschäftsfunktionen zu bilden, die sich an den Fachobjekten orientieren. Ausgehend von einem Domainmodell basierten komplexen Schema müssen ggf. APIs weitgehend automatisiert bereitgestellt werden und können nicht über einzelne Microservices implementiert werden=> "datenbezogene vs. funktionale Brille". Komplexität liegt im Rahmen der Digitalisierung häufig in den Datenanforderungen, wo Digital Payload Persistence und Digital Core Persistence sauber auseinander gehalten werden sollten. Hier ist der Core üblicherweise weiterhin ein monolytisches System zu dem spezialisierte Sidecar Systeme betrieben werden, welche über APIs und über einen Enterprise User Experience Ansatz integriert werden und definierte Geschäftsfunktionen paketiert bereitstellen. Der Microservice Ansatz stellt aus meiner Sicht hier nur die dritte Stufe eines Implementationsmodells aus Unternehmenssicht dar, wo sich die Frage anschließt, ob diese dritte Stufe für das jeweilige Unternehmen überhaupt Sinn macht.
Vielen Dank für die wie immer sehr aufschlussreiche und kurzweilige Unterscheidung zwischen Hype-Themen und substanziellem, technologieunabhängigem Wissen! 😀 Ein Thema, das im Zusammenhang mit Microservices immer wieder aufkommt, ist eine möglichst resiliente und ausfallsichere Kommunikation zwischen Diensten. Also welche Kommunikations-Muster (Request/Response vs. Publish/Subscribe) passen zu meinem fachlichen Problem? Welche Transport-Technologien (HTTP/REST, MQTT, AMQP,...) passen wiederum zu dem präferierten Muster? Vielleicht ja was für weitere Videos…? 😀 Danke Euch und weiter so! 🙏
In der Abwägung zwischen Monolith und Microservice "tendenziell eher Microservices zu empfehlen" greift zu kurz. Beide Ansätze stehen für mich gleichberechtigt nebeneinander. Der organisatorische Aspekt kommt hier zu kurz: Wie groß sind die Teams? Wie sollen sie zukünftig aufgeteilt oder strukturiert werden (Stream aligned o.ä.). Zentrale Plattform-Team, in den zum Beispiel Infrastruktur-Themen gebündelt ist, sehe ich als validen Ansatz an und würde nicht sagen das zentrale (DevOps) Teams per-se nicht sinnvoll sind. Microservices sind nicht nur eine technische, sondern in einem großen Maß organisatorische Entscheidung. Ich vermute, dass etliche Projekte bei genauerer Betrachtung wohl besser einen Monolith implementiert hätten und so die technisch wie organisatorische Komplexität eines verteilten Systems vermieden hätten.
Ein riesen thema für mich ist die bedarfsgesteuerte skalierbarkeit von services. Das lässt sich mit microservices wesentlich präziser steuern. Das jedoch ordnungsgemäß zu implementieren, ist komplexe materie. verteiltes logging, monitoring, events, die in korrekter reihenfolge abgearbeitet werden müssen, ausfallerkennung und und und. ich habe bei mir derzeit lediglich eine anwendung, für welche dieser aufwand gerechtfertigt ist. Ansonsten wird jede Anwendung immer so geschrieben, dass sie im nachhinein auch zerschnitten werden kann in mehrere komponenten. es spricht meiner meinung jach nichts gegen einen monilithischen ansatz - solange dieser ordentlich implementiert ist und sich nicht wie eine verhedderte angelschnur verhält.
Einen Monolithen zu deployen findet in der Regel 4 oder 6 mal im Jahr statt. Vielleicht sogar 12 mal bei weniger Komplexität. Aber wer mal bei Banken/Versicherungen solche Monolithen betreut hat weiß was ich meine. Änderungen ziehen sich durchs gesamte System. Und nach dem Release Wochenende (!) sitzen die OPs Leute oft da und müssen die Probleme lösen die vorher niemand getestet hat, während der Großteil der Devs das Release feiern. Eine Aussage dazu die man mehrfach bei Vorträgen hört finde ich relevant. Und zwar das man von 4 oder 6 Deployments pro Jahr auf mehrere die Woche, teilweise sogar am Tag, umgestellt hat. Allein das führt meiner Ansicht nach zu einer viel höheren Qualität da man sehr schnell reagieren kann.
Ich habe mit Webentwicklung kaum etwas zu tun. Auch mit Microservices bin ich, bis auf das Konzept, noch nie in Berührung gekommen. Da ich fast ausschließlich im on-prem SAP Bereich entwickle ist das eher der alte Monolith. Klar gibt es auch Schnittstellen, diese werden aber im SAP eigenen PI (Middleware) orchestriert. Aus reinem Interesse verfolge ich hier manchmal die "Trends" aber wirklich damit zu tun habe ich (leider) nichts. Wobei ich sagen muss, dass mich pure Webentwicklung auch thematisch eher überfordert, so gibt es hier doch sehr schnelllebige Trends, Tools, Frameworks und so weiter. Die alte SAP Welt ist da doch etwas beständiger, wobei sich in Sachen Cloudtechnologie auch bei SAP einiges tut. Dennoch interessantes Video :)
SAP ist das schlimmste software verbrechen was jemals programmiert wurde. kenne keine vergleichbar sperrige software die seit dem jahr 2000 auf web 2.0 kleben geblieben ist. SAP ist in 20 jahren wie IBM. unrelevant.
@@boohoo5419 Totgesagte leben länger ;) Aber ich stimme dir natürlich zu was die Sperrigkeit angeht. SAP Standard-Code debuggen ist Spagetti-Code Fiesta und dazu kommt dann noch ein Haufen historisch gewachsener Customer Code bei den Kunden dazu, da kommt Freude auf :D
Mikroservices sind schön und gut. Ich find bei der Diskussion aber immer schwer, Mikroservices überhaupt einzusetzen, wenn man von der Fachabteilung die Anforderung bekommt, dass eine Anwendung offline-fähig sein muss. Dann muss man meistens eben doch noch andere Anwendungs-Architekturen parat haben.
Absolut, aber nicht anders verstehe ich auch die Einschätzung von Golo. Es kommt auf die Anforderungen an und wenn eine Offline-Fähigkeit notwendig ist, dann ist vermutlich ein anderer Architektur Ansatz besser.
Ich habe den überwiegenden Teil der Kommentare gelesen und kann oft zustimmen aber oft auch den Kopf schütteln. Ist es in Wirklichkeit nicht so, dass wir "einfach nur" sehr gute Modulschnitte und so wenig "das machen wir common, weil das braucht ja jeder" wie möglich im Design haben sollten? 😉 Meiner Erfahrung nach ist es mit diesem Pattern möglich zu einem späteren Zeitpunkten auch einzelne Module in Services zu extrahieren. In der Realität ist es meiner Meinung nach daher überwiegend sinnvoll auch nicht nur Monolith vs. Microservices zu betrachten sondern vor allem bei Greenfield Entwicklung und Ablöseprojekte auf isolierte Module zu setzen. Im Ergebnis sind das dann anfänglich wenige Monolithen die mit der Zeit und dem entsprechenden Bedarf (technisch oder fachlich) in Makroservices übergehen. Nur die wirklich Änderungsvolatilen oder anderweitig erforderlichen Module z.B. wegen Last / Requestmenge landen dadurch auch in wirklichen Microservices. Damit erhält man dann Benefits die einen viel größeren Einfluss auf die gesamte Organisation, Budget usw. haben. Denn seien wir mal ehrlich: Nur weil es nach DDD sinnvoll ist die Bounded-Contexts so zu schneiden heißt das nicht dass man es über Monolith oder Microservices machen kann. Bei Microservices würde man sich ansonsten in den ersten Monaten der Entwicklung 3, 4, 5 Microservices pro Team kümmern müssen nur weil jeder Microservice einen bestimmten Bounded-Kontext entspricht der in den nächsten Monaten und Jahren erst stark anwächst. Bei reinen Monolithen würde man hingegen schnell viel common / shared haben, weil es der einfachste und schnellst Weg ist. Der Trade-Off hier ist vor allem der Punkt der Vermeidung von technischen Schulden wie z.B. Framework-Updates oder Implementierungen die zwar alle aber zu unterschiedlichen Anteilen nutzen und die Teams in den Konflikt zwischen Handlungsunfähigkeit und technischer Schulden drückt. Gleichzeitig ist es meiner Erfahrung nach auch so, dass viele Microservices oft als banale CRUD Services designed werden oder enden, bei den sich die "Fragmentierung" weder in der Entwicklung noch im Betrieb rentiert.
Komme eher aus der monolithischen Ecke und steige erst nach und nach auf MicroServices um. Als Alleinkämpfer ist bei mir allerdings bei Docker / Docker Compose Schluss und eine Einarbeitung in Kubernetes aus zeitlichen und wirtschaftlichen Gründen nicht sinnvoll. Bleibe also lieber bei Dev und mache Ops nur soweit es notwendig ist. Ich wünsche eine angenehme und erfolgreiche Woche! P.S.: Wäre es möglich den Lautstärke-Pegel etwas höher einzustellen. Ihr seit der einzige Kanal wo ich extra die System-Laustärke erhöhen muss. Danke!
Microservice um trendy zu sein, finde ich auch schwierig. Es kommt wirklich auf den Case an. Es hat wie alles Vor und Nachteile.
2 года назад
Ich würde das gar nicht so hart trennen als entweder/oder. Mein Problem mit Microservices ist, wenn man zwanghaft versucht wird, Dinge kleinzuschneiden, die gar nicht kleinzuschneiden sind. Was spricht den gegen eine Architektur, die eine "große" Komponente hat, die man (fast) als Monolithen bezeichnen kann und rund herum viele kleine Microservices. Im Gegensatz zu SOA würde ich aber sagen, die Services drum herum müssen wirklich unabhängig sein und nicht durch die große Komponente orchestriert werden. Sondern sind wirklich komplett eigenständig mit eigener Datenhaltung wie erwähnt. Ich muss meines Erachtens nicht die fachliche Anforderung so klein haken, bis ich 100te Microservices habe, sondern in sinnvolle Einheiten. Und vielleicht kommen da auch einzelne Einheiten raus, die größer sind, als das was man im ersten Momentan beim Begriff Microservice denkt.
Erstmal ne banale Anmerkung. Die Anforderungen sind nicht in Stein gemeißelt. Oftmals kommt man mit dem Kunde ins Gespräch und findet raus, dass er eigentlich was viel einfacheres mit der Software machen will. Und dadurch kann man die Komplexität sehr gut eindämmen. (Der beste Code ist der, der nie geschrieben werden muss) Microservices lösen die Skalierungsprobleme von großen Internetfirmen, sowohl bzgl. der zu verarbeitenden Datenmenge als auch bzgl. der Orchestration der am Gesamtprodukt arbeitenden Entwickler. Wenn man keines der beiden Probleme hat, sollte man bitte die Finger von Microservices lassen. Die Zuständigkeitsgrenzen zwischen "Modulen" korrekt zu ziehen ist schon schwer genug, wenn man den Code im selben Repo hat. Wenn man das ganze auf getrennte Komponenten verteilt, die man ggf. für die nächsten Wochen nicht selber anpassen kann, weil ein anderes Team dafür zuständig ist, hat man ein verdammtes Problem. Das erfordert extrem gute Design-Skills, um das Problem so zu zerlegen, dass die Dienste wirklich entkoppelt sind und nicht irgendwelche Versionsabhängigkeiten bestehen. Mit nur ein bisschen Ops und Kubernetes ist es nicht getan. Also bitte nochmal, lasst die Finger weg von Microservices, wenn ihr keine Ahnung von Architektur habt und in Wahrheit keine Skalierung braucht. Einen verteilten Ball-of-Mud zu debuggen ist die Hölle. Tut euch bitte selber nen Gefallen.
@@valeridause Danke dass es dir gefallen hat. Ich wollts nur mal anmerken. Weil der Grund, wieso man eigentlich Microservices haben will und was für krasse Nachteile es gibt, ist hier nicht ganz so klar rausgekommen 😅 TDD / DDD, CI/CD, Agile Methoden usw. kann man auch prima in jeglichen Projekten einsetzen. Das mit den Microservices muss man sich gut überlegen.
hi, ich sag gerne das es von technischer seite fast egal ist welche technik man verwendet, sondern vom team. ich hab mal nem expert java developer von docker erzaehlt, aber er sagt, der kunde versteht dann nicht was am server passiert, er kennt java anwendungen, aber eben kein docker,... damals.
[gr] Ja, das war ein Planungsfehler … wir hatten das Video fälschlicherweise für 18 Uhr eingeplant, und haben das erst um 8 Uhr gemerkt - und dann war der nächstmögliche Zeitpunkt leider erst 8:15 Uhr. Daher heute die Verspätung. Beim nächsten Video wird's wieder 8 Uhr sein 😊
AWS, Azure & Google finden Microservices gut.
Damit machen die einfach mehr Umsatz / Gewinn.
Wenn ein einzelner Server / Monolith für viele Probleme eine gute Lösung ist, verursacht ein Cluster gerne das x-fache an Kosten.
Das wären der Network Overhead, zusätzliche administrative Services die man nur braucht weil man Microservices benutzt, höherer Aufwand für Dev-Ops. Und dann noch Service-Leichen die Kosten verursachen, weil schlicht der Überblick verloren gegangen ist.
Die FAANG Truppe wird sich hüten kosteneffiziente Lösungen zu promoten. Eigentlich alle gesponserten Developer Konferenzen auf RUclips loben Microservices.
Oder noch besser: Gerne auch auch eine AWS Lambda order Cloud Function die fürs Warten auf die Datenbank bezahlt wird. Der Cloud-Anbieter wird dann für schlechte DB Antwortzeiten auch noch belohnt :D
Zunächst mal vielen Dank für ein weiteres top Video. Euer Kanal macht einfach Spaß und ist hochinformativ! Man merkt, dass ihr aus der Praxis kommt.
Die Architektur muss in erster Linie das Geschäftsziel unterstützen und Komplexität verringern. Wenn ich ein recht stabiles Geschäftsmodell habe, was gut planbar ist und wenig unvorhergesehene Ereignisse aufweist, dann fahre ich mit einem gut strukturierten Monolithen aus meiner Erfahrung gar nicht schlecht, da ich viele nicht-funktionale bzw. nicht werttreibende Aktivitäten sehr elegant bündeln kann und es sich auch für den Endanwender wie aus einem Guss anfühlt. Das geht natürlich auch mit Microservices, aber bringt dann auch wieder wieder Komplexität rein, da ich dies ggfs. zentral steuern muss.
So oder so kann ich mich den Aussagen des Videos nur anschließen: Es kommt drauf an :)
Was mir als Tester auffällt, wo ich eine Microservice Architektur dahinter erkenne, ist wenn gleiche Funktion in einem Teil der Anwendung funktioniert, und in einem anderen Teil nicht, z.B. Aus dem Einkaufswagen Artikel auf die Wunschliste setzen geht, aus der Artikelartei selbst nicht. Man "zerreisst" die Anwenderfunktion an der technischen Grenze. Und das macht mir Sorgen.
Mittlerweile kann fast hinter jeder UI komponente ein microservice liegen der diese mit daten beliefert. Das Testen jeden einzelnen Services wird zwar einfacher, aber man testet weniger im Verbund, weil es für den Verbund nun niemanden mehr gibt der sich ausreichend drum kümmert. Alle sind ja jetzt in Microservice Teams. Man kann richtig Inverse Conway's Law beobachten.
Naja, es gibt noch einen weiteren Nachteil bei Microservices:
Man hat nen Payload: Ich habe mal für so mit dem grössten Online-Klamotten-Shop Deutschlands gearbeitet und da war immer die Anforderung: Ein API Request darf nicht länger als 500ms dauern. Wenn sich aber der API Request anhand von 3 Microservice Requests bediente, gingen da mal schnell 200ms von drauf wegen Netzwerktraffic und eben auch der Microservice Payload selber (Framework bootstrappen, Security / IP Check, db Connection starten, ...). Weshalb wir da dann auch teilweise zu übergegangen sind, diese Microservices nicht zu nutzen, sondern unser eigenes Ding zu schreiben, damit wir die 500ms einhalten konnten.
Und das ist halt son typisches Beispiel von "in einer heilen Welt als Idee super" vs "Realität".
Danke für das Video.
Meine Anmerkungen zu Mikroservices..
Aha, im Leben ist es überall anzuwenden (#ironie). Wir können Reifen von einem Flugzeug an unsere PKWs wechseln, wenn dort Neue erschienen sind. Wir können Gamer-Sitze auch im Bus für die alten Menschen verwenden. Sobald ein neues Modell erschienen ist, können wir den Motor von dem Hubschrauber auch sofort in dem Küchen-Mixer integrieren. Es sind Millionen von Möglichkeiten, die abstrakt-artig-gesehen durch Mikroservices "abgedeckt" werden, jedoch die Welt funktioniert doch anders.
Egal, wie klein oder groß man "schneidet" - es kann immer passieren, dass zwar Modulare-Aufbau stattfindet, jedoch kein selbstverständlicher Austausch der einzelnen Komponente durch andere möglich wird, sondern nur die von dem gleichen Typ. Daher ist dieser Hype um Mikroservice genauso schlecht für die Qualität gewesen wie pures Agil, der überall propagiert wird. Denn beide suggerieren, dass man die "alten" Methoden wegschmeißen kann, doch mit sich bringen sie nichts außer Demagogie. Hier sind nur zwei/drei Beispiele
- Das Projektmanagement leidet gewaltig, denn eine gute und Termin-treue Planung nicht möglich sei - nur Gerede drum herum
- Wenn ein großes Projekt erst eine stabile Architektur benötigt, diese aber angeblich in iterativen Schritten gebaut werden will - das Fundament wird instabil
- Wenn eine banale Datei-Speicherung doch nicht durch S3 Buckets ersetzt werden will
- Wenn der Ersatz einer CSV-Datei durch einer JSON-Datei bevorzugt wird, egal ob die CSV-Datei bereits 3GB groß ist und der Importer diese kaum "verdauen" kann.
- Wenn das gesamte BigData auf Dezentralität setzt, doch für die Realisierung von Data Lake alle Daten angeblich zentral gespeichert werden sollen.
Viele von diesen "Trend"-Erscheinungen pure-artig verschlechtern das Gesamtbild und bringen eine bestimmte Kultur der "Alles Egal" - Mentalität. Gesagt wird was anderes, jedoch erleben wir genau das Gegenteil von dem, was propagiert wird. Und das finde ich bedauerlich für die Szene, denn es entstehen Tonnen von schlechtem und nicht langlebendem Code, Architektur usw. Alle diese Themen wie Mikroservices und Agilität sollten als Ergänzungen verstanden werden, jedoch wer macht das schon...
Viel zu wenig Abos. Der Inhalt ist echt gut.
Es liegt daran, dass Golo mehr zu Go, TypeScript, Docker und JS was erzählt und sehr wenig wie in diesem Video für allgemeine Themen.
Auch, wenn mich die og. Themen gar nicht angehen - bin ich trotzdem hier. Denn.
Die Art, wie er die Themen erzählt, finde ich einmalig - sehr authentisch, freundlich, wortbegabt, nicht herablassend - wie ein kluger Kumpel, dem man gerne zuhört.
Aber eben - er geht sehr eng spezifische Themen an (aus meiner Sicht). Er sollte mehr aufgreifen - Software Engineering, Projektmanagement, Daten-Modellierung und und und - die Welt wartet nur auf solche Beiträge 🙂 - und dann wird auch die Community größer.
Eigentlich überspringe ich bei Texten und Videos immer die Einleitung. Aber ich muss sagen, dass die Einleitung in diesem Video extrem gut strukturiert worden ist und Interesse für das Thema erweckt. RIchtig gutes Video :)
[gr] Das freut mich, vielen Dank 😊
Ein Problem was ich häufig sehe ist die starke Koppelung bzw. Verkettung einzelner Microservices aneinander. Da wird ein HTTP call über 10 Services geschickt und sobald irgendwas nicht klappt der 500er nach oben geworfen. Gut umgesetztes Async calls, retry, Queues, Events oder CQRS sieht man selten.
Ich bin nicht mit dir einverstanden, dass die "Technische Komplexität im Ops-Bereich" die weniger dramatische ist. Im Gegenteil - ich habe die Erfahrung gemacht, dass je mehr Teil-Komponenten zum Einsatz kommen umso komplexer wird das ganze "Bild" und in der Regel gibt oft selbst in laufenden Projekten kaum jemanden, der auf Anwendungsseite noch irgendwas überblickt geschweige denn die Gesamt-Architektur.
Das Ergebnis ist dann oft ein Incident der "Meine Anwendung ist langsam" und dann ist die Kacke am Dampfen ... das Ops-Team muss dann herausfinden was derjenige eigentlich mit "meine Anwendung" meint. Eine Katastrophe ...
Aufgrund der kleineren "in sich geschlossenen" Teil-Komponenten ist die Fluktuation im Dev-Team oft wesentlich größer als im Ops-Team. Manchmal kommt es dann zu solchen fragwürdigen Situationen, dass das Ops-Team sich dann irgendwann besser mit dem "Anwendung-Teilchen-Chaos" auskennt als der die Anwendungsentwicklung.
Die ganze MS-Architektur funktioniert nur, wenn man auf beiden Seiten (Dev und Ops) gute und vor allem beständige Teams hat ... und komme jetzt bitte nicht mit Themen wie "ordentliche Übergabe" oder "Know-How-Transfer" ... 🙂
Vielen Dank für das Video! Firmen, die ein überschaubares Geschäftsmodell verfolgen, können vielleicht eine reine Microservice Strategie verfolgen. Komplexere Firmen mit einer Vielzahl an wirklich komplexen Geschäftsmodellen im Kontext einer Vielzahl von soziotechnischen Vernetzungen ist eine reine Microservice Strategie wohl kein Erfolgsgarant sondern eher das Gegenteil. Eine Microservicestrategie ist hier eher als ein Nischenansatz einzuordnen, zum Beispiel für Integrationsaufgaben. Zeiterfassung ist ein gutes Beispiel einer als Paket von Geschäftsfunktionen zu schaffenden Lösung. Insbesondere über den DDD-Ansatz ergeben sich gute Ansätze, Pakete von Geschäftsfunktionen zu bilden, die sich an den Fachobjekten orientieren. Ausgehend von einem Domainmodell basierten komplexen Schema müssen ggf. APIs weitgehend automatisiert bereitgestellt werden und können nicht über einzelne Microservices implementiert werden=> "datenbezogene vs. funktionale Brille". Komplexität liegt im Rahmen der Digitalisierung häufig in den Datenanforderungen, wo Digital Payload Persistence und Digital Core Persistence sauber auseinander gehalten werden sollten. Hier ist der Core üblicherweise weiterhin ein monolytisches System zu dem spezialisierte Sidecar Systeme betrieben werden, welche über APIs und über einen Enterprise User Experience Ansatz integriert werden und definierte Geschäftsfunktionen paketiert bereitstellen. Der Microservice Ansatz stellt aus meiner Sicht hier nur die dritte Stufe eines Implementationsmodells aus Unternehmenssicht dar, wo sich die Frage anschließt, ob diese dritte Stufe für das jeweilige Unternehmen überhaupt Sinn macht.
Vielen Dank für die wie immer sehr aufschlussreiche und kurzweilige Unterscheidung zwischen Hype-Themen und substanziellem, technologieunabhängigem Wissen! 😀
Ein Thema, das im Zusammenhang mit Microservices immer wieder aufkommt, ist eine möglichst resiliente und ausfallsichere Kommunikation zwischen Diensten. Also welche Kommunikations-Muster (Request/Response vs. Publish/Subscribe) passen zu meinem fachlichen Problem? Welche Transport-Technologien (HTTP/REST, MQTT, AMQP,...) passen wiederum zu dem präferierten Muster?
Vielleicht ja was für weitere Videos…? 😀
Danke Euch und weiter so! 🙏
In der Abwägung zwischen Monolith und Microservice "tendenziell eher Microservices zu empfehlen" greift zu kurz. Beide Ansätze stehen für mich gleichberechtigt nebeneinander.
Der organisatorische Aspekt kommt hier zu kurz: Wie groß sind die Teams? Wie sollen sie zukünftig aufgeteilt oder strukturiert werden (Stream aligned o.ä.). Zentrale Plattform-Team, in den zum Beispiel Infrastruktur-Themen gebündelt ist, sehe ich als validen Ansatz an und würde nicht sagen das zentrale (DevOps) Teams per-se nicht sinnvoll sind. Microservices sind nicht nur eine technische, sondern in einem großen Maß organisatorische Entscheidung.
Ich vermute, dass etliche Projekte bei genauerer Betrachtung wohl besser einen Monolith implementiert hätten und so die technisch wie organisatorische Komplexität eines verteilten Systems vermieden hätten.
Ein riesen thema für mich ist die bedarfsgesteuerte skalierbarkeit von services. Das lässt sich mit microservices wesentlich präziser steuern. Das jedoch ordnungsgemäß zu implementieren, ist komplexe materie. verteiltes logging, monitoring, events, die in korrekter reihenfolge abgearbeitet werden müssen, ausfallerkennung und und und. ich habe bei mir derzeit lediglich eine anwendung, für welche dieser aufwand gerechtfertigt ist.
Ansonsten wird jede Anwendung immer so geschrieben, dass sie im nachhinein auch zerschnitten werden kann in mehrere komponenten. es spricht meiner meinung jach nichts gegen einen monilithischen ansatz - solange dieser ordentlich implementiert ist und sich nicht wie eine verhedderte angelschnur verhält.
Sehr schöne Erklärung des Themas!
Einen Monolithen zu deployen findet in der Regel 4 oder 6 mal im Jahr statt. Vielleicht sogar 12 mal bei weniger Komplexität. Aber wer mal bei Banken/Versicherungen solche Monolithen betreut hat weiß was ich meine. Änderungen ziehen sich durchs gesamte System. Und nach dem Release Wochenende (!) sitzen die OPs Leute oft da und müssen die Probleme lösen die vorher niemand getestet hat, während der Großteil der Devs das Release feiern. Eine Aussage dazu die man mehrfach bei Vorträgen hört finde ich relevant. Und zwar das man von 4 oder 6 Deployments pro Jahr auf mehrere die Woche, teilweise sogar am Tag, umgestellt hat. Allein das führt meiner Ansicht nach zu einer viel höheren Qualität da man sehr schnell reagieren kann.
Ich habe mit Webentwicklung kaum etwas zu tun. Auch mit Microservices bin ich, bis auf das Konzept, noch nie in Berührung gekommen. Da ich fast ausschließlich im on-prem SAP Bereich entwickle ist das eher der alte Monolith. Klar gibt es auch Schnittstellen, diese werden aber im SAP eigenen PI (Middleware) orchestriert.
Aus reinem Interesse verfolge ich hier manchmal die "Trends" aber wirklich damit zu tun habe ich (leider) nichts. Wobei ich sagen muss, dass mich pure Webentwicklung auch thematisch eher überfordert, so gibt es hier doch sehr schnelllebige Trends, Tools, Frameworks und so weiter.
Die alte SAP Welt ist da doch etwas beständiger, wobei sich in Sachen Cloudtechnologie auch bei SAP einiges tut.
Dennoch interessantes Video :)
SAP ist das schlimmste software verbrechen was jemals programmiert wurde. kenne keine vergleichbar sperrige software die seit dem jahr 2000 auf web 2.0 kleben geblieben ist. SAP ist in 20 jahren wie IBM. unrelevant.
@@boohoo5419 Totgesagte leben länger ;) Aber ich stimme dir natürlich zu was die Sperrigkeit angeht. SAP Standard-Code debuggen ist Spagetti-Code Fiesta und dazu kommt dann noch ein Haufen historisch gewachsener Customer Code bei den Kunden dazu, da kommt Freude auf :D
Golo... MEGA! 👍😎
Wenn man DevOps Teams nicht separat haben sollte. Was wäre dann mit Plattform Teams?
Mikroservices sind schön und gut. Ich find bei der Diskussion aber immer schwer, Mikroservices überhaupt einzusetzen, wenn man von der Fachabteilung die Anforderung bekommt, dass eine Anwendung offline-fähig sein muss. Dann muss man meistens eben doch noch andere Anwendungs-Architekturen parat haben.
Absolut, aber nicht anders verstehe ich auch die Einschätzung von Golo. Es kommt auf die Anforderungen an und wenn eine Offline-Fähigkeit notwendig ist, dann ist vermutlich ein anderer Architektur Ansatz besser.
Ich habe den überwiegenden Teil der Kommentare gelesen und kann oft zustimmen aber oft auch den Kopf schütteln.
Ist es in Wirklichkeit nicht so, dass wir "einfach nur" sehr gute Modulschnitte und so wenig "das machen wir common, weil das braucht ja jeder" wie möglich im Design haben sollten? 😉
Meiner Erfahrung nach ist es mit diesem Pattern möglich zu einem späteren Zeitpunkten auch einzelne Module in Services zu extrahieren. In der Realität ist es meiner Meinung nach daher überwiegend sinnvoll auch nicht nur Monolith vs. Microservices zu betrachten sondern vor allem bei Greenfield Entwicklung und Ablöseprojekte auf isolierte Module zu setzen.
Im Ergebnis sind das dann anfänglich wenige Monolithen die mit der Zeit und dem entsprechenden Bedarf (technisch oder fachlich) in Makroservices übergehen. Nur die wirklich Änderungsvolatilen oder anderweitig erforderlichen Module z.B. wegen Last / Requestmenge landen dadurch auch in wirklichen Microservices.
Damit erhält man dann Benefits die einen viel größeren Einfluss auf die gesamte Organisation, Budget usw. haben.
Denn seien wir mal ehrlich: Nur weil es nach DDD sinnvoll ist die Bounded-Contexts so zu schneiden heißt das nicht dass man es über Monolith oder Microservices machen kann.
Bei Microservices würde man sich ansonsten in den ersten Monaten der Entwicklung 3, 4, 5 Microservices pro Team kümmern müssen nur weil jeder Microservice einen bestimmten Bounded-Kontext entspricht der in den nächsten Monaten und Jahren erst stark anwächst. Bei reinen Monolithen würde man hingegen schnell viel common / shared haben, weil es der einfachste und schnellst Weg ist.
Der Trade-Off hier ist vor allem der Punkt der Vermeidung von technischen Schulden wie z.B. Framework-Updates oder Implementierungen die zwar alle aber zu unterschiedlichen Anteilen nutzen und die Teams in den Konflikt zwischen Handlungsunfähigkeit und technischer Schulden drückt.
Gleichzeitig ist es meiner Erfahrung nach auch so, dass viele Microservices oft als banale CRUD Services designed werden oder enden, bei den sich die "Fragmentierung" weder in der Entwicklung noch im Betrieb rentiert.
Komme eher aus der monolithischen Ecke und steige erst nach und nach auf MicroServices um. Als Alleinkämpfer ist bei mir allerdings bei Docker / Docker Compose Schluss und eine Einarbeitung in Kubernetes aus zeitlichen und wirtschaftlichen Gründen nicht sinnvoll. Bleibe also lieber bei Dev und mache Ops nur soweit es notwendig ist.
Ich wünsche eine angenehme und erfolgreiche Woche!
P.S.: Wäre es möglich den Lautstärke-Pegel etwas höher einzustellen. Ihr seit der einzige Kanal wo ich extra die System-Laustärke erhöhen muss. Danke!
Ohne das gesehen zu haben, sage ich auf der einen Seite ja und auf der anderen nein. Es kommt auf den Usecase an und wie man das benutzt.
Microservice um trendy zu sein, finde ich auch schwierig. Es kommt wirklich auf den Case an. Es hat wie alles Vor und Nachteile.
Ich würde das gar nicht so hart trennen als entweder/oder. Mein Problem mit Microservices ist, wenn man zwanghaft versucht wird, Dinge kleinzuschneiden, die gar nicht kleinzuschneiden sind. Was spricht den gegen eine Architektur, die eine "große" Komponente hat, die man (fast) als Monolithen bezeichnen kann und rund herum viele kleine Microservices. Im Gegensatz zu SOA würde ich aber sagen, die Services drum herum müssen wirklich unabhängig sein und nicht durch die große Komponente orchestriert werden. Sondern sind wirklich komplett eigenständig mit eigener Datenhaltung wie erwähnt.
Ich muss meines Erachtens nicht die fachliche Anforderung so klein haken, bis ich 100te Microservices habe, sondern in sinnvolle Einheiten. Und vielleicht kommen da auch einzelne Einheiten raus, die größer sind, als das was man im ersten Momentan beim Begriff Microservice denkt.
Erstmal ne banale Anmerkung. Die Anforderungen sind nicht in Stein gemeißelt. Oftmals kommt man mit dem Kunde ins Gespräch und findet raus, dass er eigentlich was viel einfacheres mit der Software machen will. Und dadurch kann man die Komplexität sehr gut eindämmen. (Der beste Code ist der, der nie geschrieben werden muss)
Microservices lösen die Skalierungsprobleme von großen Internetfirmen, sowohl bzgl. der zu verarbeitenden Datenmenge als auch bzgl. der Orchestration der am Gesamtprodukt arbeitenden Entwickler. Wenn man keines der beiden Probleme hat, sollte man bitte die Finger von Microservices lassen.
Die Zuständigkeitsgrenzen zwischen "Modulen" korrekt zu ziehen ist schon schwer genug, wenn man den Code im selben Repo hat. Wenn man das ganze auf getrennte Komponenten verteilt, die man ggf. für die nächsten Wochen nicht selber anpassen kann, weil ein anderes Team dafür zuständig ist, hat man ein verdammtes Problem. Das erfordert extrem gute Design-Skills, um das Problem so zu zerlegen, dass die Dienste wirklich entkoppelt sind und nicht irgendwelche Versionsabhängigkeiten bestehen. Mit nur ein bisschen Ops und Kubernetes ist es nicht getan.
Also bitte nochmal, lasst die Finger weg von Microservices, wenn ihr keine Ahnung von Architektur habt und in Wahrheit keine Skalierung braucht. Einen verteilten Ball-of-Mud zu debuggen ist die Hölle. Tut euch bitte selber nen Gefallen.
Also ich finde dein Plädoyer so passend, dass es im Video zum Ende eigentlich erscheinen sollte.
@@valeridause Danke dass es dir gefallen hat. Ich wollts nur mal anmerken. Weil der Grund, wieso man eigentlich Microservices haben will und was für krasse Nachteile es gibt, ist hier nicht ganz so klar rausgekommen 😅
TDD / DDD, CI/CD, Agile Methoden usw. kann man auch prima in jeglichen Projekten einsetzen. Das mit den Microservices muss man sich gut überlegen.
hi, ich sag gerne das es von technischer seite fast egal ist welche technik man verwendet, sondern vom team. ich hab mal nem expert java developer von docker erzaehlt, aber er sagt, der kunde versteht dann nicht was am server passiert, er kennt java anwendungen, aber eben kein docker,... damals.
8:15 Uhr.. ?
[gr] Ja, das war ein Planungsfehler … wir hatten das Video fälschlicherweise für 18 Uhr eingeplant, und haben das erst um 8 Uhr gemerkt - und dann war der nächstmögliche Zeitpunkt leider erst 8:15 Uhr. Daher heute die Verspätung.
Beim nächsten Video wird's wieder 8 Uhr sein 😊