Connect with us

Entwicklung & Code

Wenn Intuition versagt: KI und die Grenzen unserer Vorstellungskraft


Viele sprechen davon, dass Künstliche Intelligenz in n-dimensionalen Räumen arbeitet – und meistens klingt das irgendwie nach Science-Fiction. Wenn man das hört, denkt man sofort an fremde Welten, an Paralleluniversen, kurz: an Dinge, die sich unser Gehirn nicht vorstellen kann.


the next big thing – Golo Roden

the next big thing – Golo Roden

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.

Doch genau da liegt das Problem: Wir Menschen versuchen nur allzu gerne, uns alles bildlich vorzustellen. Aber ab der vierten Dimension klappt das nicht mehr. Wir stolpern, scheitern und merken, dass unsere Vorstellungskraft an diesem Punkt endet.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.

KI ist mächtig, aber keine Magie // deutsch

Dennoch sind hochdimensionale Räume in der KI ganz normaler Alltag. Sprachmodelle, Bilderkennung, Empfehlungssysteme – sie alle arbeiten in weitaus mehr als nur drei Dimensionen. Aber kaum jemand kann wirklich erklären, was das konkret bedeutet. Die Aussage, etwas passiere in einem 27-dimensionalen Raum, klingt natürlich eindrucksvoll, aber was steckt dahinter? Ist das ein ganz anderer Raum, quasi eine fremde Welt, etwas, das wir niemals begreifen können? Oder ist es vielleicht doch viel einfacher, als wir zunächst glauben?

Genau da möchte ich Sie heute abholen. Denn es lohnt sich, das zu verstehen. Nicht nur, um mitreden zu können, wenn wieder jemand von tausenden Dimensionen spricht. Sondern auch, weil es zeigt, warum KI oft so schwer nachvollziehbar ist, warum Sprachmodelle Vektordatenbanken brauchen und warum am Ende nicht irgendein magischer Algorithmus entscheidet, ob eine KI funktioniert, sondern ganz klassisch Erfahrung und Fachwissen.

Klären wir zunächst einmal, was Dimensionen überhaupt sind. Auf mich hat das lange sehr gewaltig gewirkt, so, als ob man dafür Astrophysik studiert haben müsste. Aber in Wahrheit steckt da etwas sehr viel Einfacheres dahinter: Eine Dimension ist nämlich nichts anderes als ein Merkmal, eine Eigenschaft, ein Freiheitsgrad – wie auch immer Sie das nennen wollen.

Wenn wir nur eine einzige Dimension haben, dann genügt eine einzelne Zahl, um etwas zu beschreiben. Nehmen Sie zum Beispiel die Temperatur. Sie können sagen:

„Heute sind es 15 Grad.“

Mehr brauchen Sie nicht, um klarzumachen, wie warm oder wie kalt es ist. Eine Zahl genügt. Das ist eine eindimensionale Welt.

Fügen wir eine zweite Dimension hinzu, wird es spannender. Denn dann brauchen Sie schon zwei Zahlen, um sich zurechtzufinden. Stellen Sie sich eine Landkarte vor. Ein einzelner Wert sagt Ihnen nur, wie weit Sie nach links oder nach rechts gehen müssen. Doch ein zweiter Wert sagt Ihnen, wie weit Sie nach oben oder unten gehen müssen. Das heißt: Zwei Dimensionen benötigen zwei Zahlen – und schon können Sie sich auf einer Fläche bewegen.

In der dritten Dimension leben wir alle. Hier genügt die Karte nicht mehr, weil sie nur die Höhe und die Breite kennt. Wir benötigen zusätzlich aber noch die Tiefe. Erst damit können wir wirklich beschreiben, wo sich etwas in unserer Welt befindet. Das heißt, mit drei Zahlen können Sie jedes Objekt eindeutig in Raum und Lage festlegen. Und genau hier steckt die erste entscheidende Erkenntnis: Mehr Dimensionen sind nichts Mystisches, nichts Magisches, sondern einfach nur zusätzliche Eigenschaften. Jede Dimension bedeutet: ein Freiheitsgrad mehr, eine Variable mehr, ein Stück zusätzliche Information.

Nun könnte man denken:

„Na gut, wenn drei Dimensionen so logisch sind, dann sind vier doch bestimmt auch kein Problem. Dann nehmen wir einfach noch eine Zahl dazu – und schon haben wir die vierte Dimension.“

