Microservices vs. Monolith: Die richtige Architekturentscheidung treffen

72 % der Unternehmen, die Microservices vorzeitig eingeführt haben, berichten von erhöhter Komplexität ohne proportionale Vorteile. Der Microservices-Hype hat viele Teams dazu veranlasst, ihre Anwendungen auf Dutzende von Services zu verteilen, obwohl ihnen ein gut strukturierter Monolith besser, schneller und kostengünstiger geholfen hätte.

Dieser Leitfaden bietet einen ehrlichen Rahmen für die Wahl zwischen monolithischen und Microservices-Architekturen, einschließlich der Hybridansätze, die für wachsende Unternehmen oft am sinnvollsten sind.

Wichtige Erkenntnisse

– Beginnen Sie mit einem Monolithen, es sei denn, Sie haben einen spezifischen, nachgewiesenen Bedarf an unabhängiger Skalierung oder Bereitstellung

• Die Teamgröße ist der stärkste Indikator für den Erfolg von Microservices: mindestens 3 Ingenieure pro Service – Das „modulare Monolith“-Muster bietet die meisten Microservices-Vorteile ohne betrieblichen Overhead – Die Migration von Monolithen zu Mikrodiensten sollte inkrementell erfolgen und jeweils einen Dienst extrahieren

---

Der ehrliche Vergleich

Monolith-Vorteile

Vorteile von Microservices

Microservices-Kosten (oft unterschätzt)

---

Der Entscheidungsrahmen

Entscheidung nach Teamgröße

Entscheidung durch Skalierung der Bedürfnisse

Entscheidung nach Bereitstellungsanforderungen

---

Der modulare Monolith: Das Beste aus beiden Welten

Ein modularer Monolith organisiert Code in gut abgegrenzten Modulen innerhalb einer einzigen einsetzbaren Einheit. Module kommunizieren über definierte Schnittstellen, nicht über direkten Datenbankzugriff.

Architektur

Single Deployment Unit
+---------------------------------------------------+
|  [Orders Module]  [Inventory Module]  [Users Module] |
|       |                  |                 |        |
|       +------ Internal API Layer ----------+        |
|       |                  |                 |        |
|  [Orders DB]   [Inventory DB]    [Users DB]          |
|       |                  |                 |        |
|       +------ Shared Database Server ------+        |
+---------------------------------------------------+

Modulares Monolithmuster von NestJS

// orders/orders.module.ts
@Module({
  imports: [
    InventoryModule, // Explicit dependency declaration
    UsersModule,
  ],
  controllers: [OrdersController],
  providers: [OrdersService],
  exports: [OrdersService], // Controlled public interface
})
export class OrdersModule {}

// inventory/inventory.module.ts
@Module({
  controllers: [InventoryController],
  providers: [InventoryService],
  exports: [InventoryService], // Only expose what others need
})
export class InventoryModule {}

Modulregeln:

1. Module kommunizieren über exportierte Dienste, niemals über direkten Datenbankzugriff
2. Jedes Modul besitzt ausschließlich seine Datenbanktabellen
3. Der Zugriff auf freigegebene Daten erfolgt über Servicemethoden und nicht über JOINs über Modulgrenzen hinweg
4. Modulabhängigkeiten sind im Array imports explizit

Wann ein Modul in einen Dienst extrahiert werden soll

Extrahieren, wenn:

• Das Modul muss unabhängig skalierbar sein (z. B. Bildverarbeitung, Suche)
• Die Einsatzhäufigkeit des Moduls unterscheidet sich erheblich vom Rest
• Das Modul wird von einem separaten Team betreut
• Das Modul hat unterschiedliche Technologieanforderungen (z. B. ML-Modell in Python)

NICHT extrahieren, wenn:

• „Es scheint, als ob es ein Dienst sein sollte“
• Sie möchten eine sauberere Architektur (stattdessen den Monolithen umgestalten)
• Sie haben keinen spezifischen Skalierungs- oder Bereitstellungsbedarf identifiziert

---

Migrationsstrategie: Monolith zu Microservices

Das Strangler-Feigen-Muster

Ersetzen Sie die monolithische Funktionalität schrittweise durch Microservices und leiten Sie den Datenverkehr an den neuen Dienst weiter, während der alte Code als Fallback verbleibt.

Schritt 1: Identifizieren Sie den Extraktionskandidaten (höchster Skalierungsbedarf oder größter Reibungsverlust bei der Bereitstellung).

