Die beste Architektur für Deine Software // deutsch

[@johnjohnson7500]

Diesmal waren ein paar Wiederholungen im Video dabei, aber nichts was störend wäre. Wie du ja schon häufig gehört hast, ist dein Vortragsstil mehr als angenehm und dann kann das Video ruhig etwas länger als nötig sein :) Danke für all diese hochqualitativen Tech-Videos!

[@allinvanguard]

Ich finde auch den Ansatz des Modulithen super als Startpunkt, um mit geringer Komplexität zu starten, aber sich die Türe zu eigenständigen Services offen zu halten. Verlangt natürlich etwas mehr Disziplin um die Modulgrenzen sauber zu halten.

[@felixrejmer7566]

Denke das ist genau der Knackpunkt. Es erfordert Disziplin und bei einem großen bzw. mehreren Entwicklerteams muss man als Architekt dafür sorgen, dass alle verstehen auf was geachtet werden muss um "die Türe offen zu halten".

[@johnjohnson7500]

Meintest du Monolith anstelle von "Modullith"? :)

[@felixrejmer7566]

@@johnjohnson7500 Wobei ich "Modulith" als Namen für einen modularen Monolithen super finde...

[@allinvanguard]

@@johnjohnson7500 Nein, Modulith passt :D Effektiv ein modularisierter Monolith

[@johnjohnson7500]

​@@allinvanguardOK, jetzt verstehe ich auch deinen gesamten Kommentar. Sorry, ich kannte den Begriff eines "modularen Monolithen" absolut nicht :)

[@fl0aten]

Klasse Video! Aber mich interessiert bei vielen Themen, wie das in der Praxis aussieht. Damit meine ich weniger das Endresultat bzw. das Produktiv-System, sondern eher die tägliche Arbeit auf dem lokalen Rechner. Wie arbeite ich an einem verteilten System/viele Services. Wie fahre ich den "Stack" hoch, wenn viele dieser Services in verschiedenen Repos liegen, oder noch schlimmer, von verschiedenen Teams entwickelt werden. Wie kann ich meine Applikation lokal testen, wenn diese von z.B. 5 fremden Services abhängt?

[@Hans-ArnoNuernberger]

Sag mal, habt ihr schon mal ein Video über Serverless Architecture gemacht? Würde mich sehr interessieren. Wenn ja, finde ich es leider nicht. Ansonsten gibt es von mir nur Daumen hoch. Toller Kanal

[@thenativeweb]

[gr] Nicht so richtig … am ehesten trifft es dieses Video hier: kzbin.info/www/bejne/iYOXeJt3Z9h-f7c Aber wäre mal ein Thema, das ein Video wert wäre 😊 Generell, zum Suchen übrigens, könnte app.thenativeweb.io/ für Dich interessant sein 😊

[@Metalkillsrap]

Wie immer richtig starker Content! Die Frage nach der passenden Architektur ist manchmal wirklich nicht einfach- ich arbeite im Bereich der Labordigitalisierung und sehe mich stets mit diversen losen Enden konfrontiert, die zu einem sinnvollen und verlässlichen Gesamtwerk verwoben werden wollen. Dabei sind von Gerätetreibern (low level), Legacy-Monolithen ohne sinnvolle Schnittstellen, Business-Services, Workflowmanagement, Design of Experiment/ Data Analytics für Mess- und Telemetriedaten bis hin zu Papier wirklich alles an Albträumen vorhanden. Das führt leider sehr oft zu irgendwelchen Individuallösungen je nach Kundenprojekt, weil es sehr schwierig ist, auch nur Teile davon im Sinne einer sinnvollen Middleware-Softwarearchitektur wiederverwendbar zu machen.

[@Mindspectrum]

Ich arbeite auch in diesem Bereich und kann dir absolut zustimmen. Wenn dann auch noch regulatorische Vorgaben wie GxP dazu kommen, wird es richtig spaßig.. Dann fallen tolle Lösungen schon von vornerein raus, weil sie nicht validiert sind bzw. die Validierung gescheut wird. Was bleibt sind Lösungen mit veraltete Technologien und viele viele Kompromisse.

[@Metalkillsrap]

@@Mindspectrum vielleicht sollten wir uns mal austauschen!

[@anion21]

Ich finde dieses Video richtig gut. Inhaltlich und auch generell. Entwickler unterschätzen meines Erachtens oft, wie wichtig dieses Thema ist. Ich hab den Eindruck, viele Software-Projekte scheitern, weil sich die Entwickler nicht genug Gedanken über die Architektur gemacht haben, weil das dann nicht wartbar ist, man Fehler nur schwer finden kann, keine klar definierten Trennung von Anwendungs-Komponenten hat, etc.. Awareness und Wissen zu dem Thema erhöhen ist deswegen so wichtig.

[@Johnny051981]

Super Video. Gerade bei Webseiten kommt man mit Authentifizierung, Logging, Firewall, u.v.m nicht um Services herum. Na, wenn die Anwendung ein Taschenrechner sein soll, kann es ein Monolith sein. Ansonsten kommt man so häufig nicht um Services herum. Ist im Video super erklärt.

[@christianbaer2897]

"Ich habe nicht für jeden Anwender einen eigenen Server" AWS Lambda: "Hold my beer" 😉

[@ScriptRaccoon]

Sehr interessantes Video! Das Thema Software-Architektur ist noch sehr neu für mich. Mit dem Video habe ich einen guten Einblick bekommen.