Theoretisch stimmt das sogar. Mehr als das ist es nämlich tatsächlich nicht. Praktisch merken wir jedoch: Wir können uns das nicht mehr vorstellen. Unser Gehirn stößt an eine Grenze, und deshalb sagen viele Menschen dann, dass es gar keine vierte Dimension gebe.

Um das besser verstehen zu können, hilft ein kleines Gedankenexperiment. Stellen Sie sich vor, es gäbe Lebewesen, die nur auf einer Linie leben. Diese kennen dann logischerweise nur eine Richtung, nämlich vorwärts und rückwärts. Das ist ihre Welt. Für sie gibt es weder oben noch unten, weder links noch rechts. Alles, was sie wahrnehmen können, spielt sich auf dieser Linie ab. Diese Linie könnte nun aber auf einem Blatt Papier gezeichnet sein. Und das hieße, dass es durchaus zwei Dimensionen gäbe (nämlich die Länge und die Breite des Blattes), aber weil diese Lebewesen nur die Linie wahrnehmen können, wirkt es für sie wie eine rein eindimensionale Welt.

Jetzt stellen Sie sich ein weiteres Lebewesen vor, das auf ebendiesem Blatt Papier lebt. Für dieses Wesen gibt es nun weitere Richtungen: vorwärts und rückwärts sowie links und rechts. Ein Leben in zwei Dimensionen. Das ist schon viel komplexer, als nur auf einer Linie hin- und herzuwandern. Aber was für uns völlig selbstverständlich ist – nämlich dass man ein Blatt Papier auch hochheben oder drehen kann –, existiert in der Welt dieses Wesens nicht. Es hat schlicht keine Vorstellung von Höhe oder Tiefe. An der Stelle sei die Erzählung Flächenland von Edwin Abbott Abbott empfohlen.

Und genau so geht es uns Menschen. Wir können uns eine dreidimensionale Welt vorstellen, weil unsere Wahrnehmung dreidimensional arbeitet. Aber sobald eine vierte Dimension dazukommt, verlieren wir den Halt. Unser Gehirn ist schlicht nicht dafür gemacht, sich das anschaulich vorzustellen. Das bedeutet jedoch nicht, dass diese vierte Dimension nicht existieren würde oder nicht berechenbar wäre. Ganz im Gegenteil: Die Mathematik kümmert es überhaupt nicht, ob wir uns etwas vorstellen können oder nicht. Für sie ist es völlig normal, mit vier, fünf, 27 oder auch 5.000 Dimensionen zu rechnen. Nur wir Menschen scheitern daran, ein Bild davon in unserem Kopf zu erzeugen. Und genau das ist die zweite wichtige Erkenntnis: Dass wir etwas nicht visualisieren können, heißt noch lange nicht, dass es nicht real ist – und schon gar nicht, dass wir es nicht berechnen könnten.

Wenn wir nun von Künstlicher Intelligenz sprechen, sind Dimensionen letztlich nichts anderes als Merkmale, die unsere Daten beschreiben. Um ein konkretes Beispiel zu nennen: Denken Sie bitte kurz an ein Musikstück, das Ihnen gut gefällt. Da gibt es das Tempo, gemessen in Beats per Minute (BPM). Es gibt die Lautstärke, die man in Dezibel angeben kann. Es gibt die Frage, ob Gesang vorkommt oder nicht, welche Instrumente eingesetzt werden und so weiter. All das sind Eigenschaften und jede einzelne dieser Eigenschaften entspricht einer Dimension.

Das heißt: Je mehr Merkmale wir aufnehmen, desto mehr Dimensionen kommen hinzu. Bei Musik könnten das auch noch die Tonhöhe sein, die Länge eines Stücks, die Tonart, die Verteilung der Wellen im Frequenzspektrum und so weiter. Jede dieser Eigenschaften ist eine Variable und zusammen bilden sie einen Raum, in dem jedes Musikstück seinen Platz hat. Dasselbe gilt natürlich nicht nur für Musik, sondern für alle Daten.

Plötzlich wird klar: Dimensionen in der KI sind nichts Abgehobenes, keine geheimnisvollen Räume, sondern schlicht und einfach nur Features: Dinge, die man messen, beobachten oder aus den Daten ableiten kann. Und das ist die dritte wichtige Erkenntnis: In der KI sind Dimensionen keine Science-Fiction-Welten, sondern handfeste Eigenschaften. Mehr Dimensionen bedeuten mehr Informationen, die ein Modell gleichzeitig berücksichtigen kann.

