Steuerungsebene im Vergleich zur Anwendungsebene - Grundlagen der SaaS-Architektur

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.

Steuerungsebene im Vergleich zur Anwendungsebene

Das vorherige Diagramm bietet eine konzeptionelle Ansicht der Kernkonzepte der SaaS-Architektur. Lassen Sie uns nun näher darauf eingehen und besser definieren, wie sich Ihre SaaS-Umgebung in verschiedene Ebenen aufgeteilt hat. Dieses klarere Bild der Grenzen zwischen SaaS-Konzepten wird es einfacher machen, die beweglichen Teile einer SaaS-Lösung zu beschreiben.

Das folgende Diagramm unterteilt Ihre SaaS-Umgebung in zwei verschiedene Ebenen. Auf der rechten Seite befindet sich die Steuerungsebene. Diese Seite des Diagramms enthält alle Funktionen und Dienste, die für das Onboarding, die Authentifizierung, die Verwaltung, den Betrieb und die Analyse einer Multi-Tenant-Umgebung verwendet werden.

Ein Diagramm, das die Steuerungsebene im Vergleich zur Anwendungsebene darstellt.

Steuerungsebene im Vergleich zur Anwendungsebene

Diese Steuerungsebene ist die Grundlage für jedes mehrinstanzenfähige SaaS-Modell. Jede SaaS-Lösung — unabhängig von der Anwendungsbereitstellung und dem Isolationsschema — muss die Services beinhalten, mit denen Sie Ihre Mandanten über ein einziges, einheitliches Erlebnis verwalten und betreiben können.

Innerhalb der Kontrollebene haben wir dies weiter in zwei verschiedene Elemente unterteilt. Die Kerndienste hier stellen die Sammlung von Diensten dar, die zur Orchestrierung Ihres Multi-Tenant-Erlebnisses verwendet werden. Wir haben einige der gängigen Beispiele für Dienste aufgeführt, die normalerweise Teil des Kerns sind, wobei wir berücksichtigen, dass die Kerndienste für jede SaaS-Lösung etwas variieren können.

Sie werden auch feststellen, dass wir eine separate Administrationsanwendung zeigen. Dies stellt die Anwendung (eine Webanwendung, eine Befehlszeilenschnittstelle oder eine API) dar, die von einem SaaS-Anbieter zur Verwaltung seiner Multi-Tenant-Umgebung verwendet werden könnte.

Ein wichtiger Vorbehalt ist, dass es sich bei der Steuerungsebene und ihren Diensten nicht um mehrere Mandanten handelt. Die Funktionalität stellt nicht die tatsächlichen funktionalen Attribute Ihrer SaaS-Anwendung bereit (die mehrinstanzenfähig sein muss). Wenn Sie sich beispielsweise einen der Kerndienste ansehen, werden Sie keine Tenant Isolation und die anderen Konstrukte finden, die Teil Ihrer Multi-Tenant-Anwendungsfunktionalität sind. Diese Dienstleistungen stehen allen Mietern weltweit zur Verfügung.

Die linke Seite des Diagramms bezieht sich auf die Anwendungsebene einer SaaS-Umgebung. Hier befindet sich die Multi-Tenant-Funktionalität Ihrer Anwendung. Was im Diagramm erscheint, muss etwas vage bleiben, da jede Lösung je nach den Anforderungen Ihrer Domain, dem Platzbedarf Ihrer Technologie usw. unterschiedlich eingesetzt und aufgeteilt werden kann.

Die Anwendungsdomäne ist in zwei Elemente unterteilt. Es gibt die SaaS-Anwendung, die das Mandantenerlebnis/die Anwendung für Ihre Lösung darstellt. Dies ist die Oberfläche, die Mieter berühren, um mit Ihrer SaaS-Anwendung zu interagieren. Dann gibt es die Backend-Services, die die Geschäftslogik und die Funktionselemente einer SaaS-Lösung darstellen. Dies können Microservices oder andere Pakete Ihrer Anwendungsdienste sein.

Sie werden auch feststellen, dass wir die Bereitstellung aufgeteilt haben. Dies wird getan, um die Tatsache hervorzuheben, dass jede Bereitstellung von Ressourcen für Mieter während des Onboardings Teil dieser Anwendungsdomäne wäre. Einige könnten argumentieren, dass dies in die Steuerungsebene gehört. Wir haben es jedoch in die Anwendungsdomäne aufgenommen, da die Ressourcen, die es bereitstellen und konfigurieren muss, direkter mit Diensten verbunden sind, die auf der Anwendungsebene erstellt und konfiguriert werden.

Wenn Sie dies in verschiedene Ebenen aufteilen, ist es einfacher, über die Gesamtlandschaft einer SaaS-Architektur nachzudenken. Noch wichtiger ist, dass es die Notwendigkeit einer Reihe von Diensten unterstreicht, die völlig außerhalb des Funktionsumfangs Ihrer Anwendung liegen.