# ZUV 3 Wie entwerfen Sie Ihre Workload-Service-Architektur?
Erstellen Sie hoch skalierbare und zuverlässige Workloads mithilfe einer serviceorientierten Architektur (SOA) oder einer Microservices-Architektur. Eine serviceorientierte Architektur (SOA) hat zum Ziel, Softwarekomponenten über Service-Schnittstellen wiederverwendbar zu machen. Die Microservices-Architektur geht noch weiter, um Komponenten kleiner und einfacher zu machen.
**Topics**
+ [REL03-BP01 Segmentierung Ihres Workloads](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Entwickeln von Services, die sich auf bestimmte Geschäftsbereiche und Funktionen konzentrieren](rel_service_architecture_business_domains.md)
+ [REL03-BP03 Bereitstellen von Serviceverträgen pro API](rel_service_architecture_api_contracts.md)
# REL03-BP01 Segmentierung Ihres Workloads
Die Workload-Segmentierung ist wichtig, wenn es um die Festlegung der Resilienzanforderungen Ihrer Anwendung geht. Eine monolithische Architektur sollte vermieden werden, wann immer möglich. Stattdessen sollten Sie sorgfältig überlegen, welche Anwendungskomponenten in Microservices aufgeteilt werden können. Abhängig von den Anforderungen Ihrer Anwendung könnte es sich im Endergebnis um eine Kombination aus einer serviceorientierten Architektur (SOA) und Microservices handeln, wenn dies möglich ist. Workloads, die zustandslos sein können, können eher als Microservices bereitgestellt werden.
**Gewünschtes Ergebnis:** Workloads sollten unterstützbar, skalierbar und so lose miteinander verbunden sein wie möglich.
Wiegen Sie bei Entscheidungen zur Segmentierung von Workloads die Vorteile und die Komplexitäten miteinander ab. Was für ein neues Produkt richtig ist, das gerade auf dem Markt eingeführt wird, unterscheidet sich von den Anforderungen eines Workloads, der von Anfang an skalierbar sein muss. Bei einem Faktorwechsel für einen vorhandenen Monolith müssen Sie berücksichtigen, wie gut dieser aufgeteilt und in zustandslose Anwendungen transformiert werden kann. Die Aufteilung von Services in kleinere Teile ermöglicht kleinen, klar definierten Teams, diese weiterzuentwickeln und zu verwalten. Kleinere Services können jedoch Komplexitäten wie eine möglicherweise erhöhte Latenz, ein komplexeres Debugging und einen erhöhten operativen Aufwand einführen.
**Typische Anti-Muster:**
+ Der [Microservice *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) ist eine Situation, in der die einzelnen Komponenten so stark voneinander abhängig werden, dass der Ausfall einer einzigen Komponente einen wesentlich größeren Ausfall bewirkt. Das bedeutet, dass die Komponenten so starr und anfällig wie ein Monolith sind.
**Vorteile der Einrichtung dieser Best Practice:**
+ Spezifischere Segmente führen zu einer größeren Agilität, zu organisatorischer Flexibilität und zu Skalierbarkeit.
+ Die Auswirkungen von Service-Unterbrechungen werden reduziert.
+ Die einzelnen Komponenten einer Anwendung besitzen möglicherweise unterschiedliche Anforderungen an die Verfügbarkeit, die von einer stärkeren Segmentierung besser unterstützt werden können.
+ Die Verantwortlichkeiten der Teams, die den Workload unterstützen, sind klar definiert.
**Risikostufe bei fehlender Befolgung dieser Best Practice:** Hoch
## Implementierungsleitfaden
Wählen Sie Ihren Architekturtyp basierend auf der Segmentierung Ihres Workloads aus. Wählen Sie eine serviceorientierte Architektur (SOA) oder eine Microservices-Architektur aus. (In seltenen Fällen ist möglicherweise auch eine monolithische Architektur geeignet.) Auch wenn Sie mit einer monolithischen Architektur beginnen möchten, müssen Sie sicherstellen, dass diese modular ist und zu einer SOA oder zu Microservices weiterentwickeln werden kann, wenn Ihr Produkt aufgrund der zunehmenden Einführung durch Benutzer skaliert wird. SOA und Microservices ermöglichen eine kleinteiligere Segmentierung, die als moderne skalierbare und zuverlässige Architektur bevorzugt wird. Es gibt jedoch auch Nachteile, die besonders bei der Bereitstellung einer Microservice-Architektur berücksichtigt werden sollten.
Aufgrund ihrer verteilten Computing-Architektur kann es schwieriger sein, die Latenzanforderungen von Benutzern zu erfüllen. Außerdem sind das Debugging und die Nachverfolgung von Benutzerinteraktionen komplexer. Zur Lösung dieses Problems können Sie AWS X-Ray verwenden. Ein weiterer Effekt ist die erhöhte operative Komplexität, da die Anzahl der von Ihnen verwalteten Anwendungen zunimmt. In der Folge müssen Sie eine größere Zahl voneinander unabhängiger Komponenten bereitstellen.
![\[Diagramm mit einem Vergleich von monolithischen, serviceorientierten und Microservice-Architekturen\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/monolith-soa-microservices-comparison.png)
## Implementierungsschritte
+ Ermitteln Sie die richtige Architektur für den Faktorwechsel oder die Entwicklung Ihrer Anwendung. SOA und Microservices bieten eine jeweils kleinere Segmentierung, die als moderne skalierbare und zuverlässige Architektur bevorzugt wird. SOA kann ein guter Kompromiss für das Erreichen einer kleineren Segmentierung sein, während die Komplexität von Microservices zum Teil vermieden wird. Weitere Informationen finden Sie in [Kompromisse bei Microservices](https://martinfowler.com/articles/microservice-trade-offs.html).
+ Wenn Ihre Workload für sie zugänglich ist und Ihre Organisation sie unterstützen kann, sollten Sie eine Microservices-Architektur verwenden, um die beste Agilität und Zuverlässigkeit zu erzielen. Weitere Informationen finden Sie in [Implementieren von Microservices in AWS.](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Sie sollten das Muster mit der Bezeichnung [*Strangler Fig* („Würgefeige“) verwenden,](https://martinfowler.com/bliki/StranglerFigApplication.html) um einen Faktorwechsel für einen Monolithen durchzuführen, bei dem Sie diesen in kleinere Komponenten aufteilen. Dies umfasst die schrittweise Ersetzung spezifischer Anwendungskomponenten durch neue Anwendungen und Services. [AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) dient als Ausgangspunkt für den inkrementellen Faktorwechsel. Weitere Informationen finden Sie in [Nahtlose Integration ältere On-Premises-Workloads unter Anwendung eines Strangler-Fig-Musters](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/).
+ Die Implementierung von Microservices erfordert möglicherweise einen Mechanismus für die Entdeckung von Services, damit diese verteilten Services miteinander kommunizieren können. [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) kann mit serviceorientierten Architekturen verwendet werden, um eine zuverlässige Erkennung von Services und den Zugriff auf sie zu unterstützen. [AWS Cloud Map](https://aws.amazon.com/cloud-map/) kann für die dynamische, DNS-basierte Serviceerkennung verwendet werden.
+ Wenn Sie von einem Monolithen zur SOA migrieren, kann [Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) helfen, als Service-Bus die Lücke zu überbrücken, wenn Sie ältere Anwendungen in der Cloud neu entwerfen.
+ Im Fall vorhandener Monolithen mit einer einzigen, geteilten Datenbank müssen Sie entscheiden, wie Sie die Daten neu in kleineren Segmenten organisieren. Dabei kann es sich um Geschäftsbereiche, Zugriffsmuster oder Datenstrukturen handeln. An diesem Punkt des Faktorwechsel-Prozesses sollten Sie entscheiden, ob Sie eine relationale oder eine nicht relationale (NoSQL) Datenbank verwenden. Weitere Informationen finden Sie in [Von SQL zu NoSQL](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html).
**Aufwand für den Implementierungsplan:** Hoch
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [REL03-BP02 Entwickeln von Services, die sich auf bestimmte Geschäftsbereiche und Funktionen konzentrieren](rel_service_architecture_business_domains.md)
**Zugehörige Dokumente:**
+ [Amazon API Gateway: Konfigurieren einer REST-API mit OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Was ist eine serviceorientierte Architektur?](https://aws.amazon.com/what-is/service-oriented-architecture/)
+ [Bounded Context (Begrenzter Kontext) (ein zentrales Muster im domänengesteuerten Design)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implementieren von Microservices in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Kompromisse bei Microservices](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices – eine Definition dieses neuen Architekturbegriffs](https://www.martinfowler.com/articles/microservices.html)
+ [Microservices in AWS](https://aws.amazon.com/microservices/)
+ [Was ist AWS App Mesh?](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html)
**Zugehörige Beispiele:**
+ [Workshop für die iterative App-Modernisierung](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro)
**Zugehörige Videos:**
+ [Kompetenz mit Microservices in AWS](https://www.youtube.com/watch?v=otADkIyugzY)
# REL03-BP02 Entwickeln von Services, die sich auf bestimmte Geschäftsbereiche und Funktionen konzentrieren
Eine serviceorientierte Architektur (SOA) entwickelt Services mit genau abgegrenzten Funktionen, die von Geschäftsanforderungen definiert werden. Microservices verwenden Domänenmodelle und begrenzten Kontext, um dies weiter einzuschränken, sodass jeder Service nur eine Aufgabe erledigt. Wenn Sie sich auf bestimmte Funktionen konzentrieren, können Sie die Zuverlässigkeitsanforderungen verschiedener Services differenzieren und Investitionen genauer ausrichten. Ein präzises Geschäftsproblem und ein kleines Team, das mit jedem Service verbunden ist, ermöglichen auch eine einfachere Skalierung der Organisation.
Beim Entwerfen einer Microservice-Architektur ist es hilfreich, das Domain-Driven Design (DDD) zu verwenden, um das Geschäftsproblem mithilfe von Entitäten zu modellieren. Für die Website Amazon.com können Entitäten beispielsweise Pakete, Zustellung, Zeitplan, Preise, Rabatte und Währung enthalten. Anschließend wird das Modell mit [https://martinfowler.com/bliki/BoundedContext.html](https://martinfowler.com/bliki/BoundedContext.html)weiter in kleinere Modelle unterteilt, wobei Entities mit ähnlichen Funktionen und Attributen in Gruppen sortiert werden. Beim Beispiel des Amazon.com-Pakets wären Lieferung und Zeitplan Teil des Versandkontexts, während Preise, Rabatte und Währung Teil des Preiskontexts sind. Wenn das Modell in Kontexte unterteilt ist, entsteht eine Vorlage für die Begrenzung von Microservices.
![\[Modellvorlage für die Begrenzung von Microservices\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/building-services.png)
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
+ Entwerfen Sie Ihre Workload basierend auf Ihren Unternehmensdomänen und deren jeweiliger Funktionalität. Wenn Sie sich auf bestimmte Funktionen konzentrieren, können Sie die Zuverlässigkeitsanforderungen verschiedener Services differenzieren und Investitionen genauer ausrichten. Ein präzises Geschäftsproblem und ein kleines Team, das mit jedem Service verbunden ist, ermöglichen auch eine einfachere Skalierung der Organisation.
+ Führen Sie eine Domänenanalyse durch, um Ihrer Workload ein domänengesteuertes Design (DDD) zuzuordnen. Anschließend können Sie einen Architekturtyp auswählen, der die Anforderungen Ihrer Workload erfüllt.
+ [How to break a Monolith into Microservices (Aufschlüsseln eines Monolithen in Microservices)](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Getting Started with DDD when Surrounded by Legacy Systems (Erste Schritte mit DDD, wenn die Umgebung aus Legacy-Systemen besteht)](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [„Domain-Driven Design: Tackling Complexity in the Heart of Software“ von Eric Evans („Domänengesteuertes Design: Bewältigung der Komplexität im Herzen der Software“)](https://www.amazon.com/gp/product/0321125215)
+ [Implementieren von Microservices in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Zerlegen Sie Ihre Services in kleinstmögliche funktionale Einheiten. Mit der Microservices-Architektur können Sie Ihre Workload in Komponenten mit minimaler Funktionalität aufteilen, um Skalierung und Agilität der Organisation zu ermöglichen.
+ Definieren Sie die API für die Workload und ihre Designziele, Limits und sonstigen Nutzungsanforderungen.
+ Definieren Sie die API.
+ Lassen Sie in der API-Definition Raum für Wachstum und weitere Parameter.
+ Definieren Sie die gewünschten Verfügbarkeiten.
+ Sie können für Ihre API mehrere Designziele für unterschiedliche Funktionen haben.
+ Limits festlegen
+ Definieren Sie mithilfe von Tests die Limits Ihrer Workload-Funktionen.
## Ressourcen
**Relevante Dokumente:**
+ [Amazon API Gateway: Konfigurieren einer REST-API mit OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Bounded Context (Begrenzter Kontext) (ein zentrales Muster im domänengesteuerten Design)](https://martinfowler.com/bliki/BoundedContext.html)
+ [„Domain-Driven Design: Tackling Complexity in the Heart of Software“ von Eric Evans („Domänengesteuertes Design: Bewältigung der Komplexität im Herzen der Software“)](https://www.amazon.com/gp/product/0321125215)
+ [Getting Started with DDD when Surrounded by Legacy Systems (Erste Schritte mit DDD, wenn die Umgebung aus Legacy-Systemen besteht)](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [How to break a Monolith into Microservices (Aufschlüsseln eines Monolithen in Microservices)](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Implementieren von Microservices in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Kompromisse bei Microservices](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices – eine Definition dieses neuen Architekturbegriffs](https://www.martinfowler.com/articles/microservices.html)
+ [Microservices in AWS](https://aws.amazon.com/microservices/)
# REL03-BP03 Bereitstellen von Serviceverträgen pro API
Serviceverträge sind dokumentierte Vereinbarungen zur Service-Integration zwischen Teams und enthalten eine maschinenlesbare API-Definition, Ratenlimits und Leistungserwartungen. Eine Versionsverwaltungs-Strategie ermöglicht es Ihren Clients, die vorhandene API weiter zu verwenden und ihre Anwendungen auf die neuere API zu migrieren, wenn sie bereit sind. Die Bereitstellung kann jederzeit erfolgen, solange der Vertrag nicht verletzt wird. Das Serviceanbieterteam kann den Technologie-Stack seiner Wahl verwenden, um den API-Vertrag zu erfüllen. Ebenso kann der Service-Verbraucher seine eigene Technologie verwenden.
Microservices nutzen das Konzept einer serviceorientierten Architektur (SOA) und erstellen Services mit minimalem Funktionsumfang. Jeder Service veröffentlicht eine API und Designziele, Limits und andere Überlegungen zur Nutzung des Services. Damit entsteht ein *Vertrag* mit aufrufenden Anwendungen. Dies bietet die folgenden drei Vorteile:
+ Der Service muss eine Lösung für ein konkretes Geschäftsproblem bieten und verfügt über ein kleines Team, das Eigentümer des Geschäftsproblems ist. Dieser Ansatz ermöglicht eine bessere unternehmerische Skalierung.
+ Das Team kann jederzeit Bereitstellungen durchführen, solange es seine API- und weitere vertragsbasierte Anforderungen erfüllt.
+ Das Team kann einen beliebigen Technologie-Stack verwenden, solange es seine API- und weitere vertragsbasierte Anforderungen erfüllt.
Amazon API Gateway ist ein vollständig verwalteter Service, der es Entwicklern erleichtert, APIs in jeder Größenordnung zu erstellen, zu veröffentlichen, zu warten, zu überwachen und zu sichern. API Gateway übernimmt alle Aufgaben, die mit der Annahme und Verarbeitung von mitunter Hunderttausenden gleichzeitigen API-Aufrufen verbunden sind. Hierzu zählen die Verwaltung des Datenverkehrs, die Autorisierung, die Zugriffskontrolle, die Überwachung sowie die API-Versionsverwaltung. Mit der OpenAPI-Spezifikation (OAS), früher als Swagger-Spezifikation bezeichnet, können Sie Ihren API-Vertrag definieren und in API Gateway importieren. Mit API Gateway können Sie die APIs versionieren und bereitstellen.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Niedrig
## Implementierungsleitfaden
+ Stellen Sie Serviceverträge pro API bereit. Serviceverträge sind dokumentierte Vereinbarungen zur Service-Integration zwischen Teams und enthalten eine maschinenlesbare API-Definition, Ratenlimits und Leistungserwartungen.
+ [Amazon API Gateway: Konfigurieren einer REST-API mit OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ Eine Versioning-Strategie ermöglicht es Clients, die vorhandene API weiter zu verwenden und ihre Anwendungen auf die neuere API zu migrieren, wenn sie bereit sind.
+ Amazon API Gateway ist ein vollständig verwalteter Service, der es Entwicklern leicht macht, APIs beliebiger Größe zu erstellen. Mit der OpenAPI-Spezifikation (OAS), früher als Swagger-Spezifikation bezeichnet, können Sie Ihren API-Vertrag definieren und in API Gateway importieren. Mit API Gateway können Sie die APIs versionieren und bereitstellen.
## Ressourcen
**Relevante Dokumente:**
+ [Amazon API Gateway: Konfigurieren einer REST-API mit OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Bounded Context (Begrenzter Kontext) (ein zentrales Muster im domänengesteuerten Design)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implementieren von Microservices in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Kompromisse bei Microservices](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices – eine Definition dieses neuen Architekturbegriffs](https://www.martinfowler.com/articles/microservices.html)
+ [Microservices in AWS](https://aws.amazon.com/microservices/)