Technologie-Vergleich Microservices
Wir vergleichen für Sie vier wichtige Arten von Microservice-Architekturen. Alle versuchen eine hohe Kohäsion und geringe Kopplung in der Systemlandschaft zu erreichen. Jeder Ansatz verwendet dabei ein unterschiedliches Maß an Granularität und verschiedene Techniken.

Eine solide Softwarearchitektur ist das Fundament für den langfristigen Erfolg. Bei ConSol entwickeln wir maßgeschneiderte Lösungen für Ihren Anwendungsfall aus einem breitgefächerten Technologie-Stack, um Ihre Software zukunftssicher und leistungsstark zu gestalten – für die Herausforderungen von heute und morgen.
Christoph Ehlers
Head of Custom IT Solutions
µSOA | SCS (Self-Contained System) | DDDD (Distributed Domain-driven Design | FaaS (Function as a Service) | |
---|---|---|---|---|
Größe | Sehr klein | Mittel, besteht ggf. aus mehreren kleineren Microservices, unabhängiges System (einschließlich Datenhaltung und UI) | Klein | So klein wie möglich (wenige hundert Zeilen), Definition des Interfaces zuerst, nur möglich, wenn Dekomposition erreichbar |
Abgrenzung | Eine Aufgabe (innerhalb einer Domäne) | Eine Domäne | Ein Bounded Context / eine Domäne | Eine Funktion |
Unabhängigkeit | Unabhängige Entwicklung der Aufgaben | Unabhängige Entwicklung der Domänen | Unabhängige Entwicklung der Bounded Contexts / Domänen | Unabhängige Entwicklung der Funktionen |
Kommunikation | Viel synchrone Kommunikation (REST), Resilienz für Aufrufe (z.B. Hystrix), oft kombiniert mit Streaming (z.B. Apache Kafka) | Leichtgewichtige Integration (idealerweise über UI), kann unabhängig Requests beantworten, asynchrone Kommunikation mit anderen Systemen (wenn nötig) | Asynchrone Kommunikation (für bessere Stabilität), fachliche Events, redundante Datenhaltung (CQRS) | Asynchrone Kommunikation, Event-basiert |
Kopplung | Orchestrierung für gemeinsames Ziel | Schwache Kopplung der Domänen | Bounded Context (abgegrenzter Kontext), Ubiquitous Language (gemeinsame Sprache), schwache Kopplung der Kontexte | Zusammenarbeit für gemeinsames Ziel, gemeinsame Interfaces, emergentes Verhalten |
Team | 2-3 Personen pro Microservice | 1 Scrum Team pro SCS als Haupt-Team (aber ggf. auch mehrere Scrum-Teams für verschiedene Microservices mit skaliertem Scrum / Nexus) | 1 Scrum-Team pro System | 1-2 Personen pro Funktion |
Infrastruktur | Gemeinsame Infrastruktur | Keine besondere Infrastruktur nötig | Gemeinsame Infrastruktur für fachliche Events | Abhängigkeit von gemeinsamer Infrastruktur |
Skalierbarkeit | Bei sehr hohen Skalierbarkeitsanforderungen | Gute Skalierbarkeit | Gute Skalierbarkeit | Bei extremen Skalierbarkeitsanforderungen |
Infrastruktur | Netflix, X (Twitter) | Amazon, Otto.de, Galeria Kaufhof | Serverlose Architektur, AWS Lambda, Azure Functions |
Profitieren Sie von unserer Expertise
Noch Fragen zu unserem Microservices Technologie-Vergleich?

Lassen Sie uns sprechen!
Thomas Machata