Architekturansätze für Steuerungsebenen in Multitenant-Lösungen

Steuerungsebenen sind ein wichtiger Bestandteil von Software as a Service (SaaS) und Multitenant-Lösungen. Sie helfen dabei, eine Lösung im großen Maßstab zu verwalten. In der Regel besteht eine Steuerungsebene aus zwei Hauptkomponenten:

• Der Mandantenkatalog, in dem wichtige Informationen zu Mandanten gespeichert werden, einschließlich der folgenden Informationen:

  • Mandantenkonfiguration
  • Für Mandantenressourcen bereitgestellte SKUs
  • Welchen Bereitstellungsstempeln die Mandanten zugewiesen sind

• Prozesse, die Änderungen an der Umgebung verwalten. Mandantenlebenszyklusereignisse lösen diese Prozesse aus. Beispiele hierfür sind die Aufnahme von Mandanten, die Abmeldung von Mandanten und die erforderliche regelmäßige Wartung

Eine Steuerebene fungiert als Anwendung. Sie müssen Ihre Steuerebene mit demselben Rigor und derselben Sorgfalt entwerfen, die Sie auf andere Teile Ihrer Lösung anwenden. Weitere Informationen dazu, was eine Steuerebene ist, warum es wichtig ist, und Entwurfsüberlegungen finden Sie unter Überlegungen zu mehrinstanzenfähigen Steuerebenen.

In diesem Artikel werden Ansätze beschrieben, mit denen Sie eine Steuerebene entwerfen und erstellen können. Jeder Ansatz ist gültig, aber eine andere Architektur außerhalb dieser Anleitung eignet sich möglicherweise besser für Ihr spezifisches Szenario.

Zu berücksichtigende Ansätze und Muster

In der folgenden Tabelle sind die Unterschiede zwischen manuellen, Low-Code- und benutzerdefinierten Ansätzen für eine Kontrollebene zusammengefasst.

Überlegung	Handbuch	Low-Code	Kundenspezifisch
Betriebsaufwand	High	Low-medium	Niedrig
Häufigkeit von Lebenszyklusereignissen, die der Ansatz unterstützt	Selten	Gelegentlich – oft	Oft
Zeit und Komplexität zur Implementierung	Niedrig	Mittel	High
Verantwortlichkeiten für die Wartung der Steuerungsebene	Niedrig	Mittel	High
Prüfbarkeit	Niedrig	Mittel	High
Risiko von Inkonsistenzen	High	Mittel-niedrig	Niedrig

Manuelle Prozesse

Sie müssen nicht immer eine vollständig automatisierte Kontrollebene aufbauen, insbesondere wenn Sie mit nur wenigen Mandanten beginnen.

Sie können Ihren Mandantenkatalog an einem zentralen Speicherort beibehalten, z. B. an einer Excel-Arbeitsmappe oder einer JSON-Datei, die an einem Speicherort gespeichert ist, auf den Ihr Team zugreifen kann. Unabhängig vom Format sollten Sie die Informationen auf strukturierte Weise speichern, damit Sie programmgesteuert mit den Daten arbeiten können.

Hinweis

Eine manuelle Kontrollebene eignet sich gut als Ausgangspunkt für die Verwaltung Ihrer mehrinstanzenfähigen Anwendung, ist aber nur für weniger als 10 Mandanten geeignet. Der Verwaltungsaufwand und das Risiko von Inkonsistenzen erhöhen sich mit jedem manuell integrierten Mandanten. Verwenden Sie diesen Ansatz nur, wenn Sie nur wenige Mandanten haben und kein automatisches oder Self-Service-Onboarding benötigen.

Berücksichtigen Sie die folgenden Faktoren für Prozesse wie Mandanten-Onboarding- und Wartungsaktivitäten:

• Erstellen Sie Nach Möglichkeit Skripts oder automatisierte Pipelines, auch wenn Sie sie manuell ausführen. Skripts oder Pipelines helfen dabei, die Schritte für jeden Mandanten konsistent auszuführen.

• Für Aufgaben, die Sie anfangs nicht skripten können, dokumentieren Sie den Prozess in klaren, detaillierten Schritten. Erläutern Sie, wie und warum. Diese Informationen helfen anderen, die Aufgabe in Zukunft zu automatisieren.