[@SirEvildeath]

Wie immer ein mega content lieber Golo 🥳😎👍

[@michaelrichter9408]

Super Content. Vielen Dank.

[@josefpharma4714]

Wenn man keine Microservice Architektur verwendet ist es meiner Erfahrung nach entscheidend Modularisierung zu beachten. Und zwar nicht horizontal sondern themenbezogen, sprich vertikal. Sonst bekommt man schnell ein System mit „Spider-Web“ Tendenz 😅

[@customraspi]

Du beschreibst gerade 1:1 das FOP-System nur mit dem Unterschied, dass du alles auf Microservices beziehst, während FOP ein FOP/AOP Composer ist, der die Anwendung als Monolith compilt, während man modular entwickelt/testet.

[@josefpharma4714]

Ein wesentlicher Aspekt der neben Skalierbarkeit für Microservices spricht ist die Anzahl der Menschen, die daran arbeiten. Es ist IMHO suboptimal, wenn 10 Teams am selben Monolithen herum werkeln.

[@Juus]

Finde persönlich dass die eine Architektur die andere nicht ausschließt. Siehe Amazon, die haben an einer Stelle einen Monolithen lieber implementiert weil es da mehr Sinn macht bzgl Perfomance und Kosten.

[@josefpharma4714]

Mit dem Begriff service wär ich vorsichtiger. Der wird für so vieles verwendet, da würde ich zumindest in diesem Kontex „Microservice“ verwenden.

[@anion21]

Der Begriff Service wird für vieles verwendet ja. Aber ich denke hier sind gar keine Microservices gemeint. Siehe den Abschnitt ab 11:59. Eine Benutzerverwaltung (im Video und auch generell aka Authentifizierungsservice) ist z. B. ein Service, der auch als "klassischer Service" implementiert werden kann, ohne Microservices. Die zur Verfügung gestellte Funktionalität wird generell immer als Service bezeichnet. Ob das mittels Microservice oder anders implementiert wird, hängt vom Anwendungsfall ab. Und ob Microservice oder nicht, darum ging es in dem Video höchstens sekundär. Und der Satz ab 17:17 trifft übrigens auch auf Services zu, die keine Microservices sind.

[@derpinguin8307]

Schön fleißig gendern. 🥱 Ansonsten top 🥳

[@ValarMorghulis858]

Ich finde es auch eher nervig. Wenn von "Anwendern und Entwicklern" die Rede ist, habe ich nicht Männer vor meinem geistigen Auge, sondern die jeweilige Personengruppe, welche dieser Tätigkeit nachgeht - völlig unabhängig vom Geschlecht. Die ständige Doppelnennung lenkt den Fokus aber weg vom eigentlichen Thema und zieht das Video nur unnötig in die Länge.

[@lnplum]

Es ist ein seltsamer Trend, dass die Leute, die sich über "gendern" beschweren, weil sie sich die Sprache nicht vorschreiben lassen wollen, anderen vorschreiben wollen, dass sie nicht "gendern" sollen. Oder dass man Sprachentwicklung "nicht erzwingen kann" und deswegen versuchen, zu erzwingen, dass Leute nicht "gendern". Hör doch einfach drüber hinweg. Der einzige Grund, dass es dich stört, ist, dass du es nicht gewohnt bist. Du bist nicht aufmerksamer, du bist nur alt (willkommen im Club!). Das ist nicht tiefgründiger als sich über "die ganzen Anglizismen" zu beschweren, oder dass "etwas nicht Sinn macht sondern Sinn ergibt" oder rot wird, wenn man darüber redet, wie "geil" etwas ist. "Gendern" ist sowieso ein Unwort. Die deutsche Sprache ist ja bereits "gegendert": die meisten Hauptwörter haben ein grammatikalisches Geschlecht, welches bei Berufen und Personen eben häufig auch ein Gender (also soziales Geschlecht) impliziert. "Gendern" löst diese implizite Vorgabe auf, im Grunde ist es also ein "Entgendern".

[@lnplum]

Übrigens wäre "Doppelnennung" ständig umständlich von "Programmierern und Programmiererinnen" usw zu reden. Dagegen ist ein einfaches "_innen" echt harmlos und schließt gleichzeitig nonbinäre Menschen mit ein. Es ist präziser, korrekter und inklusiver. Als Entwickler sehe ich da kein Problem. Wenn es dir zu lang ist, ändere halt die Wiedergabegeschwindigkeit.

[@josefpharma4714]

Mit dem Begriff service wär ich vorsichtiger. Der wird für so vieles verwendet, da würde ich zumindest in diesem Kontex „Microservice“ verwenden.

[@cyrusol]

Ich wäre eher mit dem Begriff Microservice vorsichtiger, weil da das "Micro" extrem aufgeweicht wurde. Ursprünglich hat man an 200-300 Zeilen Code gedacht, die man nicht unit-tested, sondern einfach den ganzen Service insgesamt über z.b. Systemtests, und man refactored auch nichts, wenn es nicht mehr passt, sollte man es einfach wegwerfen und neu machen. Ich will behaupten, dass 99% aller Microservices dieser Idee NICHT folgen - Und sie sollten es wohl auch nicht. Der Begriff Service im Kontext einer SOA, service-oriented architecture (was ein viel älterer Begriff ist als Microservice), geht zum Glück viel weiter/ist allgemeiner gehalten. Im Großen und Ganzen sollte man mit allen Begriffen mit Bedacht umgehen.