Software-Architektur
Zwei Wege, eine Anwendung zu bauen – und warum keiner davon „der richtige" ist.
Basierend auf: freeCodeCamp – „Microservices vs. Monoliths Explained" · Pfeiltasten zum Blättern →
Interaktiv · 02
Unser Beispiel aus dem Artikel: ein Online-Shop mit vier Aufgaben – Produktsuche, Bezahlung, Bestellungen, Empfehlungen.
▶ Schalte um und schau, wie sich dieselbe App verändert
▼ eine gemeinsame Datenbank
▲ reden über APIs & Message Queues miteinander
Ein Codebase, ein Deployment. Alles lebt zusammen in einem Repository und wird als eine Einheit ausgeliefert. Alle Features laufen auf gemeinsamer Infrastruktur.
Viele kleine Services, geschnitten nach Fachgebiet. Jeder hat eigenen Code und eigene Datenbank und kann für sich gebaut, getestet und ausgeliefert werden.
Analogie · 03
So erklärt es der Artikel – und so merkt es sich die Klasse am leichtesten:
Eine Küche, eine Speisekarte. Alle Gerichte kommen aus derselben Küche – alles ist aufeinander abgestimmt, alles hängt zusammen. Willst du ein Gericht ändern, betrifft es die ganze Küche.
Viele spezialisierte Stände – Pizza, Sushi, Burger. Jeder hat eigene Küche, eigene Karte, eigenes Team. Jeder Stand kann für sich umbauen, vergrößern oder schließen.
Behalte das Bild im Kopf – die nächsten vier Demos spielen alle in dieser Küche bzw. diesem Food-Court.
Demo 1 · Ausfallsicherheit · 04
▶ Klick einen Service kaputt und vergleiche beide Welten
Monolith – die eine Küche
✓ Alles läuft
Microservices – der Food-Court
✓ Alles läuft
Merksatz: Im Monolithen reißt ein Fehler alles mit. Bei Microservices schließt nur ein Stand – der Rest des Food-Courts verkauft weiter.
Demo 2 · Skalierung · 05
▶ Starte den Sale und vergleiche, was hochgefahren werden muss
Monolith – ganze App klonen
Laufende Feature-Instanzen: 4
Microservices – nur Bezahlung klonen
Laufende Feature-Instanzen: 4
Auch ein Monolith kann skalieren: Man kopiert die ganze App auf mehrere Server und verteilt die Anfragen per Load Balancer. Aber jede Kopie fährt alle Features mit hoch. Microservices skalieren nur das, was gebraucht wird – das spart Server und Geld.
Demo 3 · Deployment · 06
▶ Deploye den Fix und schau, wie viel jeweils angefasst wird
Monolith – alles neu ausliefern
Bereit
Microservices – nur den einen Service
Bereit
Beim Monolithen wird für eine Zeile Änderung die ganze App neu gebaut, getestet und ausgerollt – und alle Features tragen das Risiko. Bei Microservices fasst du nur den einen Service an.
Demo 4 · Kommunikation · 07
Getrennte Services müssen sich abstimmen. Dafür gibt es zwei Arten – wie ein Telefonanruf oder ein Briefkasten.
▶ Wechsle den Modus und leg dann den Bezahl-Service lahm
Telefonanruf: Bestellungen ruft an und wartet in der Leitung, bis Bezahlung antwortet. Einfach – aber eng gekoppelt.
Kein Service greift direkt in die Datenbank eines anderen – nur über dessen API. So kann ein Team sein Schema ändern, ohne andere zu brechen.
Zwischenstand · 08
Jede Bauweise gewinnt in anderen Disziplinen – genau das sagt der Artikel: Es ist ein Trade-off, kein Duell mit klarem Sieger.
| Disziplin | Punkt geht an | Warum |
|---|---|---|
| Einfachheit | Monolith | Kein verteiltes System: keine Netzwerk-Latenz, keine verteilte Datenkonsistenz. |
| Schnell iterieren | Monolith | Eine Codebasis – ideal, solange sich das Produkt noch ständig ändert. |
| Kosten am Anfang | Monolith | Weniger Infrastruktur, weniger Betrieb, weniger Leute nötig. |
| Ausfallsicherheit | Microservices | Demo 1: Ein kaputter Service reißt nicht alles mit. |
| Gezielt skalieren | Microservices | Demo 2: Nur die Bezahlung hochfahren, nicht den ganzen Shop. |
| Unabhängig deployen | Microservices | Demo 3: Ein Bugfix fasst nur einen Service an. |
| Freie Tech-Wahl | Microservices | Jedes Team wählt Sprache und Datenbank passend zu seinem Service. |
Interaktiv · 09
▶ Hakt an, was auf euer (fiktives) Team zutrifft – die Empfehlung passt sich live an
Mittelweg · 10
Man muss sich nicht ganz entscheiden. Der Artikel schlägt vor: Ähnliches zusammenfassen, Spezielles herauslösen.
gleiche Technologie → ein Monolith
Spezialfälle → eigene Services
So bekommt man die Einfachheit des Monolithen dort, wo sie reicht – und die Freiheit der Microservices nur dort, wo sie wirklich gebraucht wird.
Fazit · 11
profitieren vom Monolithen: schneller lernen, weniger bezahlen, einfacher umbauen.
mit echten Skalierungs-Anforderungen profitieren von Flexibilität und Resilienz der Microservices.
Netflix, Uber und Etsy starteten alle als Monolith – und migrierten erst zu Microservices, als sie die Probleme wirklich hatten.
Quelle: freecodecamp.org/news/microservices-vs-monoliths-explained