Das folgende Diagramm zeigt einen manuellen Prozessansatz für eine anfängliche Steuerungsebene.

Das Diagramm verfügt über zwei Hauptabschnitte, eine Steuerebene und eine Datenebene. Die Steuerebene enthält eine Webanwendung, einen Vertriebsmitarbeiter, eine Excel-Datei, einen Techniker und ein Skript. Die Datenebene enthält zwei vorhandene Mandanten und einen neuen Mandanten. Jeder Mandant verfügt über eine Anwendung und eine SQL-Datenbank. Der Ablauf beginnt mit einem externen Kunden, der sich anmeldet, indem er mit einem Verkäufer spricht. Der Verkäufer fügt die Mandanteninformationen in eine Excel-Datei ein. Ein Techniker liest die Mandanteninformationen und führt ein Bereitstellungsskript aus. Das Skript liest die Informationen und stellt die Umgebung in Azure Resource Manager bereit und konfiguriert sie. Die Ressourcenverwaltung verweist auf den neuen Mandanten in der Datenebene.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Vorteile eines manuellen Ansatzes

• Leicht: Dokumentation, Skripts und Pipelines sind einfach zu entwickeln und zu ändern. Diese Flexibilität macht sie ideal, wenn Sie Ihre Prozesse gestalten, da Sie diese rasch iterieren und weiterentwickeln können.

• Niedrige Kosten: Die Wartung und Ausführung eines manuellen Ansatzes ist kostengünstig.

• Prozessüberprüfung: Ein manueller Ansatz dient als Konzeptnachweis. Es ermöglicht Ihnen, Ihre Wartungsstrategie zu testen und zu bestätigen, bevor Sie Zeit und Ressourcen zur Erstellung der vollständigen Automatisierung übernehmen.

Nachteile eines manuellen Ansatzes

• Fehlende Kontrolle: Dieser Ansatz stützt sich auf alle Beteiligten, die das richtige tun. Jemand kann von den vorgeschriebenen Prozessen abweichen, entweder versehentlich oder absichtlich. Jede Variante des Prozesses erhöht das Risiko von Inkonsistenzen in Ihrer Umgebung, was das laufende Management erschwert.

• Herausforderungen bei der Zugriffssteuerung: Dieser Ansatz erfordert häufig einen breit angelegten, stark eingeschränkten Zugriff auf Operatoren Ihrer Lösung. Dieser Zugriff erschwert das Erzwingen von bewährten Methoden für die Segmentierung des Zugriffs .

• Skalierbarkeit: Die zum Ausführen manueller Prozesse erforderliche Arbeit skaliert mit der Anzahl der Mandanten, die Sie verwalten müssen.

• Testbarkeit: Manuelle Prozesse sind schwierig zu überprüfen und zu testen.

Wann sollten Sie sich von einem manuellen Ansatz wegbewegen?

• Wenn Ihr Team mit der Arbeitsbelastung nicht Schritt halten kann, die erforderlich ist, um die Anwendung zu warten. Dieses Szenario tritt häufig auf, wenn die Anzahl der Mandanten einen verwaltbaren Schwellenwert überschreitet, in der Regel zwischen 5 und 10 Mandanten.

• Wenn Sie das Mandantenwachstum über eine kritische Anzahl von Mandanten hinaus erwarten und sich auf die Anforderungen der Verwaltung einer größeren Anzahl von Mandanten vorbereiten müssen.

• Wenn Sie das Risiko von Inkonsistenzen mindern müssen. Beispielsweise können Sie Fehler beobachten, die auftreten, weil jemand die Prozesse nicht richtig oder aufgrund unklarer Prozesse verfolgt. Das Risiko von Inkonsistenzen steigt, je mehr Mandanten manuell an Bord genommen werden und je größer Ihr Team wird.

Low-Code-Steuerungsebene

Eine Low-Code- oder No-Code-Kontrollebene verwendet eine Plattform, die für die Automatisierung von Geschäftsprozessen und die Verfolgung von Informationen entwickelt wurde. Viele Plattformen, einschließlich Microsoft Power Platform, ermöglichen es Ihnen, diese Aufgaben auszuführen, ohne benutzerdefinierten Code zu schreiben.