Besonders interessant wird es nun, wenn wir uns Sprachmodelle anschauen. Denn Sprache funktioniert nur, wenn wir Bedeutungen verstehen, wenn wir merken, dass bestimmte Wörter nah beieinanderliegen, dass sie ähnlich sind, dass sie etwas miteinander zu tun haben. Und genau dafür brauchen Sprachmodelle sogenannte Vektordatenbanken. Man kann sich das vorstellen wie eine riesige Landkarte – aber eben nicht in zwei Dimensionen, sondern in hunderten oder gar tausenden. Jedes Wort ist ein Punkt in diesem Raum. Wörter, die oft gemeinsam vorkommen, liegen nah beieinander. Wörter, die Gegensätze sind oder nichts miteinander zu tun haben, liegen weit auseinander. Wörter, die in ähnlichen Kontexten auftauchen, rücken wiederum näher zusammen.

Nehmen Sie beispielsweise die Begriffe „Natur“ und „Technologie“. Die beiden sind vermutlich ziemlich weit voneinander entfernt. „Computer“ und „Technologie“ hingegen liegen wahrscheinlich nah beieinander. Das Wort „Baum“ ist ganz klar bei „Natur“ angesiedelt, aber nicht ganz so weit von „Technologie“ entfernt, wie man zunächst vermuten würde, denn auch in der Informatik sprechen wir von Bäumen, wenn wir bestimmte Datenstrukturen meinen.

Rasch wird klar, dass nur zwei oder drei Dimensionen für diesen Ansatz niemals ausreichen. Auf einer zweidimensionalen Karte oder selbst in einem dreidimensionalen Raum könnten Sie vielleicht ein paar Wörter sinnvoll anordnen, aber die Mehrdeutigkeit ginge schnell verloren. Es braucht viel mehr Freiheitsgrade, um die feinen Unterschiede abzubilden. Deshalb arbeiten Sprachmodelle mit vielen tausend Dimensionen. Denn nur so können sie die Vielfalt und die Nuancen menschlicher Sprache erfassen. Und das führt uns direkt zur vierten wichtigen Erkenntnis: Vektordatenbanken sind nichts anderes als mehrdimensionale Karten von Bedeutungen. Ohne sie könnten Sprachmodelle nicht funktionieren.

So faszinierend das alles klingt, bringt es doch ein ganz eigenes Problem mit sich: Je mehr Dimensionen wir hinzufügen, desto schwieriger wird es für uns, mit einfachen Begriffen wie „Nähe“ oder „Abstand“ umzugehen. In zwei oder drei Dimensionen haben wir ein klares Gefühl dafür: Wir können sehen, ob zwei Punkte nah beieinander liegen oder weit auseinander. Wir können intuitiv einschätzen, ob Dinge zusammengehören oder nicht. In 27 oder 5000 Dimensionen funktioniert das jedoch nicht mehr. Mathematisch lässt sich der Abstand zwar problemlos berechnen, aber unsere Intuition hört auf, uns dabei zu helfen.

Das führt dazu, dass Abstände ihre Aussagekraft verlieren. Dinge, die in drei Dimensionen klar voneinander getrennt wären, rücken in höheren Dimensionen oft erstaunlich nah zusammen. Oder umgekehrt: Punkte, die in zwei Dimensionen nahe beieinander erscheinen, können in einem Raum mit vielen Dimensionen plötzlich extrem weit auseinanderliegen.

Gerade für das Clustering, also das Bilden von Gruppen und Ähnlichkeiten, ist das ein echtes Problem. Denn: Je mehr Dimensionen es gibt, desto schwieriger wird es, sinnvolle Strukturen zu erkennen. Die Daten verhalten sich für uns Menschen plötzlich fremd, unanschaulich, manchmal sogar widersprüchlich. Das ist der sogenannte „Curse of Dimensionality“. Mit jeder zusätzlichen Dimension schrumpft unsere Fähigkeit, das Ganze noch zu durchschauen. Was für den Computer nur Mathematik ist, wird für uns zur Blackbox. Und das ist die fünfte wichtige Erkenntnis: Mehr Dimensionen bedeuten zwar mehr Möglichkeiten für die KI, für uns Menschen jedoch weniger Intuition und weniger Nachvollziehbarkeit.

