- Ein Artikel über die Kosten und Vorteile des Wechsels von einem einzelnen Backend zu einer Microservices-Architektur
- Mit der wachsenden Zahl von Teams, die zu einer einzigen Codebasis beitragen, werden Komponenten zunehmend stärker gekoppelt, die Produktivität sinkt und die Komplexität steigt
- Eine Möglichkeit, diese Probleme zu entschärfen, besteht darin, ein einzelnes Backend in eine Reihe unabhängig deploybarer Services aufzuteilen, die über APIs kommunizieren – also in Microservices
- Der Begriff „Micro“ ist irreführend, da Services nicht „mikro“ sein müssen. Ein passenderer Begriff wäre serviceorientierte Architektur
- Wenn ein Backend in eine Reihe von Services mit klar definierten Grenzen zerlegt wird, reicht für die Entwicklung und den Betrieb jedes Services ein kleines Team aus, wodurch sich die Entwicklungsgeschwindigkeit der Anwendung erhöht
- Jeder Microservice kann unabhängig skaliert werden und je nach eigenem Bedarf einen anderen Technologie-Stack nutzen, was Experimente und die Evaluierung neuer Technologien erleichtert
- Allerdings erhöht eine Microservices-Architektur die Komplexität, weil sie dem Gesamtsystem mehr bewegliche Teile hinzufügt, und sie erfordert ein gewisses Maß an Standardisierung
- Wenn für jeden Microservice andere Sprachen, Bibliotheken und Datastores verwendet werden, kann das in unübersichtliches Chaos umschlagen, das die Wartung der Anwendung erschwert und es für Entwickler schwierig macht, zwischen Teams zu wechseln
- Um eine große Zahl unabhängiger Services zu unterstützen, müssen neue Server, Datastores und andere Ressourcen leicht bereitgestellt werden können, was erhebliche Automatisierung erfordert
- Remote-Aufrufe sind kostspielig und führen neue Fehlermöglichkeiten in das System ein, daher sind Schutzmechanismen wie Timeouts, Retries und Circuit Breaker erforderlich
- Continuous Integration stellt sicher, dass Codeänderungen einen automatischen Build- und Testprozess durchlaufen, bevor sie in den Main-Branch gemergt werden
- Integrationstests für alle Microservices sind deutlich schwieriger als Tests eines Monolithen, da bei der Interaktion einzelner Services sehr subtile und unerwartete Verhaltensweisen auftreten können
- Teams, die Services entwickeln, sind in der Regel auch für deren Bereitschaftsdienst zuständig, was Reibung zwischen Entwicklungsarbeit und Betriebskosten erzeugt
- Das Debugging von Systemausfällen wird mit Microservices schwieriger; gutes Logging und Monitoring auf allen Ebenen ist entscheidend
- Wenn eine Anwendung in separate Services aufgeteilt wird, existiert das Datenmodell nicht mehr in einem einzigen Datastore, sodass man in der Regel Eventual Consistency akzeptieren muss
- Im Allgemeinen ist es am besten, mit einem Monolithen zu beginnen und nur dann aufzuteilen, wenn es schwierig wird, die Grenzen zwischen Services sauber zu ziehen
- Ein Microservices-First-Ansatz sollte nur dann gewählt werden, wenn bereits Erfahrung damit vorhanden ist und eine passende Plattform existiert oder der Zeitaufwand für deren Aufbau berücksichtigt wurde
Noch keine Kommentare.