Wenn Sie Microsoft Power Platform verwenden, können Sie Ihren Mandantenkatalog in Dynamics 365, Dataverse oder Microsoft 365 speichern. Sie können auch denselben Mandantenkatalog beibehalten, den Sie für Ihre manuellen Prozesse verwenden, wenn Sie sich nicht vollständig für die Automatisierung aller Vorgänge verpflichten möchten.

Für das Mandanten-Onboarding und die Wartung können Sie Power Automate verwenden, um Workflows auszuführen, die Mandantenverwaltung ausführen, Mandanten konfigurieren und Pipelines oder API-Aufrufe auslösen. Power Automate kann auf Änderungen an Ihrem Mandantenkatalog überwachen, wenn er Zugriff auf die Daten hat. Wenn Sie einen manuellen Mandantenkatalog verwenden, können Sie Power Automate-Workflows manuell auslösen. Fügen Sie manuelle Genehmigungsschritte in Ihre Workflows ein, wenn Sie ein Teammitglied zum Überprüfen oder Ausführen von Aufgaben benötigen, die Sie nicht vollständig automatisieren können.

Dieser Ansatz unterstützt auch die Self-Service-Registrierung für Ihre Kunden. Ihre Webanwendung kann Mandantenkatalogeinträge automatisch ohne menschliche Beteiligung erstellen.

Das folgende Diagramm zeigt, wie Sie microsoft Power Platform verwenden, um eine Steuerungsebene zu erstellen, die über die Self-Service-Registrierung verfügt.

Das Diagramm verfügt über zwei Hauptabschnitte, eine Steuerebene und eine Datenebene. Die Steuerebene enthält eine Webanwendung, eine Dataverse-Tabelle und einen Power Automate-Workflow. Die Datenebene enthält zwei vorhandene Mandanten und einen neuen Mandanten. Jeder Mandant verfügt über eine Anwendung und eine SQL-Datenbank. Der Ablauf beginnt mit einem externen Kunden, der sich mit einer Web-App anmeldet. Die Web-App fügt die Mandanteninformationen in eine Dataverse-Tabelle ein. Diese Änderungen lösen den Power Automate-Workflow aus, der die Umgebung in Azure Resource Manager bereitstellt und konfiguriert. Die Ressourcenverwaltung verweist auf den neuen Mandanten in der Datenebene.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Vorteile eines Low-Code-Ansatzes

• Leicht: Sie können schnell und erschwinglich Low-Code-Workflows erstellen und mit den umgebenden Systemen verbinden.

• Verwendet Plattformtools: Sie können systemeigene Plattformfeatures verwenden, um Daten zu speichern, Verwaltungsportale für Ihr Team zu erstellen und Workflows zu überwachen. Dieser Ansatz reduziert die Notwendigkeit, benutzerdefinierte Komponenten zu entwickeln und zu verwalten.

• Anpassbar: Sie können Workflows bei Bedarf mit benutzerdefiniertem Code erweitern. Power Automate kann beispielsweise einen Bereitstellungsworkflow in GitHub-Aktionen auslösen oder Azure Functions aufrufen, um Ihren Code auszuführen. Diese Flexibilität erleichtert eine schrittweise Automatisierungsimplementierung.

• Geringer Aufwand: Low-Code-Dienste werden in der Regel vollständig verwaltet, sodass Sie keine Infrastruktur verwalten müssen.

Nachteile eines Low-Code-Ansatzes

• Erforderliche Expertise: Low-Code-Plattformen erfordern häufig proprietäre Kenntnisse, um Prozesse effektiv zu erstellen und zu verwalten. Viele Organisationen verwenden diese Tools bereits, damit Ihr Team möglicherweise über das erforderliche Fachwissen verfügt, oder Sie müssen Schulungen bereitstellen.

• Management: Es kann schwierig sein, die Verwaltung großer Mengen an Low-Code-Konfigurationen zu bewältigen.

• Testbarkeit: In einer verwalteten Plattform ist das Erstellen eines typischen DevOps-Prozesses zum Testen und Fördern von Änderungen schwieriger. In der Regel nehmen Sie Änderungen über die Konfiguration vor, nicht durch Code.