In der Praxis bedeutet das, dass je mehr Dimensionen eine KI nutzt, die Frage umso wichtiger wird, welche Eigenschaften wir überhaupt hineingeben. Das heißt, die Datenvorbereitung und die Auswahl der richtigen Features sind entscheidend. Das klingt leider oft wesentlich leichter, als es tatsächlich ist. Denn es gibt keinen magischen Algorithmus, der uns sagt, welche Merkmale am besten geeignet wären, wie wir sie normalisieren müssten oder wie wir sie am besten kombinieren könnten. In der Realität bedeutet das: Man muss es ausprobieren. Man testet verschiedene Kombinationen, schaut, welche Ergebnisse dabei herauskommen, justiert nach und probiert wieder von vorn.

Das ist manchmal sehr mühsam und oft auch frustrierend. Aber es ist die Realität in der KI-Entwicklung. Am Ende ist es eine Mischung aus Statistik, Wahrscheinlichkeiten und sehr viel Ausprobieren. Provokant könnte man sagen: KI ist letztlich nur besseres Raten. Sie arbeitet nicht mit Gewissheiten, sondern mit Wahrscheinlichkeiten, mit Unschärfen, mit Annäherungen.

Genau darin liegt die große Herausforderung: Je mehr Dimensionen im Spiel sind, desto weniger können wir uns auf unsere Intuition verlassen. Wir können nicht mehr einfach draufschauen und sehen, warum die KI eine bestimmte Entscheidung getroffen hat. Wir sind darauf angewiesen, das Ganze mathematisch zu verstehen oder zu akzeptieren, dass es für uns eine Blackbox bleibt. Das ist die sechste wichtige Erkenntnis: KI ist mächtig, aber keine Magie. Sie ist im Kern Statistik auf Steroiden.

Genau an diesem Punkt bekommen so viele Menschen einen falschen Eindruck: Weil KI für uns so oft wie eine Blackbox wirkt, glauben wir schnell, KI sei etwas „Magisches“. Etwas, das von allein funktioniert, quasi: Man wirft Daten hinein, und die Maschine findet schon die richtigen Muster. Aber so funktioniert es nicht.

Gerade weil KI so viel Trial and Error ist, braucht es Menschen, die Erfahrung mitbringen. Menschen, die fachlich verstehen, welche Merkmale überhaupt sinnvoll sind. Denn wenn man die falschen Features auswählt, kann das Modell noch so groß und komplex sein – es wird niemals zu brauchbaren Ergebnissen kommen. Das heißt: Es braucht technisches Know-how, um Architekturen zu bauen, die mit dieser Mehrdimensionalität umgehen können. Es reicht nicht, einfach eine KI zu trainieren, sondern man muss wissen, wie man Daten normalisiert, vorbereitet und strukturiert. Und es braucht Erfahrung, um aus diesem Trial and Error ein zumindest halbwegs zielgerichtetes Vorgehen zu machen. Nicht einfach blind irgendetwas zu probieren, sondern zu verstehen, warum ein bestimmter Ansatz funktioniert oder warum er scheitert.

Und das ist die siebte wichtige Erkenntnis: KI-Erfolg ist keine Frage von Magie, sondern das Ergebnis einer Kombination aus Statistik und Expertise. Ohne Fachwissen bleibt KI blind. Ohne Erfahrung bleibt sie zufällig. Erst die Verbindung macht sie wirklich wertvoll.

Wenn Sie sich das alles noch einmal vor Augen führen, bleibt ein klares Bild: KI arbeitet in unglaublich vielen Dimensionen. Dimensionen, die wir uns nicht vorstellen können, weil unser Denken schon bei der vierten an seine Grenzen stößt. Genau das macht KI so mächtig und gleichzeitig so schwer nachvollziehbar. Deshalb genügt es nicht, einfach irgendein Modell laufen zu lassen: Es braucht Fachwissen, um die richtigen Features zu wählen. Es braucht technisches Know-how, um Architekturen zu bauen, die mit dieser Mehrdimensionalität zurechtkommen. Und es braucht Erfahrung, um das Ganze in eine Richtung zu lenken, die wirklich Ergebnisse bringt.


(rme)



Source link

Entwicklung & Code

Warum viele Teams mit Monolithen besser fahren als mit Micro-Frontends


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