Schritt 2: Erstellen Sie den neuen Dienst neben dem Monolithen

Schritt 3: Leiten Sie den Datenverkehr über das API-Gateway an den neuen Dienst weiter

Schritt 4: Überprüfen Sie die Richtigkeit, indem Sie beide parallel ausführen

Schritt 5: Entfernen Sie den alten Code vom Monolithen

Überlegungen zur Datenmigration

Empfehlung: Beginnen Sie während der Migration mit einer gemeinsam genutzten Datenbank und wechseln Sie dann zu einer Datenbank pro Dienst, sobald die Dienstgrenzen nachgewiesen sind.

---

Architekturbeispiele aus der Praxis

E-Commerce-Plattform

Modular Monolith (recommended for most):
- Product catalog module
- Cart and checkout module
- Order management module
- User accounts module
- Inventory module
All in one deployable unit, backed by one PostgreSQL instance.

Selective Microservices (for high-traffic stores):
- Search service (Elasticsearch, scales independently)
- Image processing service (CPU-intensive, different scaling)
- Payment service (PCI compliance boundary)
Everything else stays in the monolith.

ERP-System (Odoo-Stil)

Monolith is the correct choice for ERP:
- Deep cross-module data relationships
- Complex business rules spanning modules
- Consistent reporting across all data
- Smaller concurrent user counts
- Transactional consistency critical

Odoo itself is a modular monolith: modules are installed/uninstalled,
but everything runs in one process with one database.

---

Häufig gestellte Fragen

Hält uns unser Monolith zurück?

Wahrscheinlich nicht, es sei denn, Sie haben Hinweise auf konkrete Engpässe. Wenn die Bereitstellung langsam ist, investieren Sie in CI/CD. Wenn eine Komponente skaliert werden muss, extrahieren Sie sie. Wenn Teams aufeinander treten, setzen Sie Modulgrenzen durch. Bei den meisten „monolithischen Problemen“ handelt es sich tatsächlich um Code-Organisationsprobleme, die Microservices nicht lösen würden – sie würden sie einfach verteilen.

Wie viele Microservices sind zu viele?

Eine praktische Grenze: nicht mehr als 3–5 Dienste pro Ingenieur, der für den Betrieb verantwortlich ist. Ein Team von 5 Ingenieuren sollte nicht mehr als 15–25 Dienste besitzen. Darüber hinaus dominiert der betriebliche Overhead und die technische Geschwindigkeit sinkt. Viele erfolgreiche Unternehmen betreiben fünf bis zehn klar definierte Dienste anstelle von Hunderten von Nanodiensten.

Können wir unterschiedliche Datenbanken für unterschiedliche Module in einem Monolithen verwenden?

Ja, das ist der modulare Monolith-Ansatz. Jedes Modul kann ein separates Schema oder sogar eine separate Datenbankinstanz innerhalb derselben bereitstellbaren Einheit verwenden. Dadurch werden die Grenzen des Dateneigentums gewahrt, ohne dass die Betriebskosten für separate Dienste anfallen. Es erleichtert auch die spätere Extraktion.

Wie geht ECOSIRE dies für Kunden an?

Für die meisten Kunden empfehlen wir, mit einem modularen Monolithen zu beginnen. Unsere Odoo-Implementierungsdienste nutzen die modulare Architektur von Odoo und unsere benutzerdefinierten Entwicklungsprojekte folgen dem modularen Monolithmuster von NestJS. Wir extrahieren Dienste nur, wenn nachweislich Bedarf an unabhängiger Skalierung besteht – typischerweise Suche, Dateiverarbeitung oder externe Integrationen. Die vollständige Architekturphilosophie finden Sie in unserem DevOps-Leitfaden.

---

Was als nächstes kommt

Architekturentscheidungen sind grundlegend. Sobald Sie sich für Ihren Ansatz entschieden haben, investieren Sie in CI/CD-Automatisierung für eine zuverlässige Bereitstellung, Überwachung für betriebliche Transparenz und API-Gateway-Muster für die Verwaltung der Service-to-Service-Kommunikation.

Kontaktieren Sie ECOSIRE für Architekturberatung oder erkunden Sie unsere Odoo-Implementierungsdienste für eine ERP-Architektur, die mit Ihrem Unternehmen skaliert.

---

Herausgegeben von ECOSIRE – hilft Unternehmen bei der Auswahl der richtigen Architektur für ihre Wachstumsphase.