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/Zwoelf-Regeln-fuer-die-perfekte-Micro-Services-Architektur-9792599.html
Ich habe gelernt, wenn du überlegst mit Microservices zu starten, dann überlege dir zweimal gut ob du das wirklich willst. In den meisten Fällen willst du keine Microservices umsetzen. Ich bin mittlerweile eher bei sowas wie einem Modular Monolithen für komplexere Systeme und erst wenn es zwingend notwendig ist würde ich die einzelnen Module in eigene Services auslagern. Microservices bringen einfach so viel Komplexität mit wie SAGA Pattern, Verteilte Transaktionen, Outbox Pattern usw. Module lassen sich einfacher schneiden und wenn man einmal etwas falsch eingeschätzt und die Module zu groß oder zu klein geschnitten hat ist das einfacher zu.korrigieren als in einer verteilten Architektur. Meine Devise: Starte einfach und wenn du wirklich Microservices brauchst dann wird sich das von alleine zeigen und sich richtig anfühlen. Wenn man von vornherein eine Microservices Architektur umsetzt endet das meist im Chaos.
Vorallem führen Microservices zu endloser De- und Re- Serialisierung von Daten. Inklusive der "unzuverlässigkeit des Netzwerks". Selbst wenn es nur iptables innerhalb eines Kubernetes Hosts sind, ist es was anderes als in einem Prozess eine Speicheradresse zu schreiben und diese als gegeben zu betrachten. Die Grundregel: Wenn du mehr Microservices als User hast, wird es grauenvoll.
Das kann ich unbedingt auch so empfehlen. Niemals mit Microservices anfangen. Ich bin auch kein Freund davon gleich serverless mit functions loszulegen (obwohl ich dafür eher zu haben bin als für Microservices from start...). Unsere Erfahrung mit uServices ist richtig übel ausgegangen: Wir haben da jetzt in einem großen Projekt einen verteilten Monolithen. In einem kleineren Projekt sind wir auf den Modulithen umgestiegen, da das Refactoring dort noch gut möglich war. Der verteilte Monolith ist zwar in einem monorepo, aber was auch immer du da anfasst, viel Spaß beim Test 😕 Eigentlich wissen wir da gar nicht mehr genau was abgeht. Klar, hier sind Fehlentscheidungen getroffen worden von Anfang an, aber eben genau weil der Trend damals Microservices waren und man dachte das sei so toll. Der Modulith dagegen wird immer besser, weil wir nun explizit die Abhängigkeiten testen und sehen können und dadurch viel besser in den Griff bekommen. Da wir mit Spring arbeiten, war das alles kein Problem mit Spring Modulith - ein Segen für uns. Anders formuliert: Bitte nicht denken jeder muss Netflix-like die uServices Keule auspacken und Skalierbarkeit sei das Allheilmittel oder immer Quali Kriterium Nummer 1. Wartbarkeit, decoupling und cohesion sind häufig viel wichtiger. IMHO Für Microservices (und jeder in seinem eigenen repo) gibt es natürlich Szenarien, aber die sind schon sehr speziell und ergeben sich aus dem Business Case, der Organisation, der Teamstruktur, dem Design und einer entsprechenden Architekturgrundlage.
@@pinguincoder ist das so, ich mein, man sollte doch davor schon wissen, wie es geschnitten ist. Die Frage ist, ob es separate Builds sein müssen. Das Problem ist, wenn man es am Anfang nicht richtig plant wie es aufgeteilt werden muss, dann wird es umso schwieriger. Also nicht jetzt komplett alles planen, aber zumindest sollte das fachliche zumindest bekannt sein.
@@qui-gonkenobi4574 Du schaffst es meist nie die Services von Anfang an perfekt zu schneiden und wenn du sie aber bereits aufgeteilt hast ist es schwieriger etwas daran zu ändern. Ich kenne eigentlich keine Projekte aus meiner Vergangenheit die als Microservices gestartet sind und nicht im Chaos geendet sind. Daher meine Einschätzung
Ja, wie schon in anderen Kommentaren erwähnt: Video erweckt bei mir den Eindruck als ob du einem Kleinkind erklärst, wie man eine AK-47 richtig pflegt und einsetzt. Die Tipps sind alle gut, kann da voll zustimmen (danke für die CORS Erwähnung). ABER: Wichtigster und erster Tipp sollte sein: "Mach keine Microservices!" (in 98% der Fälle) ... ausser du hast triftige Gründe / Umfeld stimmt (Projekt ist zu gross für ein Team + bist Senior-Dev; hast das schon mal gemacht; oder hast sonst Experten-Rat + unabhängiger Lifecycle ist zwingend + ...).
Finde auch, dass man unbedingt erwähnen muss, wann Microservices überhaupt Sinn machen. Die meisten Teams und Produkte haben keine Skalierungsprobleme. Und der Tipp mit mehreren Repos ist zudem ziemlich kontraproduktiv, weil man die APIs der Dienste nie auf Anhieb richtig hinbekommt und sich die Option, Logik zwischen den Diensten zu schieben, nicht grundlos verbauen sollte. Und außerdem wurde das Wichtigste vergessen, dass die Dienste unabhängig voneinander releasebar sein müssen und deswegen mit sämtlichen Versionen der anderen Dienste funktionieren müssen.
Sehr gutes Video! Ich würde beim Design von Microservices noch darauf achten, Services so zu schneiden, dass verteilte Transaktionen möglichst unnötig sind. Two-Phase-Commit ist in den meisten Fällen sinnfrei und Sagas, egal ob orchestriert oder choreographiert, sind anspruchsvoll in der Umsetzung. Idealerweise am fachlichen Workflow orientieren und dort saubere Transaktionsgrenzen festlegen - das ist neben DDD Bounded Contexts sehr guter Input für das Schneiden von verschiedenen Services.
Sehr gut erklärt. Ist aber nur die halbe Miete. Man muss zusätzlich verstehen, in welchem Kontext Microservices überhaupt Sinn ergeben. Man hat nämlich nix gewonnen, wenn die Microservices voneinander anhängen, weil nur bestimmte Versionen miteinander funktionieren, usw. Das Microservices Design soll großen Firmen dabei helfen, dass hunderte Entwickler am selben Backend arbeiten können, ohne sich in die Quere zu kommen. Hinter jedem Service soll ein kleines Team stehen, das an seinem Dienst entwickelt. Wenn man eh nur wenige Entwickler hat, ist es daher nicht wirklich sinnvoll, Microservices zu entwickeln. Außerdem fehlt noch der Aspekt von Continuous Delivery, dass die Pipeline durch ausgiebige Tests definitiv feststellt, ob der Stand releasebar ist. Wenn die Pipeline durch läuft, sollte die Qualität gut genug sein, dass man den Stand ohne Bedenken in Production freigeben kann. Ich persönlich mags übrigens lieber, wenn der Code in einem großen Repo ist. Dann kann man auch ein Docker-Compose erstellen, um die Dienste zusammen zu starten. Und außerdem kann man in Git abbilden, wenn eine Änderung mehrere Dienste gleichzeitig betrifft. Ich würde daher eher einen Ordner pro Microservice in einem großen Git Repo anlegen. Und Branching ist auch schlecht. Unfertige Änderungen sollten sofort in origin/main, aber mit einer Feature Flag deaktiviert. Sonst kann man nicht Continuous Integration praktizieren, was per Definition verlangt, dass die Änderungen aller Entwickler mindestens 1 Mal pro Tag gemerged werden. Die Philosophie hinter Microservices ist eigentlich das, was sie so erfolgreich macht.
Před měsícem
Ich unterstütze den Gedanken von monorepos. So kann auch code zwischen micro services geteilt wird wie beispielsweise datenmodelle etc. Via library Einziger Nachteil man kann nicht so einfach automatisch die services versionieren.
Vielen Dank für dieses Video. Ich finde das einen sehr guten Vorschlag. Beeindruckend ist auch die technische sehr gute Diskussion zu Überlegung, wann man Microservices entwickeln sollte und wann nicht.
an sich gute tipps und gutes video :) ich find es wichtig, dass du am ende gesagt hast, dass nicht alles immer überall perfekt zutrifft. manchmal kann man nicht nur einen einzigen "main"-branch haben, weil man mehrere versionen gleichzeitig supporten muss und unter gewissen umständen halte ich konfigurations-dateien auch für praktikabler als umgebungsvariablen. (z.b. wenn es sehr viele konfigurationsmöglichkeiten gibt) aber wenn man auf einer grünen wiese anfängt, einen neuen service zu entwickeln, dann finde ich deine tipps als leitfaden echt gut :)
Deine Umgebungsvariablen sind in einer Configmap verschlüsselt persistiert (Configmaps gibt es z.B. unter Kubernetes) und werden im Git mit IaC versioniert. Mit Umgebungsvariable war nicht gemeint, dass du dich über SSH auf deinen Server verbindest und deine Variablen manuell in die Konsole eintippst, das ist voll 2013.
Ich begann als Steinzeitprogrammierer und entwickelte damals schon im Microservicesstil. Das war durch Adressbeschränkungen zwingend, wollte man viel erreichen. Insofern gelten die genannten Prinzipien schon immer.
Ich arbeite immer allein, da könnte man den Weg zur perfekten (Micro-)Service-Architektur sicher relativ schnell durchziehen wenn man denn will. In einem größeren Team wird so eine Umstellung aber wohl sehr aufwendig werden. Die Log Dateien könnte man übrigens in ein Volume schreiben, dann sind sie später auch nicht weg. Und ob dynamische Subdomains für DEV Versionen notwendig ist im Einzelfall zu hinterfragen. Schöne Woche!
Ein paar Dinge sind hier doch mit Vorsicht zu genießen. Ich würde eher davon abraten für jeden Service in ein eigenes Git-Repo anzulegen. Die Unabhängigkeit der Services sollte sich über eine gute DDD Struktur umsetzen können. Gleichzeitig würde ich eher davon abraten zu schnell den Weg in Richtung einer Microservice Architektur zu gehen. Viel mehr ist es besser mit einem modularen Monolithen anzufangen, bis die Fachlichkeit gut genug verstanden ist. Ansonsten holt man sich schon früh eine höhere Komplexität in das Projekt, was die Entwicklung und eben Refactorings erschwert. Durch einen falschen Service-Schnitt am Anfang eines Projektes schafft man sich schon viel früher eine schwerere Wartbarkeit. Außerdem fehlt mir ein wenig ein größeres Verständis für die Zuständigkeit von Services, z.B. warum man sie anhand der Fachlichkeit schneiden sollte und nicht am Arbeitsgegenstand. Weiter kann man dann noch erwähnen, wie und warum man Anti-Corruption-Layer an den Schnittstellen einbauen sollte.
Ich weiß nicht, ob es nicht sogar je nach Anwendungsfall durchaus sinnvoll sein kann, mit gRPC/Protobuf zu starten, insbesondere wenn man ein Datenmodell zwischen mehreren Services teilen möchte, die in verschiedenen Sprachen implementiert sind, ohne dabei auf Typsicherheit zu verzichten. Dieses allgegenwärtige HTTP+JSON+JSON-Schema mit irgendeiner ad hoc runtime Validierung anstelle von einem ordentlichen typsicheren Modell bereitet mir genau dieselben Bauchschmerzen wie früher Python mit dem dynamischen Typsystem. Klar, es ist einfach, es geht schnell, aber so richtig geil finde ich es insbesondere mit statisch typisierten Sprachen, die keine runtime reflection haben, eigentlich nicht.
Ich verstehe Deinen Punkt, sehe aber bei HTTP als erstem Protokoll einen ganz anderen Vorteil gegenüber gRPC oder auch GraphQL: Ich brauche keinen speziellen Client, der mir erst noch generiert werden muss. Sondern ich kann einfach mit curl anfangen, die API aufzurufen. Alles ist menschenlesbar, was es einfach zu debuggen macht. Und gerade, wenn man noch nicht so richtig weiß, wo man genau hinwill, finde ich gerade das Leichtgewichtige an HTTP viel praktischer als die Typsicherheit der anderen Technologien. Langfristig bin ich bei Dir, aber deshalb gilt bei uns die Regel, zunächst mit HTTP anzufangen, und dann bei Bedarf gRPC & Co. einzuführen. Aber wie ja auch schon im Video gesagt: YMMV
Danke für das kompakte Video! Die paar Minuten hat sicher jeder übrig, der aktuell quasi mini-VMs mit supervisord (startet dann nginx, fpm, crond, queue-consumer ...) baut und diese dann als microservice bezeichnet. Habt ihr Tipps zu Punkt 8a, womit ich service-to-service Kommunikation meine. Ich bin mir nie ganz sicher, ob man da mit klassischen east-west balancern oder doch eher mit round-robin mittels (DNS-based) service-discovery oder gar Richtung service-mesh (mit mTLS dann) gehen sollte.
Ein neues Docker Image pro Commit ist ja schön und gut. Aber realistisch gesehen muss ja irgendwann auch mal ein Cleanup stattfinden, weil man ja nicht beliebig viel Storage dafür hat.
@@alex0kai Ich meinte es eher so, dass man nicht beliebig lange ohne Cleanup auskommt. Das Cleanup wird in der Planung gerne vergessen und man hat dann am Ende ein Docker Image zu jedem Commit der letzten 5 Jahre rumliegen.
Für den main-Branch macht das IMHO schon Sinn, da dort ja auch jeder Commit einer neuen Version entspricht. Die Images von den PRs kannst Du natürlich alle löschen, sobald ein PR gemerged oder geschlossen wird. Dann hält sich auch die Anzahl der Images in Grenzen. (Dass man daran natürlich denken muss bzw dafür etwas tun muss, versteht sich von selbst.)
Gott sei Dank bin ich "Steinzeitprogrammierer" und brauche kein Docker, Microservices und anderen neumodischen Kram. Würde auch unter FreeDOS nicht laufen.
@@alexandershendi7428 docker ist super praktisch du kannst dir eine komplette Datenbank mit ein paar Zeilen Code in einer Docker Composer hochziehen :D
Das ist genauso richtig/falsch wenn einer immer das neueste einsetzt. Einsatz der Technologie sollte eher bestimmt werden, was das für eine Anforderung ist und nicht weil es alt oder neu ist.
Wir haben noch einige COBOL Programmierer bei uns. Die sagten mir mal, alles was die wissen müssen steht in einem Buch. Versionskontrolle? Unit Tests? Was für ein neumodischer Kram, alles unnötig. Da hackt man noch seinen Code selbst auf die Ausführungsumgebung und dann läuft es halt oder nicht. Wer damit glücklich ist, bitte. Aber ob das besser ist wage ich mal zu bezweifeln.
Monorepos sind IMHO deutlich überbewertet und bringen ihre ganz eigenen Probleme und Nachteile mit sich … am Ende des Tages gilt aber letztlich: Der Ansatz, den man wählt, muss zum Problem und der Umgebung passen. Das habe ich ja auch im Video schon gesagt: YMMV Für *uns* haben sich Monorepos im Lauf der Jahre als eher schlechte Idee erwiesen, weshalb wir es heute so machen wie im Video beschrieben. Das heißt aber natürlich nicht, dass das für jede und jeden anderen auch die richtige Lösung sein muss.
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/Zwoelf-Regeln-fuer-die-perfekte-Micro-Services-Architektur-9792599.html
Ich habe gelernt, wenn du überlegst mit Microservices zu starten, dann überlege dir zweimal gut ob du das wirklich willst. In den meisten Fällen willst du keine Microservices umsetzen.
Ich bin mittlerweile eher bei sowas wie einem Modular Monolithen für komplexere Systeme und erst wenn es zwingend notwendig ist würde ich die einzelnen Module in eigene Services auslagern.
Microservices bringen einfach so viel Komplexität mit wie SAGA Pattern, Verteilte Transaktionen, Outbox Pattern usw.
Module lassen sich einfacher schneiden und wenn man einmal etwas falsch eingeschätzt und die Module zu groß oder zu klein geschnitten hat ist das einfacher zu.korrigieren als in einer verteilten Architektur.
Meine Devise:
Starte einfach und wenn du wirklich Microservices brauchst dann wird sich das von alleine zeigen und sich richtig anfühlen.
Wenn man von vornherein eine Microservices Architektur umsetzt endet das meist im Chaos.
Vorallem führen Microservices zu endloser De- und Re- Serialisierung von Daten. Inklusive der "unzuverlässigkeit des Netzwerks". Selbst wenn es nur iptables innerhalb eines Kubernetes Hosts sind, ist es was anderes als in einem Prozess eine Speicheradresse zu schreiben und diese als gegeben zu betrachten.
Die Grundregel: Wenn du mehr Microservices als User hast, wird es grauenvoll.
Das kann ich unbedingt auch so empfehlen. Niemals mit Microservices anfangen. Ich bin auch kein Freund davon gleich serverless mit functions loszulegen (obwohl ich dafür eher zu haben bin als für Microservices from start...). Unsere Erfahrung mit uServices ist richtig übel ausgegangen:
Wir haben da jetzt in einem großen Projekt einen verteilten Monolithen. In einem kleineren Projekt sind wir auf den Modulithen umgestiegen, da
das Refactoring dort noch gut möglich war. Der verteilte Monolith ist zwar in einem monorepo, aber was auch immer du da anfasst, viel Spaß beim Test 😕 Eigentlich wissen wir da gar nicht mehr genau was abgeht. Klar, hier sind Fehlentscheidungen getroffen worden von Anfang an,
aber eben genau weil der Trend damals Microservices waren und man dachte das sei so toll.
Der Modulith dagegen wird immer besser, weil wir nun explizit die Abhängigkeiten testen
und sehen können und dadurch viel besser in den Griff bekommen.
Da wir mit Spring arbeiten, war das alles kein Problem mit Spring Modulith - ein Segen für uns.
Anders formuliert: Bitte nicht denken jeder muss Netflix-like die uServices Keule auspacken und Skalierbarkeit sei das Allheilmittel
oder immer Quali Kriterium Nummer 1.
Wartbarkeit, decoupling und cohesion sind häufig viel wichtiger. IMHO
Für Microservices (und jeder in seinem eigenen repo) gibt es natürlich Szenarien, aber die sind schon sehr speziell und ergeben sich
aus dem Business Case, der Organisation, der Teamstruktur, dem Design und einer entsprechenden Architekturgrundlage.
Microservices sind halt ein Werkzeug und keine Wunderwaffe
@@pinguincoder ist das so, ich mein, man sollte doch davor schon wissen, wie es geschnitten ist. Die Frage ist, ob es separate Builds sein müssen. Das Problem ist, wenn man es am Anfang nicht richtig plant wie es aufgeteilt werden muss, dann wird es umso schwieriger. Also nicht jetzt komplett alles planen, aber zumindest sollte das fachliche zumindest bekannt sein.
@@qui-gonkenobi4574 Du schaffst es meist nie die Services von Anfang an perfekt zu schneiden und wenn du sie aber bereits aufgeteilt hast ist es schwieriger etwas daran zu ändern.
Ich kenne eigentlich keine Projekte aus meiner Vergangenheit die als Microservices gestartet sind und nicht im Chaos geendet sind. Daher meine Einschätzung
Ja, wie schon in anderen Kommentaren erwähnt: Video erweckt bei mir den Eindruck als ob du einem Kleinkind erklärst, wie man eine AK-47 richtig pflegt und einsetzt. Die Tipps sind alle gut, kann da voll zustimmen (danke für die CORS Erwähnung). ABER: Wichtigster und erster Tipp sollte sein: "Mach keine Microservices!" (in 98% der Fälle) ... ausser du hast triftige Gründe / Umfeld stimmt (Projekt ist zu gross für ein Team + bist Senior-Dev; hast das schon mal gemacht; oder hast sonst Experten-Rat + unabhängiger Lifecycle ist zwingend + ...).
Finde auch, dass man unbedingt erwähnen muss, wann Microservices überhaupt Sinn machen. Die meisten Teams und Produkte haben keine Skalierungsprobleme.
Und der Tipp mit mehreren Repos ist zudem ziemlich kontraproduktiv, weil man die APIs der Dienste nie auf Anhieb richtig hinbekommt und sich die Option, Logik zwischen den Diensten zu schieben, nicht grundlos verbauen sollte.
Und außerdem wurde das Wichtigste vergessen, dass die Dienste unabhängig voneinander releasebar sein müssen und deswegen mit sämtlichen Versionen der anderen Dienste funktionieren müssen.
Dieser Kanal ist einfach pures Gold
Sehr gutes Video! Ich würde beim Design von Microservices noch darauf achten, Services so zu schneiden, dass verteilte Transaktionen möglichst unnötig sind. Two-Phase-Commit ist in den meisten Fällen sinnfrei und Sagas, egal ob orchestriert oder choreographiert, sind anspruchsvoll in der Umsetzung. Idealerweise am fachlichen Workflow orientieren und dort saubere Transaktionsgrenzen festlegen - das ist neben DDD Bounded Contexts sehr guter Input für das Schneiden von verschiedenen Services.
Sehr gut erklärt. Ist aber nur die halbe Miete. Man muss zusätzlich verstehen, in welchem Kontext Microservices überhaupt Sinn ergeben. Man hat nämlich nix gewonnen, wenn die Microservices voneinander anhängen, weil nur bestimmte Versionen miteinander funktionieren, usw.
Das Microservices Design soll großen Firmen dabei helfen, dass hunderte Entwickler am selben Backend arbeiten können, ohne sich in die Quere zu kommen. Hinter jedem Service soll ein kleines Team stehen, das an seinem Dienst entwickelt. Wenn man eh nur wenige Entwickler hat, ist es daher nicht wirklich sinnvoll, Microservices zu entwickeln.
Außerdem fehlt noch der Aspekt von Continuous Delivery, dass die Pipeline durch ausgiebige Tests definitiv feststellt, ob der Stand releasebar ist. Wenn die Pipeline durch läuft, sollte die Qualität gut genug sein, dass man den Stand ohne Bedenken in Production freigeben kann.
Ich persönlich mags übrigens lieber, wenn der Code in einem großen Repo ist. Dann kann man auch ein Docker-Compose erstellen, um die Dienste zusammen zu starten. Und außerdem kann man in Git abbilden, wenn eine Änderung mehrere Dienste gleichzeitig betrifft. Ich würde daher eher einen Ordner pro Microservice in einem großen Git Repo anlegen.
Und Branching ist auch schlecht. Unfertige Änderungen sollten sofort in origin/main, aber mit einer Feature Flag deaktiviert. Sonst kann man nicht Continuous Integration praktizieren, was per Definition verlangt, dass die Änderungen aller Entwickler mindestens 1 Mal pro Tag gemerged werden.
Die Philosophie hinter Microservices ist eigentlich das, was sie so erfolgreich macht.
Ich unterstütze den Gedanken von monorepos.
So kann auch code zwischen micro services geteilt wird wie beispielsweise datenmodelle etc. Via library
Einziger Nachteil man kann nicht so einfach automatisch die services versionieren.
Vielen Dank für dieses Video. Ich finde das einen sehr guten Vorschlag. Beeindruckend ist auch die technische sehr gute Diskussion zu Überlegung, wann man Microservices entwickeln sollte und wann nicht.
Danke für Deinen Kommentar 😊
an sich gute tipps und gutes video :)
ich find es wichtig, dass du am ende gesagt hast, dass nicht alles immer überall perfekt zutrifft. manchmal kann man nicht nur einen einzigen "main"-branch haben, weil man mehrere versionen gleichzeitig supporten muss und unter gewissen umständen halte ich konfigurations-dateien auch für praktikabler als umgebungsvariablen. (z.b. wenn es sehr viele konfigurationsmöglichkeiten gibt)
aber wenn man auf einer grünen wiese anfängt, einen neuen service zu entwickeln, dann finde ich deine tipps als leitfaden echt gut :)
Deine Umgebungsvariablen sind in einer Configmap verschlüsselt persistiert (Configmaps gibt es z.B. unter Kubernetes) und werden im Git mit IaC versioniert.
Mit Umgebungsvariable war nicht gemeint, dass du dich über SSH auf deinen Server verbindest und deine Variablen manuell in die Konsole eintippst, das ist voll 2013.
@@alex0kai Das ist mir bewusst :)
Ich begann als Steinzeitprogrammierer und entwickelte damals schon im Microservicesstil. Das war durch Adressbeschränkungen zwingend, wollte man viel erreichen. Insofern gelten die genannten Prinzipien schon immer.
Ich arbeite immer allein, da könnte man den Weg zur perfekten (Micro-)Service-Architektur sicher relativ schnell durchziehen wenn man denn will. In einem größeren Team wird so eine Umstellung aber wohl sehr aufwendig werden.
Die Log Dateien könnte man übrigens in ein Volume schreiben, dann sind sie später auch nicht weg. Und ob dynamische Subdomains für DEV Versionen notwendig ist im Einzelfall zu hinterfragen.
Schöne Woche!
Ein paar Dinge sind hier doch mit Vorsicht zu genießen. Ich würde eher davon abraten für jeden Service in ein eigenes Git-Repo anzulegen. Die Unabhängigkeit der Services sollte sich über eine gute DDD Struktur umsetzen können. Gleichzeitig würde ich eher davon abraten zu schnell den Weg in Richtung einer Microservice Architektur zu gehen. Viel mehr ist es besser mit einem modularen Monolithen anzufangen, bis die Fachlichkeit gut genug verstanden ist. Ansonsten holt man sich schon früh eine höhere Komplexität in das Projekt, was die Entwicklung und eben Refactorings erschwert. Durch einen falschen Service-Schnitt am Anfang eines Projektes schafft man sich schon viel früher eine schwerere Wartbarkeit.
Außerdem fehlt mir ein wenig ein größeres Verständis für die Zuständigkeit von Services, z.B. warum man sie anhand der Fachlichkeit schneiden sollte und nicht am Arbeitsgegenstand. Weiter kann man dann noch erwähnen, wie und warum man Anti-Corruption-Layer an den Schnittstellen einbauen sollte.
das video kommt genau richtig, danke!
Das freut mich, vielen Dank 😊
das mit den schreiben von constanten als umgebungsvariablen ist keine schlechte idee ;)
Ich weiß nicht, ob es nicht sogar je nach Anwendungsfall durchaus sinnvoll sein kann, mit gRPC/Protobuf zu starten, insbesondere wenn man ein Datenmodell zwischen mehreren Services teilen möchte, die in verschiedenen Sprachen implementiert sind, ohne dabei auf Typsicherheit zu verzichten. Dieses allgegenwärtige HTTP+JSON+JSON-Schema mit irgendeiner ad hoc runtime Validierung anstelle von einem ordentlichen typsicheren Modell bereitet mir genau dieselben Bauchschmerzen wie früher Python mit dem dynamischen Typsystem. Klar, es ist einfach, es geht schnell, aber so richtig geil finde ich es insbesondere mit statisch typisierten Sprachen, die keine runtime reflection haben, eigentlich nicht.
Ich verstehe Deinen Punkt, sehe aber bei HTTP als erstem Protokoll einen ganz anderen Vorteil gegenüber gRPC oder auch GraphQL: Ich brauche keinen speziellen Client, der mir erst noch generiert werden muss.
Sondern ich kann einfach mit curl anfangen, die API aufzurufen. Alles ist menschenlesbar, was es einfach zu debuggen macht. Und gerade, wenn man noch nicht so richtig weiß, wo man genau hinwill, finde ich gerade das Leichtgewichtige an HTTP viel praktischer als die Typsicherheit der anderen Technologien.
Langfristig bin ich bei Dir, aber deshalb gilt bei uns die Regel, zunächst mit HTTP anzufangen, und dann bei Bedarf gRPC & Co. einzuführen.
Aber wie ja auch schon im Video gesagt: YMMV
Danke für das kompakte Video! Die paar Minuten hat sicher jeder übrig, der aktuell quasi mini-VMs mit supervisord (startet dann nginx, fpm, crond, queue-consumer ...) baut und diese dann als microservice bezeichnet. Habt ihr Tipps zu Punkt 8a, womit ich service-to-service Kommunikation meine. Ich bin mir nie ganz sicher, ob man da mit klassischen east-west balancern oder doch eher mit round-robin mittels (DNS-based) service-discovery oder gar Richtung service-mesh (mit mTLS dann) gehen sollte.
Ein neues Docker Image pro Commit ist ja schön und gut. Aber realistisch gesehen muss ja irgendwann auch mal ein Cleanup stattfinden, weil man ja nicht beliebig viel Storage dafür hat.
Im Harbor gibts dafür retention Policies. Das sollte aber jedes Registry können, wundere mich, dass das für dich ein Hinderniss darstellt
@@alex0kai Ich meinte es eher so, dass man nicht beliebig lange ohne Cleanup auskommt. Das Cleanup wird in der Planung gerne vergessen und man hat dann am Ende ein Docker Image zu jedem Commit der letzten 5 Jahre rumliegen.
Für den main-Branch macht das IMHO schon Sinn, da dort ja auch jeder Commit einer neuen Version entspricht.
Die Images von den PRs kannst Du natürlich alle löschen, sobald ein PR gemerged oder geschlossen wird. Dann hält sich auch die Anzahl der Images in Grenzen.
(Dass man daran natürlich denken muss bzw dafür etwas tun muss, versteht sich von selbst.)
wann kommt denn das versprochene data mesh video?
Ich weiß, es lässt auf sich warten - aber es kommt noch … ich kann Dir nur noch nicht versprechen, wann. Aber es wird kommen 😊
Gott sei Dank bin ich "Steinzeitprogrammierer" und brauche kein Docker, Microservices und anderen neumodischen Kram. Würde auch unter FreeDOS nicht laufen.
@@alexandershendi7428 docker ist super praktisch du kannst dir eine komplette Datenbank mit ein paar Zeilen Code in einer Docker Composer hochziehen :D
Naja, man ist halt Kind seiner Zeit :-D
Das ist genauso richtig/falsch wenn einer immer das neueste einsetzt. Einsatz der Technologie sollte eher bestimmt werden, was das für eine Anforderung ist und nicht weil es alt oder neu ist.
Wir haben noch einige COBOL Programmierer bei uns. Die sagten mir mal, alles was die wissen müssen steht in einem Buch. Versionskontrolle? Unit Tests? Was für ein neumodischer Kram, alles unnötig. Da hackt man noch seinen Code selbst auf die Ausführungsumgebung und dann läuft es halt oder nicht.
Wer damit glücklich ist, bitte. Aber ob das besser ist wage ich mal zu bezweifeln.
Dem multi repo approach widerspreche ich. In großen Teams macht monorepo mehr Sinn.
Monorepos sind IMHO deutlich überbewertet und bringen ihre ganz eigenen Probleme und Nachteile mit sich … am Ende des Tages gilt aber letztlich: Der Ansatz, den man wählt, muss zum Problem und der Umgebung passen.
Das habe ich ja auch im Video schon gesagt: YMMV
Für *uns* haben sich Monorepos im Lauf der Jahre als eher schlechte Idee erwiesen, weshalb wir es heute so machen wie im Video beschrieben. Das heißt aber natürlich nicht, dass das für jede und jeden anderen auch die richtige Lösung sein muss.