• Entwurf: Low-Code-Plattformen verwalten häufig nicht funktionsfähige Anforderungen, müssen aber dennoch überprüfen, ob sie Ihren Standards entsprechen. Bewerten Sie sorgfältig, wie sie diese Anforderungen erfüllen, z. B. Sicherheit und Zuverlässigkeit.

Wann man in Erwägung ziehen sollte, sich von einem Low-Code-Ansatz zu entfernen

Schließlich werden Ihre Anforderungen möglicherweise so komplex, dass Sie sie nicht sinnvoll in eine Low-Code-Lösung integrieren können. Wenn Sie die Werkzeugeinschränkungen umgehen müssen, um Ihre Anforderungen zu erfüllen, sollten Sie sich von einer verwalteten Lösung hin zu einer benutzerdefinierten Steuerungsebene bewegen.

Benutzerdefinierte Steuerungsebene

Sie können eine vollständig angepasste Steuerungsebene erstellen. Diese Option bietet die größte Flexibilität und Leistung, erfordert aber auch die meiste Arbeit.

Der Mandantenkatalog wird in der Regel in einer Datenbank gespeichert. Sie arbeiten nicht direkt mit dem Katalog. Stattdessen verwalten Sie sie über eine administrative Schnittstelle, z. B. eine benutzerdefinierte Anwendung oder ein System wie die CRM-Anwendung (Customer Relationship Management) Ihrer Organisation.

In der Regel erstellen Sie eine Reihe von Komponenten der Steuerungsebene, um Ihre Mandantenverwaltungsfunktionen zu unterstützen. Diese Komponenten können ein Verwaltungsportal oder eine andere Benutzeroberfläche, eine API und Hintergrundverarbeitungskomponenten enthalten. Sofern Sie Code oder Infrastruktur bereitstellen müssen, wenn Ereignisse im Lebenszyklus eines Mandanten eintreten, können Sie Ihrer Kontrollebene auch Bereitstellungspipelines hinzufügen.

Stellen Sie sicher, dass bei zeitintensiven Bearbeitungen geeignete Tools verwendet werden. Sie können beispielsweise dauerhafte Funktionen oder Azure Logic Apps für Komponenten verwenden, die das Onboarding des Mandanten koordinieren, Bereitstellungen verwalten oder eine Kommunikation mit externen Systemen erfordern.

Wie der Low-Code-Ansatz ermöglicht Ihnen dieser Ansatz, Ihren Kunden eine Self-Service-Registrierung zu ermöglichen. Ihre Webanwendung kann Ihrem Mandantenkatalog datensätze direkt hinzufügen, ohne dass ein menschliches Eingreifen möglich ist.

Das folgende Diagramm zeigt, wie Sie eine einfache benutzerdefinierte Steuerungsebene erstellen, die die Self-Service-Registrierung bereitstellt.

Dieses Diagramm enthält zwei Hauptabschnitte, eine Steuerebene und eine Datenebene. Die Steuerebene enthält eine Webanwendung, azure Service Bus, dauerhafte Funktionen und SQL-Datenbank. Die Datenebene enthält zwei vorhandene Mandanten und einen neuen Mandanten. Jeder Mandant verfügt über eine Anwendung und eine SQL-Datenbank. Der Ablauf beginnt mit einem externen Kunden, der sich mit einer Web-App anmeldet. Die Web-App speichert die Mandanteninformationen in der Azure SQL-Datenbank und sendet eine Benachrichtigung an Service Bus. Diese Benachrichtigung löst dauerhafte Funktionen aus, die die Umgebung in Azure Resource Manager bereitstellen und konfigurieren. Die Ressourcenverwaltung verweist auf den neuen Mandanten in der Datenebene. Dauerhafte Funktionen speichern die metadaten der neuen Mandantenumgebung in der SQL-Datenbank.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Vorteile eines benutzerdefinierten Ansatzes

• Volle Flexibilität und Anpassbarkeit: Sie haben die vollständige Kontrolle über die Funktionalität Ihrer Steuerebene und können sie ändern, wenn sich Ihre Anforderungen ändern.