Softwarearchitektur kennt Moden und Gegenbewegungen. Frontends in winzige unabhängige Teile zu zerschneiden, galt in den letzten Jahren als modern: Micro-Frontends und Microservices. Heute zeigt sich: Der Ansatz bleibt wertvoll. Aber nur dort, wo er die organisatorische Realität tatsächlich abbildet. Für viele kleine bis mittlere Teams ist ein modularer Monolith oft die robustere Startarchitektur.


Nicolai Wolko

Nicolai Wolko

Nicolai Wolko ist Softwarearchitekt, Consultant und Mitgründer der WBK Consulting AG. Er unterstützt Unternehmen bei komplexen Web- und Cloudprojekten und wirkt als Sparringspartner sowie Gutachter für CTOs. Fachbeiträge zur modernen Softwarearchitektur veröffentlicht er regelmäßig in Fachmedien und auf seinem Blog.

Die internationale Umfrage State of Frontend des Unternehmens The Software House zeigt eine klare Bewegung: 2022 gaben 75,4 Prozent der Befragten an, Micro‑Frontends zu nutzen. 2024 waren es nur noch 23,6 Prozent. Das klingt auf den ersten Blick dramatisch, ist aber kein Tod der Idee. Der Rückgang zeigt, dass viele Teams Micro-Frontends nicht mehr als Standardlösung betrachten, sondern selektiv dort einsetzen, wo organisatorische oder architektonische Gründe es rechtfertigen. Denn parallel dazu steigt die Popularität von Module Federation, und zwar nicht nur für Micro‑Frontends: 2024 berichten 51,8 Prozent die Nutzung, oft auch in monolithischen Anwendungen, um Teile unabhängig zu aktualisieren. Das stützt die These einer Konsolidierung auf weniger Deployment-Einheiten bei weiterhin modularer Struktur.

Bemerkenswert ist, dass auch KI Microservices favorisiert: Fragt man ChatGPT ohne Kontext nach Architekturmustern, empfiehlt es fast immer Microservices und oft auch Micro-Frontends. Das ist kein Indiz für universelle Richtigkeit, sondern für den Hype-Bias in den Trainingsdaten. Ohne fachliche Einordnung bleibt es eine Wahrscheinlichkeitsaussage und ersetzt nicht die Analyse eines erfahrenen Architekten oder einer erfahrenen Architektin.

Micro-Frontends entstanden als Analogie zu Microservices und erfreuen sich nicht ohne Grund großer Beliebtheit. Die Idee besteht darin, schwerfällige SPAs oder Webportale in kleine, autonome Apps aufzuteilen. Jedes Team kann sein Stück mit dem Lieblingsframework entwickeln und unabhängig deployen. Das reduziert den Koordinationsaufwand, vermeidet monolithische Rebuilds und erlaubt, Teile des Frontends asynchron zu laden.

In der Praxis führt diese Freiheit jedoch auch oft zu neuen Problemen: Mehrere Frameworks oder UI-Bibliotheken erhöhen die Downloadgröße und verlängern die Time to Interactive, globale Stores oder Shells schaffen den berüchtigten Hidden Monolith oder verteilten Monolithen, in dem Micro-Apps weiterhin denselben Zustand teilen, und zusätzliche Deployments erzeugen Overhead bei CI/CD, Feature Flags und Versionierung.

Micro‑Frontends eignen sich, wenn wirklich unabhängige Teams und heterogene Stacks aufeinandertreffen, etwa bei Tech‑Riesen wie Amazon oder Spotify. In sehr vielen Projekten erzeugt die zusätzliche Orchestrierung jedoch mehr Probleme, als sie löst und sorgt schnell für komplexe Builds und längere Ladezeiten. Gerade bei kleineren Teams und klar abgegrenzten Produkten übersteigt der Aufwand den Nutzen, und die erhoffte Entkopplung bleibt aus. Oft entsteht faktisch ein verteilter Monolith mit zahlreichen Teilprojekten, die doch nur gemeinsam leben können. Eine fatale Entwicklung, denn der verteilte Monolith vereint oft die schlechtesten Eigenschaften beider Welten in sich.

