Service pro Teammuster - AWS Präskriptive Leitlinien

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Service pro Teammuster

Anstatt Monolithen nach Geschäftsfunktionen oder Services zu zerlegen, unterteilt das Service-per-Team-Muster sie in Microservices, die von einzelnen Teams verwaltet werden. Jedes Team ist für eine Geschäftsfähigkeit verantwortlich und besitzt die Codebasis der Fähigkeit. Das Team entwickelt, testet, implementiert oder skaliert seine Dienste unabhängig und interagiert hauptsächlich mit anderen Teams, um APIs auszuhandeln. Wir empfehlen, dass Sie jeden Microservice einem einzelnen Team zuweisen. Wenn das Team jedoch groß genug ist, könnten mehrere Unterteams separate Microservices innerhalb derselben Teamstruktur besitzen. Die folgende Tabelle erklärt die Vor- und Nachteile der Verwendung dieses Musters.

Vorteile Nachteile

  • Teams agieren unabhängig und mit minimaler Koordination.

  • Codebasen und Microservices werden nicht von mehreren Teams gemeinsam genutzt.

  • Teams können schnell Innovationen entwickeln und Produktmerkmale verbessern.

  • Verschiedene Teams können unterschiedliche Technologien, Frameworks oder Programmiersprachen verwenden. Wichtig: Diese sollten hinter einer klar definierten und stabilen öffentlichen API versteckt sein.

  • Es kann schwierig sein, Teams auf die Funktionen der Endbenutzer oder die Geschäftsfähigkeiten auszurichten.

  • Zusätzliche Anstrengungen sind erforderlich, um größere, koordinierte Anwendungsinkremente bereitzustellen, insbesondere wenn zirkuläre Abhängigkeiten zwischen den Teams bestehen.

Die folgende Abbildung zeigt, wie ein Monolith in Microservices aufgeteilt werden kann, die von einzelnen Teams verwaltet, gewartet und bereitgestellt werden.

Teams zerlegen Monolithen in Microservices