SaaS Lens AWS Well-Architected Framework
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
SaaS Lens AWS Well-Architected Framework
SaaS Lens AWS Well-Architected Framework SaaS Lens: AWS Well-Architected Framework Copyright © Amazon Web Services, Inc. and/or its affiliates. All rights reserved. Amazon's trademarks and trade dress may not be used in connection with any product or service that is not Amazon's, in any manner that is likely to cause confusion among customers, or in any manner that disparages or discredits Amazon. All other trademarks not owned by Amazon are the property of their respective owners, who may or may not be affiliated with, connected to, or sponsored by Amazon.
SaaS Lens AWS Well-Architected Framework
Table of Contents
Überblick ........................................................................................................................................... 1
Überblick ................................................................................................................................... 1
Einführung ......................................................................................................................................... 2
Definitionen ........................................................................................................................................ 3
Mandant .................................................................................................................................... 3
Silo-, Pool- und Brückenmodelle ................................................................................................... 3
SaaS-Identität ............................................................................................................................ 4
Mandantenisolation ..................................................................................................................... 4
Datenpartitionierung .................................................................................................................... 5
„Noisy Neighbor“ ........................................................................................................................ 5
Mandanten-Onboarding ............................................................................................................... 5
Mandantenstufen ........................................................................................................................ 5
Mandantenaktivität und -verbrauch ................................................................................................ 5
Messung und Abrechnung ................................................................................................... 6
Mandantenbewusste Vorgänge ..................................................................................................... 6
Allgemeine konzeptionelle Grundsätze ................................................................................................... 7
Szenarien ........................................................................................................................................ 10
Serverless SaaS ....................................................................................................................... 10
Mandantenübergreifenden Zugriff vermeiden ......................................................................... 12
Ebenen verbergen Mandantendetails ................................................................................... 13
Amazon EKS SaaS ................................................................................................................... 14
Full-Stack-Isolation .................................................................................................................... 16
Einheitliches Onboarding, Management und Vorgänge ............................................................ 17
Hybrid-SaaS-Bereitstellung ......................................................................................................... 18
Multi-Mandanten-Microservices ................................................................................................... 19
Mandanteneinblicke ................................................................................................................... 20
Die Säulen des Well-Architected Framework ......................................................................................... 22
Säule „Betriebliche Exzellenz“ ..................................................................................................... 22
Konzeptionelle Grundsätze ................................................................................................. 22
Definition ......................................................................................................................... 22
Bewährte Methoden .......................................................................................................... 23
Ressourcen ...................................................................................................................... 28
Säule „Sicherheit“ ..................................................................................................................... 29
Konzeptionelle Grundsätze ................................................................................................. 29
Definition ......................................................................................................................... 29
Bewährte Methoden .......................................................................................................... 29
Ressourcen .................................................................................................................... 39
Säule „Zuverlässigkeit“ ............................................................................................................... 40
Konzeptionelle Grundsätze ................................................................................................. 40
Definition ......................................................................................................................... 40
Bewährte Methoden .......................................................................................................... 40
Ressourcen ...................................................................................................................... 44
Säule „Leistungseffizienz“ ........................................................................................................... 45
Definition ......................................................................................................................... 45
Bewährte Methoden .......................................................................................................... 45
Ressourcen ...................................................................................................................... 50
Säule „Kostenoptimierung“ ......................................................................................................... 50
Definition ......................................................................................................................... 50
Bewährte Methoden .......................................................................................................... 51
Ressourcen ...................................................................................................................... 55
Fazit ............................................................................................................................................... 56
Mitwirkende ...................................................................................................................................... 57
Dokumentversionen ........................................................................................................................... 58
Hinweise .......................................................................................................................................... 59
iii
SaaS Lens AWS Well-Architected Framework
Überblick
SaaS Lens
Veröffentlichungsdatum: 3. Dezember, 2020 (Dokumentversionen (p. 58))
Überblick
Dieses Paper beschreibt die SaaS Lens für das AWS Well-Architected Framework, mit der Kunden
ihre cloudbasierten Architekturen überprüfen und verbessern und die geschäftlichen Auswirkungen
ihrer Designentscheidungen besser verstehen können. Wir gehen dabei auf allgemeine konzeptionelle
Grundsätze sowie auf Best Practices ein und geben Anleitungen zu fünf konzeptionellen Bereichen, die wir
als die Säulen des Well-Architected Frameworks bezeichnen.
1
SaaS Lens AWS Well-Architected Framework
Einführung
Das AWS Well-Architected Framework unterstützt Sie dabei, die Vor- und Nachteile der Entscheidungen
nachzuvollziehen, die Sie beim Aufbau von Systemen in AWS treffen. Das Framework hilft Ihnen,
architektonische Best Practices für die Entwicklung und den Betrieb zuverlässiger, sicherer, effizienter
und kosteneffektiver Systeme in der Cloud zu ermitteln. Es bietet Ihnen die Möglichkeit, Ihre Architekturen
konsistent hinsichtlich der Einhaltung von Best Practices zu überprüfen und Optimierungsmöglichkeiten
zu identifizieren. Wir sind davon überzeugt, dass architektonisch gute Systeme die Wahrscheinlichkeit des
geschäftlichen Erfolgs signifikant beeinflussen.
Bei dieser „Linse“ konzentrieren wir uns auf die Entwicklung, Bereitstellung und Architektur Ihrer Multi-
Mandanten-SaaS (Software as a Service)-Anwendungs-Workloads in der AWS Cloud. Der Übersichtlichkeit
halber behandeln wir nur Details aus dem Well-Architected Framework, die spezifisch für SaaS-Workloads
sind. Sie sollten weiterhin bewährte Methoden und Fragen berücksichtigen, die nicht in diesem Dokument
enthalten sind, wenn Sie Ihre Architektur entwerfen. Wir empfehlen Ihnen, das Whitepaper AWS Well-
Architected Framework zu lesen.
Dieses Dokument richtet sich an Nutzer in technologischen Rollen, z. B. CTOs (Chief Technology Officers),
Architekten, Entwickler und Mitglieder von Operations-Teams. Mit Lektüre dieses Dokuments erfahren Sie
mehr über die bewährten Methoden und Strategien von AWS für die Entwicklung von Architekturen für
SaaS-Anwendungen.
2
SaaS Lens AWS Well-Architected Framework
Mandant
Definitionen
Das AWS Well-Architected Framework basiert auf fünf Säulen: betriebliche Exzellenz, Sicherheit,
Zuverlässigkeit, Leistungseffizienz und Kostenoptimierung. Durch SaaS ist jede dieser Säule mit
vollkommen neuen Überlegungen verknüpft. Da es sich bei SaaS-Anwendungen um Multi-Mandanten-
Anwendungen handelt, müssen Architekten einen neuen Ansatz dafür finden, wie sie Sicherheit,
betriebliche Exzellenz, Stabilität und Agilität in ihre SaaS-Umgebungen einbinden. In diesem Abschnitt
finden Sie eine Übersicht über die SaaS-Konzepte, die in diesem Dokument verwendet werden. Wenn Sie
eine SaaS-Architektur aufbauen, müssen Sie 10 Bereiche berücksichtigen.
Themen
• Mandant (p. 3)
• Silo-, Pool- und Brückenmodelle (p. 3)
• SaaS-Identität (p. 4)
• Mandantenisolation (p. 4)
• Datenpartitionierung (p. 5)
• „Noisy Neighbor“ (p. 5)
• Mandanten-Onboarding (p. 5)
• Mandantenstufen (p. 5)
• Mandantenaktivität und -verbrauch (p. 5)
• Mandantenbewusste Vorgänge (p. 6)
Mandant
Ein Mandant ist das grundlegendste Konstrukt einer SaaS-Umgebung. Wenn Sie als SaaS-Anbieter eine
Anwendung bauen, stellen Sie diese Anwendung Ihren Kunden zur Verfügung. Die Kunden, die sich
anmelden, um Ihre Umgebung zu nutzen, werden in Ihrem System als Mandanten dargestellt. Stellen
Sie sich zum Beispiel vor, Ihr Unternehmen hat einen Buchhaltungsservice erstellt, den Sie anderen
Unternehmen zur Verfügung stellen möchten, damit sie damit ihre Geschäfte verwalten können. Jedes
dieser Unternehmen würde als ein Mandant Ihres Systems gelten.
Wenn sich ein Mandant registriert, wird er meist Benutzerinformationen für den Mandanten-Administrator
bereitstellen. Der Mandanten-Administrator kann sich dann im System anmelden und es basierend auf
den Bedürfnissen des jeweiligen Unternehmens konfigurieren. Dazu gehört die Fähigkeit, Benutzer einer
bestimmten Mandanten-Umgebung hinzuzufügen.
Die in diesem Modell bereitgestellte Software wird als ein Multi-Mandanten-SaaS-System bereitgestellt, da
jeder der Mandanten des Services ein einziges, gemeinsames System nutzt, das die Bedürfnisse dieser
Mandanten in Form einer einheitlichen Erfahrung unterstützt. Ein Update an dem System beispielsweise
wird gewöhnlich für alle Mandanten dieses Systems durchgeführt.
Silo-, Pool- und Brückenmodelle
SaaS-Architekturen können mit vielen verschiedenen Architekturmodellen gebaut werden. Regulatorische,
wettbewerbsorientierte, strategische, Kosteneffizienz- und Marktüberlegungen wirken sich allesamt auf
Ihre SaaS-Architektur aus. Gleichzeitig werden Strategien und Muster angewendet, um den Fußabdruck
3
SaaS Lens AWS Well-Architected Framework
SaaS-Identität
einer SaaS-Anwendung zu definieren. Diese Muster lassen sich in eine von drei Kategorien einordnen: Silo,
Brücke und Pool.
Das Silomodell bezieht sich auf eine Architektur, in der Mandanten dedizierte Ressourcen bereitgestellt
werden. Stellen Sie sich beispielsweise eine SaaS-Umgebung vor, in der jeder Mandant Ihres Systems
ein vollständig unabhängiges Infrastruktur-Stack hat. Oder vielleicht, dass jeder Mandant Ihres Systems
für jeden Mandanten eine separate Datenbank hat. Wenn einige oder alle Ressourcen eines Mandanten
auf diese dedizierte Weise bereitgestellt werden, bezeichnen wir das als Silomodell. Es sei darauf
hingewiesen, dass, auch wenn das Silo dedizierte Ressourcen hat, eine Siloumgebung dennoch auf
einer gemeinsamen Identität, Onboarding und operativer Erfahrung basiert, in der alle Mandanten über
ein gemeinsames Konstrukt verwaltet und bereitgestellt werden. Das unterscheidet SaaS von einem
verwalteten Servicemodell, in dem Kunden separate Versionen Ihres Produkts mit separaten Onboarding-,
Management- und operativen Erfahrungen ausführen können.
Im Gegensatz dazu steht das Poolmodell von SaaS, in dem Mandanten sich Ressourcen teilen. Bei dieser
klassischeren Definition einer Multi-Mandanten-Umgebung hängen Mandanten von einer gemeinsamen,
skalierbaren Infrastruktur ab, um Einsparungen in den Bereichen Skalierbarkeit, Verwaltbarkeit, Agilität
usw. zu erreichen. Diese gemeinsamen Ressourcen können sich auf einige oder alle Elemente Ihrer SaaS-
Architektur beziehen, darunter Rechenleistung, Speicher, Messaging usw.
Das letzte Muster ist das Brückenmodell. Mit Brücke wird die Tatsache anerkannt, dass sich SaaS-
Geschäfte nicht immer nur als Silo oder Pool definieren lassen. Stattdessen haben viele Systeme einen
gemischten Modus, bei dem ein Teil des Systems in einem Silomodell implementiert ist und ein anderer
Teil in einem Poolmodell. Einige Microservices in Ihrer Architektur könnten beispielsweise mit einem Silo-,
andere mit einem Poolmodell implementiert sein. Das regulatorische Profil der Daten eines Services und
ihre „Noisy Neighbor“-Eigenschaften könnten einen Microservice in ein Silomodell lenken. Die Agilität, die
Zugriffsmuster und das Kostenmodell eines anderen Microservices wiederum könnten ihn in ein Poolmodell
lenken.
SaaS-Identität
Die Authentifizierung erfolgt in den meisten Systemen über einen Identitätsanbieter. In der Welt von SaaS
müssen wir den Begriff „Identität“ um Mandanten erweitern. Das bedeutet, dass wir, nachdem wir einen
Benutzer authentifiziert haben, wissen müssen, wer der Benutzer ist und mit welchem Mandanten er
verbunden ist. Das Verschmelzen der Benutzeridentität mit der Mandantenidentität wird als eine SaaS-
Identität bezeichnet. Dieses Konzept ist ein grundlegendes Element einer SaaS-Architektur, das den
Mandantenkontext bereitstellt, mit dem die zugrunde liegenden Multi-Mandanten-Richtlinien und -Strategien
implementiert werden, die Teil einer SaaS-Anwendung sind.
Mandantenisolation
Mandantenisolation gehört zu den ersten Themen, mit denen sich jeder SaaS-Anbieter befassen muss.
Unabhängige Softwareanbieter (ISVs) wenden sich SaaS zu und übernehmen ein gemeinsames
Infrastrukturmodell, um operative und Kosteneffizienz zu erzielen. In diesem Zusammenhang müssen
sie sich auch damit befassen, wie ihre Multi-Mandanten-Umgebungen sicherstellen werden, dass kein
Mandant auf die Ressourcen eines anderen Mandanten zugreifen kann. Sollte die Grenze in irgendeiner
Form überschritten werden, würde dies für ein SaaS-Unternehmen ein bedeutendes und möglicherweise
nicht behebbares Ereignis darstellen.
Die Notwendigkeit der Mandantenisolation gilt zwar bei SaaS-Anbietern als essentiell, es gibt aber keine
einheitlichen Strategien und Ansätze, um diese Isolation zu erreichen. Viele verschiedene Faktoren können
sich darauf auswirken, wie die Mandantenisolation in einer SaaS-Umgebung erreicht wird. Die Domäne,
Compliance, das Bereitstellungsmodell und die Auswahl der AWS-Services sind alle mit ihren individuellen
Überlegungen in Bezug auf die Mandantenisolation verknüpft.
4
SaaS Lens AWS Well-Architected Framework
Datenpartitionierung
Unabhängig davon, wie die Isolation umgesetzt wird, muss jede SaaS-Architektur sicherstellen, dass sie
über die Konstrukte verfügt, mit denen sichergestellt wird, dass die Ressourcen jedes Mandanten effektiv
isoliert wurden.
Datenpartitionierung
Wenn Sie verschiedene Architekturmuster für die Darstellung von Multi-Mandanten-Daten betrachten,
müssen Sie Entscheidungen darüber treffen, wie diese Daten organisiert werden. Werden die Daten
in separaten Datenbanken gespeichert oder in einem gemeinsamen Konstrukt vermischt? Diese Multi-
Mandanten-Speichermechanismen und -muster werden meist als Datenpartitionierung bezeichnet.
„Noisy Neighbor“
„Noisy Neighbor“ ist ein Begriff, der häufig auf allgemeine Architekturmuster und -strategien angewendet
wird. Er bezieht sich darauf, dass ein Benutzer eines Systems auf die Ressourcen dieses Systems eine
Last ausüben könnte, die sich negativ auf andere Benutzer im System auswirkt. Das könnte dazu führen,
dass ein Benutzer die Erfahrung eines anderen Benutzers verschlechtert.
Dieses Konzept ist besonders relevant in einer Multi-Mandanten-Umgebung, in der Mandanten
gemeinsame Ressourcen nutzen können. Erschwerend kommt hinzu, dass die Workloads in einer Multi-
Mandanten-Umgebung unvorhersehbar sein können. Daher müssen SaaS-Architekturen unbedingt eigene
Strategien umsetzen und die möglichen Auswirkungen von „noisy“ Mandanten verwalten und geringhalten.
Mandanten-Onboarding
SaaS-Anwendungen bauen auf einem unkomplizierten Modell für die Einführung neuer Mandanten in
ihre Umgebung auf. Dafür müssen häufig eine Reihe von Komponenten zusammenwirken, um alle für die
Erstellung eines neuen Mandanten erforderlichen Elemente erfolgreich bereitzustellen und zu konfigurieren.
Dieser Vorgang wird in der SaaS-Architektur als Mandanten-Onboarding bezeichnet. Es sei darauf
hingewiesen, dass das Mandanten-Onboarding direkt von den Mandanten oder im Rahmen eines vom
Anbieter verwalteten Vorgangs initiiert werden kann.
Mandantenstufen
Eine SaaS-Anwendung wird häufig gebaut, um eine Reihe von Marktsegmenten zu unterstützen und
verschiedenen Kundenprofilen separate Preise und Erfahrungen zu bieten. Diese Profile werden häufig als
Stufen bezeichnet. Damit diese verschiedenen Stufen unterstützt werden, müssen Architekturkonstrukte
eingeführt werden, die sich auf die Erfahrung jeder Stufe auswirken können. Diese mehrstufigen Modelle
können den Kosten-, Betriebsvorgangs-, Management- und Zuverlässigkeitsfußabdruck einer SaaS-Lösung
beeinflussen.
Mandantenaktivität und -verbrauch
In einer Multi-Mandanten-SaaS-Umgebung muss sichtbar sein, wie Mandanten Ihre Anwendung nutzen
und die Architektur Ihres Systems belasten. Wenn Sie diese Informationen auf Mandantenebene verfolgen,
können Sie beurteilen, ob Ihr System die sich ständig ändernden Workloads in Ihrer Umgebung effektiv
skalieren und unterstützen kann. Die Metriken und Erkenntnisse, die von einem SaaS-System gesammelt
werden, werden als Mandantenaktivität und -verbrauch bezeichnet.
5
SaaS Lens AWS Well-Architected Framework
Messung und Abrechnung
Messung und Abrechnung
SaaS-Produkte werden häufig als Pay-as-You-Go-Modell verkauft, bei dem die Kosten eines Produkts vom
Verbrauchsprofil eines Kunden abhängen. Bei diesem Modell haben Kunden ein Preismodell, das enger
mit dem Wert und der Belastung eines SaaS-Systems verknüpft ist. Bei diesem Modus definieren SaaS-
Anbieter Messmechanismen, die den Verbrauch messen, und führen sie ein. Diese Messdaten werden in
der Regel an ein Abrechnungssystem geschickt, dass die Abrechnungsinformationen sammelt und eine
Rechnung erstellt. Verbrauchsbasierte Preise stellen ein Preismodell dar, das mit weiteren Preisstrategien
(wie ein Abonnement) kombiniert werden kann.
Mandantenbewusste Vorgänge
Für den Betrieb von SaaS-Umgebungen werden zusätzliche Mechanismen und Tools benötigt, mit denen
operative Ansichten erstellt werden können, die es den Teams ermöglichen, mandantenbewusste optionale
Ansichten zu erstellen. Die Idee dahinter ist, dass SaaS-Anbieter die Systemaktivität und -gesundheit
aus dem Blickwinkel individueller Mandanten oder Mandantenstufen betrachten können müssen. Das
ist entscheidend bei der Diagnose und Beurteilung von Trends und Mustern in den Aktivitäten und im
Verbrauch einzelner Mandanten.
6
SaaS Lens AWS Well-Architected Framework
Allgemeine konzeptionelle
Grundsätze
Das Well-Architected Framework fasst allgemeine konzeptionelle Grundsätze zusammen, die einen guten
Aufbau in der Cloud für SaaS-Anwendungen fördern:
• Es gibt nicht nur eine SaaS-Architektur: Die Bedürfnisse von SaaS-Unternehmen, die Art ihrer Domäne,
ihre Complianceanforderungen, ihre Marktsegmente, ihre Lösungsart sind allesamt Faktoren, die sich
entscheidend auf die Architektur einer SaaS-Umgebung auswirken. Jede SaaS-Umgebung sollte von
einer operativen und Kundenerfahrung umgeben sein, die die Agilität und Software-as-a-Service-
Grundsätze widerspiegeln, die für ein erfolgreiches SaaS-Angebot entscheidend sind. Egal, wie
das System aufgebaut ist, es sollte immer möglich sein, dass Mandanten über eine einzige Konsole
hinzugefügt, verwaltet und geleitet werden. Dadurch erreicht das SaaS-Unternehmen die Agilität und die
umfangreichen Einsparungen, die den Grundstein beim Aufbau eines SaaS-Geschäfts bilden.
• Zerlegung jedes Services basierend auf seiner Multi-Mandanten-Last und seinem Isolationsprofil: Wenn
Sie Ihr System in Services zerlegen, sollte Ihre Zerlegungsstrategie berücksichtigen, wie sich Multi-
Mandanten-Lasten, Mandantenstufen und Isolationsanforderungen auf die Services auswirken, die
Teil Ihres Systems sind. In diesen Szenarios muss jeder Service separat betrachtet werden. Einige
Services können Daten vielleicht zusammenlegen, während andere die Daten, die sie verwalten, aus
Compliancegründen oder aufgrund von „Noisy Neighbor“-Vorkehrungen separat speichern müssen. Sie
werden ebenso sehen, dass einige Services in einem Silomodell bereitgestellt werden, um mehrstufige
Strategien zu ermöglichen. Für Premium-Mandanten beispielsweise können als Teil der Wertgeschichte
der Premiumstufe einige Services in einem Silomodell verfügbar sein.
• Alle Mandantenressourcen werden isoliert: Der Erfolg eines SaaS-Systems hängt stark von
einem Sicherheitsmodell ab, das sicherstellt, dass die Mandantenressourcen stets vor jeglichem
mandantenübergeifenden Zugriff geschützt sind. Eine robuste SaaS-Architektur führt Isolationsstrategien
in jeder Ebene der Architektur ein und stellt spezifische Konstrukte bereit, die sicherstellen, dass jeglicher
Versuch, auf eine Mandantenressource zuzugreifen, im Sinne des aktuellen Mandantenkontextes gültig
ist.
• Auf Wachstum ausgelegt: Bei der Entscheidung für ein SaaS-Modell geht es für SaaS-Unternehmen
häufig um Wachstum. Während Sie den architektonischen und operativen Fußabdruck Ihres SaaS-
Angebots festlegen, müssen Sie stets im Hinterkopf behalten, wie Ihre Umgebung in der Lage sein wird,
einen rasanten Anstieg neuer Mandanten zu unterstützen. SaaS-Architekten müssen eine besonders
agile, reibungslose Umgebung aufbauen, die Anstiege im Mandanten-Onboarding ohne erheblichen
zusätzlichen Betriebsaufwand bewältigen kann. Hier geht es darum, ein Wachstum Ihres Kundenstamms
zu ermöglichen, ohne den operativen oder infrastrukturellen Fußabdruck Ihrer SaaS-Umgebung zu
vergrößern.
• Mandantenmetriken instrumentieren, erfassen und analysieren: Wenn Sie mehrere Mandanten in einer
Umgebung haben, insbesondere in einer gemeinsamen Umgebung, kann es schwierig sein, einen klaren
Überblick darüber zu haben, wie Mandanten Ihr System nutzen. SaaS-Teams müssen in metrische
Instrumente investieren, die Einblicke in die von den Mandanten genutzten Funktionen, die Belastung
des Systems, die Engpässe, das Kostenprofil ihrer Aktivitäten usw. geben können. Die Daten sind
wichtig, um Mandantentrends zu analysieren, die sich direkt auf die geschäftliche, architektonische
und operative Gesundheit eines SaaS-Unternehmens auswirken, und entsprechend in die Strategie
eingespeist zu werden.
• Mandanten-Onboarding erfolgt über einen einzigen, automatisierten, wiederholbaren Prozess: SaaS
steht für Agilität. Wichtiger Bestandteil der Agilität ist der Mandanten-Onboarding-Vorgang. Ein robustes
SaaS-System verfügt über einen unkomplizierten, wiederholbaren Vorgang für das Onboarding neuer
7SaaS Lens AWS Well-Architected Framework
Mandanten in Ihr System. Das ermöglicht Skalierbarkeit und Wachstum. Und so wird auch sichergestellt,
dass neue Kunden schneller einen Nutzen aus Ihrer Anwendung ziehen.
• Die Unterstützung von Multi-Mandanten-Erfahrungen einplanen: SaaS-Märkte und -Kunden lassen
sich nicht alle in einem einzigen Profil unterbringen. SaaS-Unternehmen müssen häufig eine Reihe von
Mandantenprofilen unterstützen, die unterschiedliche Anforderungen an Ihre Architektur und Operationen
haben. Als SaaS-Anbieter und -Architekt müssen Sie diese Mandantenpersönlichkeiten modellieren und
eine einzige Umgebung aufbauen, die Konstrukte und Mechanismen umfasst, mit denen eine Reihe
von Mandantenerfahrungen ermöglicht werden, ohne einmalige Versionen Ihres Produkts erstellen
zu müssen. Es ist wichtig, dass Sie die Wertgrenzen Ihres Systems identifizieren, damit das Geschäft
Stufen für Ihr Angebot erstellen kann, die mehrere Segmente erreichen und das Vorankommen eines
Kunden durch diese Stufen fördert.
• Unterstützung von einmaligen Bedürfnissen durch globale Anpassung: SaaS-Agilität und -Innovation
werden durch eine einzige Umgebung erreicht, die von allen Kunden ausgeführt wird. Es ist ein
grundlegender Bestandteil von SaaS, alle Kunden gemeinsam aktualisieren, verwalten und leiten zu
können. In der Realität sind für einige Kunden jedoch unter Umständen Anpassungen erforderlich. Diese
Anpassungen sollten als Konfigurationsoptionen eingeführt werden, die jedem Kunden zur Verfügung
stehen. Indem diese Funktionen wesentlicher Bestandteil des Angebots werden, kann ein SaaS-
Unternehmen einmalige Bedürfnisse unterstützen, ohne dass die Agilität, die betriebliche Effizienz und
die Innovationsziele des Geschäfts darunter leiden müssten.
• Verknüpfung von Benutzeridentität mit Mandantenidentität: Für jede Ebene Ihrer Architektur wird
wahrscheinlich eine Art Mandantenkontext erforderlich sein, um Daten zu protokollieren, Metriken
aufzuzeichnen, auf Daten zuzugreifen usw. Das bedeutet, dass der Mandantenkontext ein erstklassiges
Konstrukt sein muss, das von den Ebenen Ihrer Architektur gelöst und leicht erreicht werden
kann, ohne dass ein anderer Service hinzugezogen werden müsste. Die Authentifizierungs- und
Autorisierungserfahrung Ihrer Lösung sollte die Mandantenidentität (und möglicherweise andere
Mandantenattribute) mit der Identität des authentifizierten Benutzers verknüpfen. Dadurch entsteht
eine SaaS-Identität, die durch alle Ebenen des Systems geführt wird und einen leichten Zugriff auf den
Mandantenkontext ermöglicht.
• Anpassung des Infrastrukturverbrauchs an die Mandantenaktivität: Die Aktivitäten von Mandanten
in einer SaaS-Umgebung lassen sich häufig nicht vorhersehen. Welche Ressourcen Mandanten
verbrauchen, wie sie sie verbrauchen und wann sie sie verbrauchen, kann stark variieren. Auch die
Anzahl der Mandanten in Ihrem System kann sich regelmäßig ändern. All diese Faktoren stellen zwar
Skalierungsherausforderungen dar, eine robuste SaaS-Architektur wird jedoch über Richtlinien verfügen,
um eine Überbereitstellung zu begrenzen und den Infrastrukturverbrauch einer Anwendung auf die
Echtzeittrends in der Mandantenaktivität anzupassen. Das führt zu einer engeren Übereinstimmung
zwischen Mandanten-Workloads und dem Kostenprofil Ihrer gesamten SaaS-Infrastruktur.
• Entwicklerbewusstsein auf Multi-Mandanten-Konzepte beschränken: Auch wenn sich Tenancy durch alle
Ebenen Ihrer Architektur zieht, sollten Sie das Ziel haben, dass Entwickler möglichst wenig mit Tenancy
zu tun haben. Als Faustregel gilt, dass sich die Erfahrung eines Entwicklers, der einen Multi-Mandanten-
Service schreibt, nicht sehr stark vom Schreiben eines Services ohne Mandanten unterscheiden soll.
Wenn Entwickler über ihren Code Tenancy einführen müssen, wird es schwierig sein, die Einhaltung der
Multi-Mandanten-Richtlinien und -Mechanismen Ihrer Anwendung zu verwalten und durchzusetzen. Das
bedeutet, dass Entwicklern Bibliotheken und wiederverwendbare Konstrukte bereitgestellt werden, um
die Details der Mandanten zu verbergen.
• SaaS ist eine Geschäftsstrateige, keine technische Implementierung: SaaS-Umgebungen und ihre
zugrunde liegenden Technologieentscheidungen werden direkt von den Agilitäts-, Innovations- und
Wettbewerbsbedürfnissen des Geschäfts beeinflusst. Der Schwerpunkt liegt hier darauf, den Kunden
eine Serviceerfahrung zu bieten, die sich auf null Ausfallzeit, regelmäßige Updates und eine engere
Verbindung zu Kunden konzentriert. Daher muss ein architektonischer und operativer Fußabdruck
geschaffen werden, der die ständige Weiterentwicklung von und schnelle Antwort auf Marktnachfragen
stemmen kann. Eine technisch solide Architektur, die keine Agilität, Innovation und operative Effizienz
ermöglicht, wird wahrscheinlich nicht mit der Wettbewerbslandschaft des Marktes mithalten können,
insbesondere wenn Sie SaaS-Anbieter als Wettbewerber haben.
• Mandantenbewusste betriebliche Ansichten erstellen: Operations Teams sind in einer Multi-Mandanten-
Umgebungen neuen Herausforderungen ausgesetzt. Auch wenn es in SaaS-Umgebungen weiter wichtig
8SaaS Lens AWS Well-Architected Framework
ist, einen globalen Überblick über den Zustand und die Aktivität eines Systems zu behalten, umfasst
ein robuster operativer SaaS-Fußabdruck auch Einblicke in die Nutzung des Systems durch bestimmte
Mandanten oder Mandantenstufen. SaaS Operations Teams sollten Dashboards und Ansichten erstellen,
über die sie die Aktivitäten und Lasten einzelner Mandanten analysieren und zuordnen können. Die
Nutzung aus dem Blickwinkel einzelner Mandanten zu sehen und zu untersuchen ist wichtig beim Aufbau
einer proaktiven, effizienten operativen Multi-Mandanten-Erfahrung.
• Die Kostenauswirkung einzelner Mandanten messen: Die Geschäftsebene, die Architekten und die
Operations Teams eines SaaS-Unternehmens müssen sich häufig ein klares Bild davon verschaffen,
wie Mandanten sich auf den Kostenfußabdruck einer SaaS-Umgebung auswirken. Zum Beispiel:
Verursachen die Mandanten in der Grundstufe höhere Kosten als die Mandanten in der Premiumstufe?
Ändern Mandantenverbrauchsmuster oder -merkmale das Kostenprofil Ihrer Umgebung? Das sind
einige der Fragen, die am besten beantwortet werden können, wenn Sie einen klaren Überblick über die
Kostenprofile der Mandanten haben. Das ist vor allem in den Umgebungen von Bedeutungen, in denen
sich mehrere Mandanten Mandantenressourcen teilen. Das Erfassen und Ermitteln dieser Daten bietet
einem SaaS-Geschäft häufig wertvolle Einblicke, die die Architektur und das Geschäftsmodell eine SaaS-
Unternehmens beeinflussen können.
9SaaS Lens AWS Well-Architected Framework
Serverless SaaS
Szenarien
In diesem Abschnitt befassen wir uns mit einer Reihe von Szenarien, die häufige Muster und Strategien
beim Design und Aufbau von SaaS-Lösungen in AWS vorstellen. Wir präsentieren die Annahmen,
die wir für jedes dieser Szenarien gemacht haben, die gängigen Treiber für das Design und eine
Referenzarchitektur, wie diese Szenarien mit AWS-Architektur-Konstrukten erstellt werden.
Themen
• Serverless SaaS (p. 10)
• Amazon EKS SaaS (p. 14)
• Full-Stack-Isolation (p. 16)
• Hybrid-SaaS-Bereitstellung (p. 18)
• Multi-Mandanten-Microservices (p. 19)
• Mandanteneinblicke (p. 20)
Serverless SaaS
Die Entscheidung für ein SaaS-Bereitstellungsmodell geht mit dem Wunsch nach maximaler Kosten- und
Betriebseffizienz einher. Das kann vor allem in einer Multi-Mandanten-Umgebung eine Herausforderung
sein, in der sich die Aktivität von Mandanten nur schwer vorhersagen lässt. Die richtig zusammengesetzte
Skalierungsstrateige, die die Mandantenaktivität auf den tatsächlichen Ressourcenverbrauch ausrichtet, ist
mitunter schwer definierbar. Die Strategie, die heute funktioniert, kann morgen unter Umständen nicht mehr
funktionieren.
Aufgrund dieser Eigenschaften ist SaaS gut für ein serverloses Modell geeignet. Wenn Unternehmen
Server aus ihrer SaaS-Architektur entfernen, können sie sich auf skalierbare verwaltete Services
verlassen und genau die Ressourcen bereitstellen, die Ihre Anwendung verbraucht. Das vereinfacht den
architektonische und betrieblichen Fußabdruck Ihrer Anwendung, da keine Skalierungsrichtlinien ständig
verfolgt und verwaltet werden müssen. Ebenso werden der Betriebsaufwand und die Komplexität verringert
und mehr operative Verantwortung auf die verwalteten Services übertragen.
AWS bietet eine Reihe von Services, mit denen eine serverlose SaaS-Lösung implementiert werden kann.
Das Diagramm in Abbildung 1 zeigt ein Beispiel einer serverlosen Architektur.
10SaaS Lens AWS Well-Architected Framework
Serverless SaaS
Abbildung 1: Serverlose SaaS-Architektur
Hier sehen Sie, dass sich die beweglichen Teile einer serverlosen SaaS-Architektur nicht stark von einer
klassischen serverlosen Webanwendungsarchitektur unterscheiden. Links im Diagramm sehen Sie, dass
unsere Webanwendung über einen Amazon S3-Bucket gehostet und bedient wird (wahrscheinlich von
einem modernen Client-Framework wie React, Angular usw.).
In dieser Architektur nutzt die Anwendung Amazon Cognito als unseren SaaS-Identitätsanbieter. Die
Authentifizierungserfahrung bildet ein Token, das unseren SaaS-Kontext umfasst, der über ein JSON Web
Token (JWT) vermittelt wird. Dieses Token wird dann in unsere Interaktionen mit allen nachgelagerten
Anwendungsservices injiziert.
Die Interaktion mit unseren serverlosen Anwendungsservices wird von dem Amazon API Gateway
organisiert. Der Gateway übernimmt hier mehrere Rollen. Er validiert die eingehenden Mandanten-Token
(über einen Lambda-Genehmiger), weist jede Anfrage eines Mandanten Microservices zu und kann
verwendet werden, um die SLAs unterschiedlicher Mandantenstufen zu verwalten (über Nutzungspläne).
Sie werden auch sehen, dass wir hier eine Reihe von Microservices dargestellt haben, die als Platzhalter
für die zahlreichen Services dienen, die die Multi-Mandanten-IP Ihrer SaaS-Anwendung implementieren
würden. Jeder Microservice hier setzt sich aus einer oder mehreren Lambda-Funktionen zusammen, die
den Vertrag Ihres Microservices implementieren. In Übereinstimmung mit bewährten Microservicemethoden
fassen diese Services auch die Daten zusammen, die sie verwalten. Diese Services sind von dem
eingehenden JWT-Token abhängig, um den Mandantenkontext zu erhalten und dort anzuwenden, wo er
benötigt wird.
Wir haben hier auch für jeden Microservice Speicher angezeigt. In Übereinstimmung mit bewährten
Microservicemethoden besitzt jeder Microservice die von ihm verwalteten Ressourcen. So können sich
beispielsweise zwei Microservices nicht eine Datenbank teilen. SaaS hat hier einen Nachteil, da die Multi-
Mandanten-Darstellung der Daten je nach Service anders aussehen kann. Ein Service kann für jeden
Mandanten separate Datenbanken haben (Silo), während ein anderer die Daten in der gleichen Tabelle
vermischt (Pool). Die Speicherentscheidungen, die Sie hier treffen, sollten sich an Überlegungen zu
Compliance, „Noisy Neighbor“, Isloation und Leistung orientieren.
Rechts im Diagramm sehen Sie schließlich eine Reihe gemeinsamer Services. Diese Services stellen
die gesamte Funktionalität bereit, die von allen Mandanten geteilt wird, die links im Diagramm angezeigt
werden. Diese Services repräsentieren häufige Services, die für gewöhnlich als separate Microservices
gebaut werden und für das Onboarding, die Verwaltung und die Leitung von Mandanten erforderlich sind.
11SaaS Lens AWS Well-Architected Framework
Mandantenübergreifenden Zugriff vermeiden
Weitere Informationen über allgemeine bewährte Well-Architected-Methoden finden Sie im Whitepaper
Serverless Applications Lens.
Mandantenübergreifenden Zugriff vermeiden
Jede SaaS-Architektur muss außerdem überlegen, wie sie verhindern wird, dass Mandanten auf die
Ressourcen eines anderen Mandanten zugreifen. Einige fragen sich, ob Mandanten wirklich mit AWS
Lambda isoliert werden müssen, da grundsätzlich immer nur ein Mandant auf einmal eine Lambda-Funktion
ausführen kann. Das stimmt zwar, aber unsere Isolation muss auch sicherstellen, dass ein Mandant,
der eine Funktion ausführt, nicht auf andere Ressourcen zugreift, die möglicherweise einem anderen
Mandanten gehören.
SaaS-Anbieter können bei der Implementierung von Isolation in einer serverlosen SaaS-Umgebung zwei
grundlegende Ansätze verfolgen. Die erste Option folgt dem Silomuster, bei dem für jeden Mandanten
ein separater Satz an Lambda-Funktionen bereitgestellt wird. Mit diesem Modell definieren Sie eine
Ausführungsrolle für jeden Mandanten und stellen für jeden Mandanten separate Funktionen mit seiner
Ausführungsrolle bereit. Diese Ausführungsrolle definiert, auf welche Ressourcen ein bestimmter Mandant
zugreifen kann. Sie können zum Beispiel in diesem Modell eine Reihe von Mandanten der Premiumstufe
bereitstellen. Die Verwaltung kann sich jedoch als schwierig erweisen und mit Kontolimits in Berührung
kommen (je nachdem, wie viele Mandanten Ihr System unterstützt).
Die andere Option entspricht eher dem Poolmodell. Hier werden Funktionen in einer Ausführungsrolle
bereitgestellt, deren Umfang so breit ist, dass sie Aufrufe von allen Mandanten akzeptiert. In diesem Modus
müssen Sie den Isolationsumfang während der Laufzeit in der Implementierung Ihrer Multi-Mandanten-
Funktionen anwenden. Das Diagramm in Abbildung 2 zeigt ein Beispiel dafür, wie das aussehen würde.
Abbildung 2: Isolation in einer serverlosen Umgebung
In diesem Beispiel sehen Sie, dass drei Mandanten auf eine Reihe von Lambda-Funktionen zugreifen.
Da diese Funktionen geteilt werden, werden sie mit einer Ausführungsrolle bereitgestellt, die alle
Mandanten abdeckt. Innerhalb der Implementierung dieser Funktionen verwendet unser Code den
Kontext des aktuellen Mandanten (über JWT bereitgestellt), um neue auf den Mandanten ausgerichtete
Anmeldeinformationen von AWS Security Token Service (AWS STS) zu erhalten. Wenn wir diese
Anmeldeinformationen erhalten haben, kann mit ihnen auf die Ressourcen mit Mandantenkontext
zugegriffen werden. In diesem Beispiel verwenden wir diese ausgerichteten Anmeldeinformationen, um auf
Speicher zuzugreifen.
12SaaS Lens AWS Well-Architected Framework
Ebenen verbergen Mandantendetails
Es sei darauf hingewiesen, dass in diesem Modell kein Teil des Isolationsmodells in den Code Ihrer
Lambda-Funktionen verschoben wird. Es gibt Methoden (beispielsweise Funktions-Wrapper), die
dieses Konzept außerhalb des Blickfelds der Entwickler einführen können. Die Details zum Erhalt dieser
Anmeldeinformationen können auch auf eine Lambda-Ebene verschoben werden, damit dieses Konstrukt
nahtloser und zentral verwaltet wird.
Ebenen verbergen Mandantendetails
Eines unserer Ziele bei jeder SaaS-Architektur besteht darin, das Entwicklerbewusstsein über
Mandantendetails zu beschränken. In serverlosen SaaS-Umgebungen können Sie Lambda-Ebenen
nutzen, um gemeinsamen Code zu erstellen, der Multi-Mandanten-Richtlinien außerhalb des Blickfelds der
Entwickler implementiert.
Das Diagramm in Abbildung 3 zeigt ein Beispiel dafür, wie Lambda-Ebenen verwendet werden können,
um diese Multi-Mandanten-Konzepte anzugehen. Hier sehen Sie, dass wir zwei separate Microservices
haben (Product und Order), die Protokoll- und Metrik-Daten veröffentlichen müssen. Das entscheidende
Detail hier ist, dass beide Services Mandantenkontext in ihre Protokollmeldungen und Metrikereignisse
injizieren müssen. Es wäre jedoch alles andere als ideal, wenn jeder Service diese Richtlinien eigenständig
implementieren müsste. Stattdessen haben wir eine Ebene eingeführt, die Code enthält, der die
Veröffentlichung dieser Daten verwaltet.
Abbildung 3: Lambda-Ebenen verbergen Mandantendetails
Sie werden feststellen, dass unsere Ebene Protokoll- und Metrikhelfer umfasst, die ein JWT-Token
akzeptieren. Dadurch kann jeder Microservice einfach diese Funktionen aufrufen und das Token
bereitstellen, ohne darauf achten zu müssen, um welchen Mandanten es geht. Innerhalb der Ebene
verwendet der Code dann das JWT-Token, um den Mandantenkontext aufzulösen und ihn in die
Protokollmeldungen und Metrikereignisse zu injizieren.
Das ist nur ein kleiner Überblick darüber, wie Ebenen angewendet werden können, um Mandantenkontext
zu verbergen. Der wahre Mehrwert besteht darin, dass die Richtlinien und Mechanismen für das Injizieren
von Mandantenkontext vollkommen von der Entwicklererfahrung entfernt wurden. Sie werden auch separat
aktualisiert, versioniert und bereitgestellt. Dadurch können diese Richtlinien in Ihrer Umgebung zentraler
verwaltet werden, ganz ohne die Einführung separater Microservices, die zu mehr Latenz führen und
Engpässe erzeugen könnten.
13SaaS Lens AWS Well-Architected Framework
Amazon EKS SaaS
Amazon EKS SaaS
Für viele SaaS-Anbieter passt das Profil von Amazon Elastic Kubernetes Service (Amazon EKS) gut zu
Ihren Zielen bezüglich der Entwicklung und Architektur von Microservices. Es baut Multi-Mandanten-
Microservices auf und stellt sie so bereit, dass die Agilitäts-, Skalierungs-, Kosten- und Betriebsziele
erreicht werden können, ohne dass sie sich auf vollkommen andere Entwicklungstools und -einstellungen
einlassen müssten. Die umfangreiche Community an Kubernetes-Tools und -Lösungen bietet SaaS-
Entwicklern zudem eine Reihe verschiedener Optionen für den Aufbau, die Verwaltung, die Sicherung und
den Betrieb ihrer SaaS-Umgebungen.
In Container-basierten Umgebungen ist ein Großteil der Architektur darauf ausgerichtet, wie wir erfolgreich
sicherstellen, dass mandantenübergreifender Zugriff vermieden wird. Es kann zwar verlockend sein,
Mandanten das Teilen von Containern zu gestatten, aber dabei wird davon ausgegangen, dass Mandanten
mit einer lockeren Multi-Mandanten-Umgebung einverstanden wären. In den meisten SaaS-Umgebungen
erfordern die Isolationsanforderungen jedoch eine deutlich robustere Isolationsimplementierung.
Diese Isolationsfaktoren können sich entscheidend auf das Architekturmodell auswirken, das mit Amazon
EKS erstellt wird. Der allgemeine Leitfaden für den Aufbau von SaaS-Architekturen mit Amazon EKS
besagt, dass sich Mandanten keine Container teilen sollen. Dadurch wird der Architekturfußabdruck
zwar komplexer, wir werden dadurch aber sicherstellen können, dass wir ein Isolationsmodell geschaffen
haben, das die Anforderungen von Multi-Mandanten-Kunden in Bezug auf Domänen, Compliance und
regulatorische Anforderungen erfüllt.
Schauen wir uns nun eine Beispielarchitektur an, um die grundlegenden Elemente einer SaaS-Amazon
EKS-Umgebung kennenzulernen. Da es bei dieser Lösung viele bewegliche Teile gibt, schauen wir uns
zunächst die geteilten Services an, mit denen die wichtigen, horizontalen Konzepte unterstützt werden, die
für all unsere Mandanten gelten (siehe Abb. 4).
Sie werden zunächst die Grundelemente sehen, die Bestandteil jeder hochverfügbaren, hochskalierbaren
AWS-Architektur sind. Die Umgebung umfasst eine VPC, die aus drei Availability Zones besteht. Die
Weiterleitung des eingehenden Verkehrs von Mandanten wird von Amazon Route 53 verwaltet, das so
konfiguriert ist, dass eingehende Anwendungsanfragen an den von unserem NGINX Ingress Controller
definierten Endpunkt geleitet werden. Der Controller ermöglicht das ausgewählte Routing innerhalb unseres
Amazon EKS-Clusters, das für das Multi-Mandanten-Routing entscheidend ist, das Sie nachfolgend sehen
werden.
Abbildung 4: Amazon EKS SaaS-Architektur mit gemeinsamen Services
14SaaS Lens AWS Well-Architected Framework
Amazon EKS SaaS
Die im Amazon EKS-Cluster ausgeführten Services sind eine Auswahl einiger gängiger Services, die meist
Bestandteil einer SaaS-Umgebung sind. Mit der Registrierung wird das Onboarding neuer Mandanten
ermöglicht. Das Mandantenmanagement verwaltet den Status und diese Attribute aller Mandanten im
System und speichert diese Daten in einer Amazon DynamoDB-Tabelle. Das Benutzermanagement stellt
die grundlegenden Vorgänge für das Hinzufügen, Löschen, Aktivieren, Deaktivieren und Aktualisieren von
Mandanten bereit. Die verwalteten Identitäten werden in Amazon Cognito gespeichert. AWS CodePipeline
ist ebenfalls vorhanden, um das Tooling bereitzustellen, das für die Einrichtung jedes neuen Mandanten
verwendet wird, der in das System aufgenommen wird.
Diese Architektur stellt nur die grundlegenden Elemente unserer SaaS-Umgebung dar. Wir müssen uns
nun anschauen, was es bedeutet, Mandanten in diese Umgebung einzuführen. Angesichts der zuvor
beschriebenen Isolationsüberlegungen wird unsere Amazon EKS-Umgebung separate Namespaces
für jeden Mandanten erstellen und diese Namespaces sichern, um sicherzustellen, dass unser
Mandantenisolationsmodell robust ist.
Abbildung 5: Bereitstellen von Mandantenumgebungen in Amazon EKS
Das Diagramm in Abbildung 5 gibt einen Überblick über diese Namespaces innerhalb unserer SaaS-
Architektur. Oberflächlich betrachtet sieht diese Architektur dem vorherigen Baseline-Diagramm ziemlich
ähnlich. Der entscheidende Unterschied besteht darin, dass wir die Services, die zu unserer Anwendung
gehören, in separaten Namespaces bereitstellen. In diesem Beispiel gibt es zwei Mandanten mit
unterschiedlichen Namespaces. In jedem haben wir einige Beispielservices bereitgestellt (Order und
Product).
Jeder dieser Mandanten-Namespaces wird von dem oben angezeigten Registrierungsservice bereitgestellt.
Dieser nutzt Continuous Delivery-Services (wie AWS CodePipeline), um eine Pipeline zu starten, die den
Namespace erstellt, die Services bereitstellt, Mandantenressourcen (Datenbanken usw.) erstellt und das
Routing konfiguriert. Hier kommt der Ingress Controller ins Spiel. Jeder bereitgestellte Namespace erstellt
eine separate Ingress-Ressource für jeden Microservice in diesem Namespace. Dadurch kann Mandanten-
Datenverkehr in den geeigneten Mandanten-Namespace geleitet werden.
Namespaces schenken Ihnen zwar klare Grenzen zwischen den Mandantenressourcen in Ihrem Amazon
EKS-Cluster, diese Namespaces sind aber eher ein Gruppierungskonstrukt. Der Namespace alleine kann
nicht sicherstellen, dass Ihre Mandantenlasten vor mandantenübergreifendem Zugriff geschützt sind.
15SaaS Lens AWS Well-Architected Framework
Full-Stack-Isolation
Wir müssen verschiedene Sicherheitskonstrukte einführen, die den Zugriff eines in einem bestimmten
Namespace laufenden Mandanten beschränken, um so die Isolation unserer Amazon EKS-Umgebung
zu verbessern. Das Diagramm in Abbildung 6 ist eine umfassende Illustration eines Ansatzes, den Sie
übernehmen können, um die Erfahrung jedes Mandanten zu kontrollieren.
Abbildung 6: Isolieren von Mandantenressourcen
Hier werden zwei spezifische Konstrukte eingeführt. Auf Namespace-Ebene sehen Sie, dass wir separate
Pod-Sicherheitsrichtlinien erstellt haben. Es gibt native Kubernetes-Netzwerksicherheitsrichtlinien, die
einer Richtlinie hinzugefügt werden können. In diesem Beispiel werden diese Richtlinien verwendet, um
den Netzwerkverkehr zwischen Mandanten-Namespaces zu begrenzen. Dies ist ein grober Ansatz, um zu
verhindern, dass ein Mandant auf die Rechenressourcen eines anderen Mandanten zugreift.
Zusätzlich zur Sicherung der Namespaces müssen Sie auch sicherstellen, dass die Ressourcen, auf die
die in einem Namespace laufenden Services zugreifen, beschränkt werden. In diesem Beispiel haben wir
zwei Isolationsbeispiele. Der Order-Microservice verwendet ein Modell mit einer Tabelle pro Mandanten
(Silo) und hat IAM-Richtlinien eingerichtet, die den Zugriff auf einen bestimmten Mandanten beschränkt.
Der Product-Microservice verwendet ein Poolmodell, bei dem Mandantendaten vermischt werden, und
baut auf einer IAM-Richtlinie auf, die auf jedes Element angewendet wird, um den Mandantenzugriff zu
beschränken.
Full-Stack-Isolation
SaaS-Unternehmen wollen Skalierungseffekte nutzen, die entstehen, wenn Infrastrukturressourcen von
Mandanten geteilt werden. Gleichzeitig können Faktoren aus der realen Welt zu einer SaaS-Architektur
beitragen, bei der alle Mandanten in Ihrer Umgebung eine dedizierte (Silo-)Infrastruktur benötigen.
Compliance, „Noisy Neighbor“, mehrstufige Strategien und veraltete Technologien, sind einige der
zahlreichen Überlegungen, die Sie dazu bringen können, Mandanten ihre eigene Infrastruktur zu bieten.
Dies wird als Silo- oder Full-Stack-Isolation-SaaS bezeichnet.
Dieser Ansatz wird häufig mit einem Managed Service Provider (MSP) verwechselt, bei dem das Produkt
eines Unternehmens auf einmaliger Basis für einzelne Kunden installiert und verwaltet wird. Dieser
Ansatz hat zwar seine Daseinsberechtigung, lässt sich aber nicht mit den SaaS-Grundsätzen vereinbaren.
Der Schlüssel zu einem SaaS-Modell ist ein Wertsystem, in dem alle Mandanten über eine einzelne,
einheitliche Erfahrung verwaltet und geleitet werden. Das bedeutet, dass jeder Mandant die gleiche Version
der Software ausführt, alle Mandanten Bereitstellungen zur gleichen Zeit erhalten, das Onboarding für alle
nach dem gleichen Prozess verläuft und sie alle über eine einzelne operative Erfahrung verwaltet werden,
die für alle Mandanten gilt.
Dieser Ansatz bietet nicht die Kosteneffizienzen eines geteilten Infrastrukturmodells (Pool). Der verteilte
Aufbau kann ebenfalls dazu führen, dass die betrieblichen Vorgänge und die Bereitstellung komplexer
werden. Ein richtig aufgebautes Full-Stack-Modell kann dennoch die Agilitäts-, die Innovations- und die
betrieblichen Effizienzziele erreichen, die zentraler Bestandteil von SaaS sind.
Das Diagramm in Abbildung 7 bietet einen genaueren Überblick über das Full-Stack-Isolation-(Silo)-
Modell. Jede Mandantenumgebung in diesem Modell ist unkompliziert. Sie sehen hier, dass wir für
jeden Mandanten eine separate VPC bereitgestellt haben. Diese VPCs beinhalten den vollständigen
isolierten Stack, der von jedem Mandanten verwendet wird. Die Rechen- und Speicherkonstrukte
könnten aus jeder beliebigen Kombination von AWS-Services bestehen. Hier ist entscheidend, dass jede
Mandantenumgebung die gleiche Infrastrukturkonfiguration und die gleiche Version Ihres Produkts haben
sollte. Das Hinzufügen neuer Mandanten ist demnach so einfach wie die Bereitstellung einer weiteren VPC
mit demselben Infrastruktur-Fußabdruck für jeden Mandanten.
Sie werden feststellen, dass dieses Modell Amazon Route 53 verwendet, um den eingehenden Verkehr
in die richtige VPC weiterzuleiten. Das Routing baut auf einem Modell auf, in dem jedem Mandanten
16SaaS Lens AWS Well-Architected Framework
Einheitliches Onboarding, Management und Vorgänge
Subdomänen zugewiesen werden. Das ist in SaaS-Umgebungen ein sehr häufiges Muster. Dieses Routing
kann erreicht werden, indem die Inhalte eines JWT-Mandantentoken untersucht, ihr Mandantenkontext
ermittelt und Routing-Regeln über einen eingefügten Mandanten-Header ausgelöst werden. Dieser Ansatz
kann jedoch dazu führen, dass Kontolimits erweitert werden, und muss unter Umständen optimiert werden,
um die Latenz einer Laufzeitauflösung der Identität eines Mandanten auszugleichen. Dennoch ist dies eine
geeignete Option für einige SaaS-Umgebungen.
Abbildung 7: Full-Stack (Silo)-Isolation
Dieses Beispiel zeigt zwar ein Modell mit einer VPC pro Mandanten, es gibt aber noch andere
Architekturen, mit denen das Full-Stack-Modell implementiert werden kann. Einige Unternehmen werden
sich für ein Modell mit einem Konto pro Mandanten entscheiden, bei dem jede Mandantenumgebung in
einem separaten bereitgestellten Konto bereitgestellt wird. Die Entscheidung für eine Option hängt von der
Anzahl der Mandanten ab, die Sie unterstützen müssen, sowie von der Management-Gesamterfahrung, die
Sie bieten möchten. In einigen Fällen übersteigt die Anzahl der zu unterstützenden Mandanten die Anzahl
der VPCs, die in einem AWS-Konto erstellt werden können.
Einheitliches Onboarding, Management und Vorgänge
Die realen SaaS-Elemente des Full-Stack-Isolation-(Silo)-Modells sind von Bedeutung, wenn wir uns
mit dem Onboarding, der Verwaltung und den Vorgängen dieser Erfahrung befassen. Um den vollen
Mehrwert von SaaS auszuschöpfen, muss dieses Modell eine Reihe von Services einführen, mit denen alle
Mandantenumgebungen verwaltet und geleitet werden können.
Das Diagramm in Abbildung 8 bietet einen Überblick über diese zusätzlichen Serviceebenen. Wir
führen hier einen separaten Satz von Services ein, die auf die Bedürfnisse der Administrations- und
Managementerfahrung des SaaS-Anbieters zugeschnitten sind.
17Sie können auch lesen