Die Debatte über Monolithen und Microservices krankt oft daran, dass Begriffe nicht klar sind. Ein Beitrag auf dem Dev-Details-Blog erläutert anschaulich, dass die Einordnung nicht von der Anzahl der Repositories, Container oder Teams abhängt:

  • Ein Monolith entsteht, wenn mehrere Teile so eng gekoppelt sind, dass sie nur gemeinsam deployt werden können.
  • Microservices wiederum zeichnen sich durch lose Kopplung und hohe Kohäsion aus. Sie können Daten und Ressourcen mit anderen Diensten teilen, solange jede Komponente ihre eigene Verantwortung behält.
  • Serverless bedeutet nur, dass die Infrastrukturverwaltung abstrahiert wird. Es ist kein Synonym für Function as a Service. Entscheidend ist, dass sich die Teams nicht um Server kümmern müssen und nur für tatsächliche Nutzung bezahlen.

Diese Perspektive hilft, Modebegriffe zu entmystifizieren. Man kann monolithische, Microservices‑basierte oder Serverless-Architekturen mischen – entscheidend ist, wie stark die Komponenten voneinander abhängen. Wenn mehrere Services stets gemeinsam deployt werden müssen, entsteht faktisch wieder ein „verteilter Monolith“.

Oft zitiert wird das Team hinter Amazon Prime Video, wie auch bereits auf heise berichtet. Es hat 2023 die Audio/Video-Monitoring-Komponente von einem Step-Functions-getriebenen verteilten Design auf ein monolithisches Prozessdesign umgestellt, was zu über 90 Prozent geringeren Kosten und höherer Skalierbarkeit für diese Komponente führte.

Das ist keine Abkehr von Microservices im gesamten Produkt, aber eine klare kontextspezifische Optimierung: weniger Netzwerk-Hops, wegfallender S3-Zwischenspeicher und weniger Orchestrierungs-Overhead.

Ein hervorragendes Beispiel dafür, dass Architektur keinem Etikett folgen sollte, sondern in diesem Fall dem Lastprofil und Coupling. Microservices und Serverless sind Werkzeuge, die bei passender Problemklasse hervorragend funktionieren; andernfalls ist ein enger gekoppelter Entwurf aber günstiger und einfacher zu betreiben.

Praktische Erfahrungen bestätigen diese Sicht: Ken Kantzer, VP Engineering bei FiscalNote und Gründer der Sicherheits- und Architekturberatung PKC Security, hat in über zwanzig Code-Audits von Start-ups wiederkehrende Muster identifiziert. Sein Befund: Die erfolgreichsten Unternehmen hielten ihre Architektur bewusst einfach. Teams, die konsequent nach dem Prinzip „Keep it simple“ arbeiteten, dominierten später ihre Märkte.

Demgegenüber verschwanden viele Firmen, die sich früh in komplexe Architekturexperimente stürzten. Kantzer hält die vorzeitige Umstellung auf Microservices, stark verteilte Systeme und Messaging-lastige Designs für eine eine selbst verschuldete Falle, die Teams in unnötige Betriebs- und Entwicklungsprobleme manövriert. In seinen Audits zeigte sich, dass solche Systeme einen Großteil der Entwicklerzeit mit Queue-Fehlern, Versionsinkompatibilitäten und Netzwerk-Latenzen blockierten, während die eigentliche Produktentwicklung ins Stocken geriet.

Die Lehre: Komplexität ist keine Investition in Zukunftsfähigkeit, wenn sie dem Kontext vorauseilt – sie ist ein Kostenfaktor, der den Markterfolg gefährden kann.

Der modulare Monolith oder auch Modulith vereint die Vorteile von Monolith und Microservices: Die Anwendung wird in klar abgegrenzte Module unterteilt, die sich intern unabhängig entwickeln, testen und versionieren lassen, aber gemeinsam deployed werden. Thoughtworks beschreibt ihn als „best of both worlds“: Es gibt weniger bewegliche Teile, einfache Deployments und geringere Infrastrukturkosten, während eine klare Aufteilung in Module dennoch möglich ist. Durch die gemeinsame Deployment-Einheit entfallen Gateways, Service Discovery und verteiltes Logging. Das verbessert die Performance, da Module über Funktionsaufrufe statt über das Netzwerk kommunizieren und das System bei Ausfall eines Moduls nicht sofort fragmentiert. Gleichzeitig lassen sich klare Teamgrenzen und Domänen definieren, sodass Entwickler ein Modul später relativ leicht ausgliedern können.

