Microservices oder Monolith – was eignet sich besser für mein Studienprojekt?

Hallo Daniel, dein Bauchgefühl trügt dich hier nicht. Ich würde die Entscheidung für euer Projekt über die klassischen Treiber für Microservices begründen, die in der Literatur (z. B. bei Fowler) genannt werden: unabhängige Skalierbarkeit einzelner Komponenten, getrennte Deployment-Zyklen, Teams, die parallel und eigenständig an Services arbeiten, und organisatorische Entkopplung nach Conway's Law. Wenn keiner dieser Punkte bei dir zutrifft, kannst du das in der Begründung auch genau so argumentieren: nicht "Microservices sind too much", sondern "die Voraussetzungen, unter denen Microservices ihren Mehrwert entfalten, liegen hier nicht vor".

Der modulare Monolith ist tatsächlich ein sehr guter Mittelweg für eine Projektarbeit, weil er dir erlaubt, fachliche Bereiche sauber per Modulgrenzen (z. B. getrennte Packages/Namespaces, klar definierte Schnittstellen zwischen den Modulen, eigene Datenhaltung pro Modul wenn gewünscht) zu trennen, ohne den Overhead von Netzwerkkommunikation, verteilten Transaktionen oder Service-Discovery. Das lässt sich auch didaktisch gut verkaufen: du zeigst, dass du die Prinzipien von Domain-Driven Design und lose Kopplung verstanden hast, aber auch, dass du die Architektur passend zum Kontext (Teamgröße, Projektumfang, Zeitrahmen) wählst statt blind dem Trend zu folgen. Genau diese Abwägung ist meist das, was in der Bewertung positiv auffällt, weil sie zeigt, dass du nicht nur Buzzwords anwenden, sondern Architekturentscheidungen begründen kannst.

Kann mich Anna nur anschließen, und aus der Praxis-Ecke (BWL/IT-Schnittstelle) kommt da noch ein Argument dazu: bei Microservices zahlst du massiv Infrastruktur-Overhead drauf, den du bei 3-4 Bereichen nie wieder reinholst. Du brauchst dann ja plötzlich API-Gateway, evtl. Message Broker für async Kommunikation, mehrere Datenbanken, Container-Orchestrierung, verteiltes Logging/Tracing – und das alles, um am Ende Dinge zu debuggen, die in einem Monolithen ein simpler Funktionsaufruf wären.

Für ein Ein-Personen-Projekt würde ich da ganz klar zum (modularen) Monolithen raten. Merksatz, den ich mir dafür gemerkt habe: "Start with a monolith, split when you feel the pain" – die Pain-Points (Skalierung einzelner Teile, getrennte Teams, unterschiedliche Deployment-Zyklen) entstehen bei dir schlicht nicht.

Typischer Fehler in solchen Projektarbeiten: Leute bauen Microservices, kommunizieren dann aber doch wieder synchron per REST zwischen allen Services wie in einem Monolithen – nur jetzt über Netzwerk, mit allen Nachteilen (Latenz, Fehleranfälligkeit) und keinem der Vorteile (keine echte Entkopplung, kein unabhängiges Deployment, weil ja eh alles zusammen released wird).

Dein modularer Monolith mit klar getrennten Modulen pro fachlichem Bereich (Nutzerverwaltung, Bestellung, Produktkatalog) und sauberen Interfaces dazwischen ist genau der richtige Reifegrad. Du kannst in der Doku sogar erwähnen, dass diese Struktur bei Bedarf später relativ leicht in echte Microservices überführt werden könnte – das zeigt Weitblick, ohne dass du es jetzt schon umsetzen musst.

Daniel, dem kann ich mich anschließen, und ich kenne genau diese Überlegung noch aus meinem eigenen Projekt. Ein Aspekt, der in der Diskussion hier noch etwas kurz kam: der Deployment-Aufwand lässt sich sehr gut quantitativ in der Hausarbeit argumentieren, nicht nur qualitativ.

Ich würde in der Arbeit kurz skizzieren, was ein produktiver Betrieb deiner 3-4 Microservices tatsächlich bedeuten würde: jeder Service braucht ein eigenes Deployment-Artefakt, eine eigene Pipeline-Konfiguration, eigene Health-Checks, eigene Versionierung der Schnittstellen. Dazu kommt Betriebsverantwortung, die bei dir als Einzelperson ja komplett auf dich fällt – es gibt niemanden, der parallel einen anderen Service betreut. Das lässt sich schön als Argument formulieren: der organisatorische Nutzen von Microservices (parallele, unabhängige Teams) entsteht erst, wenn tatsächlich mehrere Personen unabhängig deployen. Bei einer Person fällt dieser Vorteil komplett weg, der Aufwand bleibt aber bestehen.

Merksatz, den ich mir dafür notiert habe: Microservices verschieben Komplexität von innerhalb des Codes nach außen in die Infrastruktur – das lohnt sich nur, wenn du diese Infrastruktur-Komplexität auch wirklich brauchst, sonst zahlst du nur drauf. Für die Bewertung ist es meiner Erfahrung nach überzeugender, wenn du diese Kosten-Nutzen-Abwägung explizit machst, statt die Architektur einfach zu setzen.