• Testbarkeit: Sie können einen Standardlebenszyklus für die Softwareentwicklung für Ihre Steuerungsebenenanwendung verwenden und typische Ansätze für Tests und Bereitstellungen implementieren, genau wie bei Ihren Hauptanwendungen.

Nachteile eines benutzerdefinierten Ansatzes

• Wartungsaufgaben: Dieser Ansatz erfordert mehr Wartungsaufwand, da Sie alles selbst erstellen müssen. Eine Steuerungsebene ist ebenso wichtig wie jeder andere Teil Ihrer Anwendung. Sie müssen bei der Entwicklung, beim Testen und beim Betrieb Ihrer Steuerebene sorgfältig vorgehen, um ihre Zuverlässigkeit und Sicherheit zu gewährleisten.

Hybridansätze

Sie können auch einen Hybridansatz in Betracht ziehen, der manuelle und automatisierte Systeme kombiniert. Oder Sie können eine verwaltete Plattform wie Microsoft Power Platform verwenden und mit benutzerdefinierten Anwendungen erweitern. Erwägen Sie die Implementierung eines Hybridansatzes, wenn Sie die Flexibilität einer benutzerdefinierten Steuerungsebene benötigen, aber kein vollständig benutzerdefiniertes System erstellen und verwalten möchten. Denken Sie jedoch daran, dass automatisierte Anpassungen an Ihre manuellen Prozesse oder verwaltete Plattform so komplex werden können wie ein vollständig angepasstes System. Wenn Ihr Hybridansatz schwierig zu verwalten ist, ziehen Sie in Betracht, zu einem vollständig angepassten System zu wechseln.

Schrittweise Implementierung

Auch wenn Sie schließlich Ihre Steuerungsebene automatisieren möchten, müssen Sie nicht unbedingt mit diesem Ansatz beginnen. In den anfangsphasen soll ein gemeinsamer Ansatz der Anwendungsentwicklung mit einer manuellen Steuerungsebene beginnen. Wenn Ihre Anwendung fortschreitet und mehr Mandanten integriert, identifizieren Sie Engpassbereiche und automatisieren Sie diese nach Bedarf. Diese Verschiebung bewegt Sie in Richtung eines Hybridansatzes. Während Sie weitere Aufgaben automatisieren, können Sie zu einer vollständig automatisierten Steuerungsebene wechseln.

Zu vermeidende Antimuster

• Zu langes Vertrauen auf manuelle Prozesse: Manuelle Prozesse funktionieren gut, wenn Sie mit dem Start beginnen oder über eine geringe Anzahl von Mandanten verfügen und eine einfache Verwaltung erfordern. Sie müssen jedoch planen, wie Sie bei der Erweiterung auf eine automatisierte Lösung skalieren können. Wenn Sie weitere Teammitglieder einstellen müssen, um mit der Nachfrage Ihrer manuellen Prozesse schrittzuhalten, sollten Sie die Automatisierung von Teilen Ihrer Steuerebene in Betracht ziehen.

• Verwenden unangemessener Tools für lange ausgeführte Workflows: Verwenden Sie keine Tools, die Laufzeitbeschränkungen aufweisen, z. B. Standard-Azure-Funktionen oder synchrone API-Aufrufe, für lange ausgeführte Vorgänge wie Azure Resource Manager-Bereitstellungen oder mehrstufige Orchestrierung. Verwenden Sie stattdessen Tools, die lange ausgeführte Workflows oder Sequenzen von Vorgängen unterstützen, z. B. Logic Apps und Durable Functions. Weitere Informationen finden Sie unter Azure Functions Performance and Reliability und Asynchrones Request-Reply Muster.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautoren:

• John Downs | Leitender Softwareentwickler
• Landon Pierce | Customer Engineer

Andere Mitwirkende:

• Mick Alberts | Technischer Autor
• Bohdan Cherchyk | Senior Customer Engineer
• Arsen Vladimirskiy | Principal Customer Engineer

Um nicht-öffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.

Nächste Schritte

• Microsoft Power Platform
• Power Automate

Verwandte Ressourcen

• Architekturüberlegungen für Steuerungsebenen in einer Mehrinstanzenlösung
• Architekturansätze für eine Mehrinstanzenlösung