Eine praktische Entscheidungshilfe in Tabellenform stellen die Architekturexperten hinter der Toolsuite Ptidej zur Verfügung. Microservices bieten Vorteile, wenn autonome Teams mit eigenen Releasezyklen an unterschiedlichen Teilen eines großen Systems arbeiten, wenn einzelne Komponenten sehr unterschiedlich skalieren oder wenn verschiedene Technologien notwendig sind. Ein Monolith hingegen genügt, wenn das Team überschaubar ist, die Domäne klar umrissen und die Skalierungsanforderungen homogen sind. Wichtig ist, dass das System modular bleibt, damit es sich bei Bedarf später in Microservices zerlegen lässt.

Der modulare Monolith bietet somit einen pragmatischen Mittelweg: Er teilt eine Anwendung in klar abgegrenzte Module, deployt sie aber gemeinsam. Im Python/Django-Umfeld ist das Prinzip seit Jahren gelebte Praxis („Apps“ als Modulgrenzen), auch wenn es dort nicht Modulith heißt.

Thoughtworks empfiehlt, mit einem solchen Monolithen zu starten und erst nach gründlichem Verständnis der Geschäftsprozesse einzelne Module auszulagern. Die Vorteile sind klar: einfache Deployments, gute Performance, niedrigere Betriebskosten und weniger Latenz.

Moderne Monorepo‑Werkzeuge senken die Reibung größerer Codebasen: Nx etwa bietet Computation Caching (lokal und remote) und „Affected“‑Mechaniken, sodass bei Änderungen nur die betroffenen Projekte gebaut und getestet werden. Das senkt Build‑ und CI‑Zeiten drastisch und macht ein Repo mit vielen Modulen praktikabel.

Interessant ist, dass Nx explizit dokumentiert, dass Micro‑Frontends vor allem dann empfehlenswert sind, wenn unabhängiges Deployment wirklich notwendig ist. Andernfalls lassen sich dieselben Build‑Effekte zunehmend auch ohne Micro-Frontend‑Architektur erzielen (etwa Module Federation nur zur Build‑Beschleunigung).

Aus Daten, Praxisberichten und Werkzeugtrends lassen sich pragmatische Leitlinien ableiten:

  1. Für die meisten kleinen bis mittleren Teams ist ein modularer Monolith der schnellste Weg zu Features und Feedback. Er reduziert Kosten, minimiert Betriebsrisiken und bleibt evaluierbar.
  2. Wenn Komponenten immer gemeinsam deployt werden müssen, ist die Anwendung monolithisch – unabhängig davon, auf wie viele Container oder Repos sie verteilt ist. Umgekehrt sind Microservices erst dann sinnvoll, wenn Deployments wirklich unabhängig sind.
  3. Verteilte Systeme erkauft man sich mit Betriebskosten: Observability, Versionierung, Backward Compatibility, Netzwerklatenz, CAP‑Trade‑offs (Abwägungen zwischen Konsistenz, Verfügbarkeit und Partitionstoleranz). Wer diese Reife nicht hat oder nicht braucht, verliert Zeit und Fokus aufs Produkt. Genau das zeigen Code‑Audits aus der Start‑up‑Praxis.
  4. Was in einem Konzern mit Dutzenden Teams sinnvoll ist, ist für ein Team mit zehn Leuten häufig Overkill. Architektur folgt Teamschnitt und Geschäftsprozess, nicht dem Blog‑Hype. Der Artikel auf Heise hat das am Prime‑Video‑Beispiel sorgfältig eingeordnet (Stichwort Modulith).
  5. Werden einzelne Module zu Engpässen (abweichender Release‑Rhythmus, stark abweichende Last, anderes Team), lassen sie sich sauber herauslösen. Ohne vorzeitige Zersplitterung bleibt die Komplexität beherrschbar.



Source link

Weiterlesen

Entwicklung & Code

Bestie statt for-Schleife: KI entwickelt Programmiersprache im Gen-Z-Slang


Damn, das ist cringe: Der Australier Geoffrey Huntley hat die Programmier-KI Claude Code von Anthropic drei Monate in Dauerschleife laufen lassen, um eine eigene Programmiersprache im Stile der verbreiteten Umgangssprache der Generation Z zu entwerfen. Und warum? Nun, weil er es kann, wie er in einem Blogpost darlegt.


WTF

WTF

Das Internet ist voll von heißen IT-News und abgestandenem Pr0n. Dazwischen finden sich auch immer wieder Perlen, die zu schade sind für /dev/null.

