Die beste Architektur für Deine Software // deutsch

Подписаться 35 тыс.

Просмотров 8 тыс.

50% 1

Die beste Architektur für Deine Software ist - der Monolith. Oder doch Client-Server? Oder eine Architektur auf der Basis von Microservices? Für jede Architektur gibt es Pro und Contra, doch woher weiß man, wann welche Architektur die richtige ist?
00:00 - Einleitung
01:19 - Was ist Architektur?
02:54 - Software- vs Systemarchitektur
04:12 - Anwendungen vs Prozesse
05:40 - Echte Monolithen gibt es (fast) nicht
07:29 - Das Backend als Monolith
08:35 - Was für Monolithen spricht
09:47 - 24/7, Zero-Downtime & Co.
10:30 - Redundante Entwicklung
11:59 - Authentifizierung als Service auslagern
13:41 - Weitere orthogonale Aspekte
15:21 - Fachliche und technische Aspekte trennen
17:17 - Was sind Services?
18:28 - Komplexität von Services
20:25 - Welche Architektur wann?
────────────────────
Über the native web 🦄
Wir sind ein Beratungs-, Schulungs- und Entwicklungsunternehmen, das sich auf Web- und Cloud-Technologien spezialisiert hat. Wir streben nach intelligenten und eleganten Lösungen für komplexe Probleme, und wir glauben, dass Softwareentwicklung kein Selbstzweck ist. Stattdessen sollte Software tatsächliche Probleme der realen Welt lösen.
Wir glauben, dass native Web- und Cloud-Technologien das Fundament sind, auf dem die Zukunft aufbaut. Unsere Kernkompetenz ist der Entwurf und die Entwicklung verteilter Web- und Cloud-Anwendungen unter Verwendung dieser Technologien in interdisziplinären Teams. Wir entwickeln auch unser eigenes Open-Source-Framework namens wolkenkit. Und wir lieben es, unser Wissen in Schulungen und Workshops, auf Konferenzen und bei Usergroups zu teilen.
⬥ Kanal abonnieren: / @thenativeweb
────────────────────
Weiterführende Links 🌍
⬥ Webseite: www.thenativeweb.io/
⬥ App: app.thenativeweb.io/
⬥ Discord: / discord
⬥ Twitter: / thenativeweb
⬥ GitHub: github.com/thenativeweb
⬥ Impressum: www.thenativeweb.io/company/l...

Наука

Опубликовано:

1 авг 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 31

@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!

@SirEvildeath Год назад

Wie immer ein mega content lieber Golo 🥳😎👍

@ScriptRaccoon Год назад

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

@michaelrichter9408 Год назад

Super Content. Vielen Dank.

@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.

@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 :)

@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.

@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: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-SR4GhA2sKIU.html 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 😊

@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 3 месяца назад

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.

@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!

@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 😅

@christianbaer2897 Год назад

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

@customraspi 10 месяцев назад

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.

@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.

@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.