Tatsächlich habe ihn einfach die Möglichkeit gereizt, dass mithilfe generativer KI der Traum vom eigenen Compiler Gestalt annehmen kann, schreibt er. Das Ganze sei dann auch ein Lernexperiment gewesen. Der KI sei es dabei selbst überlassen worden, die Sprache jeweils weiter zu verbessern. Das Ergebnis hat er sogar auf einer eigenen Website zum Download bereitgestellt. Der Name der Programmiersprache: Cursed (auf deutsch: verflucht).

Der Compiler verfügt über zwei Modi. Er kann als Interpreter oder als Compiler eingesetzt werden und Binärdateien für macOS, Linux und Windows erstellen. Zudem gebe es halbfertige Erweiterungen für die Editoren VSCode, Emacs und Vim. Wer sich den Entstehungsprozess anschauen möchte, findet dazu entsprechende Videos bei YouTube.

Sprachlich darf man sich das so vorstellen, dass an die Stelle von bekannten Begriffen wie for oder case Wörter treten, die in der GenZ gerne benutzt werden, wie etwa bestie oder mood. Eine Roadmap zur Weiterentwicklung gebe es nicht, darüber soll die Community entscheiden.

Der ursprüngliche Prompt lautete: „Hey, kannst du mir eine Programmiersprache wie Golang erstellen, bei der jedoch alle lexikalischen Schlüsselwörter ausgetauscht sind, sodass sie dem Slang der Generation Z entsprechen?“

Wer dem Beispiel von Huntley folgen möchte, sollte allerdings das nötige Kleingeld bereithalten. Der eigene Compiler koste einen etwa 5000 US-Dollar, schreibt er in einem Post auf X. Tatsächlich habe er mit 14.000 US-Dollar fast das Dreifache investieren müssen, da Cursed zunächst in C, dann in Rust und jetzt in Zig entwickelt wurde. Aber so gebe es jetzt eben auch drei Editionen des Compilers. Und am Ende sei das nur ein Vierzehntel des Gehalts eines Entwicklers in San Francisco, scherzt er.


(mki)



Source link

Weiterlesen

Entwicklung & Code

MCP Registry gestartet: Katalog für MCP-Server


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

Das Entwicklungsteam hinter dem Model Context Protocol (MCP) hat die MCP Registry als Preview eingeführt – einen offenen Katalog und eine API, um öffentlich verfügbare MCP-Server ausfindig zu machen und zu verwenden. Bei MCP handelt es sich um ein offenes Protokoll für den Zugriff von Large Language Models (LLMs) auf externe Datenquellen.

Bereits vor einigen Monaten teilte das MCP-Team auf GitHub mit, an einem zentralen Register für das MCP-Ökosystem zu arbeiten. Die nun veröffentlichte, quelloffene MCP Registry soll das Verfahren standardisieren, wie MCP-Server verteilt und entdeckt werden. Sie bietet Server-Maintainern die Möglichkeit, ihre Server hinzuzufügen, und Client-Maintainern, auf Serverdaten zuzugreifen.

Um der Registry einen Server hinzuzufügen, muss dieser auf einer Package Registry wie npm, PyPI oder DockerHub veröffentlicht sein. Eine detaillierte Anleitung findet sich auf GitHub. Dort erfahren Developer, wie sie eine server.json-Datei für ihren Server erstellen, Authentifizierung mit der Registry erreichen, ihren Server veröffentlichen und die Veröffentlichung verifizieren können.

Wie das MCP-Team betont, soll das zentrale Register als hauptsächliche Source of Truth für öffentlich verfügbare MCP-Server dienen, jedoch den bereits bestehenden Registries von Community und Unternehmen nicht im Weg stehen. Diese können in der MCP Registry öffentliche oder private Sub-Registries anlegen, wie das MCP-Team auf GitHub beschreibt.

Bereits existierende Sammlungen sind etwa eine lange, gepflegte Liste auf GitHub und ein Docker-Verzeichnis für MCP-Quellen.

Da es sich bei der MCP Registry derzeit um eine Preview handelt, gibt es keine Garantie für die Beständigkeit der darin enthaltenen Daten. Auch sind Breaking Changes möglich, bevor die Registry die allgemeine Verfügbarkeit erreicht.

Weitere Informationen sind auf dem MCP-Blog zu finden.


(mai)



Source link

Weiterlesen

Beliebt