Architekturansätze für Mandantenintegration und Datenzugriff

Es ist typisch, dass Systeme zusammen integriert werden, auch über Organisationsgrenzen hinweg. Wenn Sie eine mehrinstanzenfähige Lösung erstellen, müssen Sie möglicherweise Daten zurück an die Systeme Ihrer Mandanten senden oder Daten von diesen Systemen empfangen. In diesem Artikel werden wichtige Überlegungen und Ansätze für die Architektur und die Entwicklung von Integrationen für eine mehrinstanzenfähige Lösung beschrieben.

Wichtige Überlegungen und Anforderungen

Richtung des Datenflusses

Es ist wichtig, die Richtung Ihrer Datenflüsse zu verstehen. Die Datenflussrichtung wirkt sich auf verschiedene Aspekte Ihrer Architektur aus, z. B. die Verwaltung der Identität und der Netzwerktopologie Ihrer Lösung. Es gibt zwei allgemeine Datenflüsse:

• Exportieren, was bedeutet, dass Daten von Ihrem mehrinstanzenfähigen System zu ihren einzelnen Mandantensystemen fließen.

• Importieren, was bedeutet, dass Daten aus den Systemen Ihrer Mandanten in Ihr mehrinstanzenfähiges System gelangen.

Es ist auch wichtig, die Richtung des Netzwerkdatenflusses zu berücksichtigen, die nicht notwendigerweise der logischen Datenflussrichtung entspricht. Sie können z. B. eine ausgehende Verbindung mit einem Mandanten initiieren, damit Sie die Daten aus dem System des Mandanten importieren können.

Vollzugriff oder benutzerdelegierte Zugriff

In vielen Systemen ist der Zugriff auf bestimmte Daten auf einzelne Benutzer beschränkt. Die Daten, auf die ein Benutzer zugreift, können sich von denen unterscheiden, auf die ein anderer Benutzer zugreift. Es ist wichtig zu überlegen, ob Sie mit vollständigen Datensätzen arbeiten oder ob die daten, die Sie importieren oder exportieren, von den Zugriffsberechtigungen jedes Benutzers abhängig sind.

Power BI ist beispielsweise ein mehrinstanzenfähiger Dienst, der Berichte und Business Intelligence über kundeneigene Datenspeicher bereitstellt. Wenn Sie Power BI konfigurieren, konfigurieren Sie Datenquellen, um Daten aus Datenbanken, APIs und anderen Datenspeichern abzurufen. Sie können Datenspeicher auf zwei verschiedene Arten konfigurieren:

• Importieren Sie alle Daten aus dem zugrunde liegenden Datenspeicher. Dieser Ansatz erfordert, dass Power BI Anmeldeinformationen für eine Identität empfängt, die über Berechtigungen für den vollständigen Datenspeicher verfügt. Nach dem Importieren der Daten konfigurieren Power BI-Administratoren Berechtigungen unabhängig voneinander. Power BI erzwingt diese Berechtigungen.

• Importieren Einer Teilmenge von Daten aus dem zugrunde liegenden Datenspeicher basierend auf den Berechtigungen eines Benutzers. Wenn ein Benutzer eine Datenquelle erstellt, verwendet er seine Anmeldeinformationen und die zugehörigen Berechtigungen. Die genaue Teilmenge der Daten, die Power BI importiert, hängt von der Zugriffsebene des Benutzers ab, der die Datenquelle erstellt.

Beide Ansätze weisen gültige Anwendungsfälle auf, daher ist es wichtig, die Anforderungen Ihrer Mandanten klar zu verstehen.

Wenn Sie mit vollständigen Datensätzen arbeiten, behandelt das Quellsystem das Zielsystem effektiv als vertrauenswürdiges Subsystem. Für diese Art der Integration sollten Sie auch die Verwendung einer Workloadidentität anstelle einer Benutzeridentität berücksichtigen. Eine Workloadidentität ist eine Systemidentität, die keinem einzelnen Benutzer entspricht. Die Workloadidentität wird einer hohen Berechtigung für die Daten im Quellsystem gewährt.

Wenn Sie mit benutzerbezogenen Daten arbeiten, müssen Sie möglicherweise einen Ansatz wie die Delegierung verwenden, um auf die richtige Teilmenge von Daten aus dem Datensatz zuzugreifen. Anschließend erhält das Zielsystem effektiv dieselbe Berechtigung wie ein bestimmter Benutzer. Weitere Informationen finden Sie unter Delegierter Benutzerzugriff. Wenn Sie Stellvertretung verwenden, überlegen Sie, wie Sie Szenarien behandeln können, in denen ein Benutzer nicht bereitgestellt wird oder seine Berechtigungen geändert werden.

Echtzeitintegrationen oder Batchintegrationen

Überlegen Sie, ob Sie Planen, Echtzeitdaten zu verwenden oder die Daten in Batches zu senden.

Bei Echtzeitintegrationen sind die folgenden Ansätze üblich:

• Anforderungsantwort ist der Ort, an dem ein Client eine Anforderung an einen Server initiiert und eine Antwort empfängt. In der Regel werden Anforderungsantwortintegrationen mithilfe von APIs oder Webhooks implementiert. Anforderungen sind möglicherweise synchron, wo sie auf die Bestätigung und eine Antwort warten. Alternativ können Anforderungen asynchron sein und so etwas wie das asynchrone Request-Reply Muster verwenden, um auf eine Antwort zu warten.

• Lose gekoppelte Kommunikation wird häufig durch Messaging-Komponenten ermöglicht, die dazu konzipiert sind, Systeme lose zu koppeln. Azure Service Bus bietet beispielsweise Nachrichtenwarteschlangenfunktionen, azure Event Grid und Azure Event Hubs bieten Ereignisfunktionen. Diese Komponenten werden häufig als Teil von Integrationsarchitekturen verwendet.

Im Gegensatz dazu werden Batchintegrationen häufig über einen Hintergrundauftrag verwaltet, der zu bestimmten Tageszeiten ausgelöst werden kann. Batchintegrationen erfolgen häufig über einen Stagingspeicherort wie einen Blob-Speichercontainer, da die ausgetauschten Datensätze groß sein können.

Datenvolume

Es ist wichtig, die Menge der Daten zu verstehen, die Sie durch eine Integration austauschen, da diese Informationen Ihnen bei der Planung der Gesamtkapazität des Systems helfen. Wenn Sie die Kapazität Ihres Systems planen, denken Sie daran, dass unterschiedliche Mandanten möglicherweise unterschiedliche Datenmengen haben, die ausgetauscht werden sollen.

Bei Echtzeitintegrationen können Sie das Volumen als Die Anzahl der Transaktionen über einen bestimmten Zeitraum messen. Bei Batchintegrationen können Sie entweder die Anzahl der ausgetauschten Datensätze oder die Datenmenge in Bytes messen.

Datenformate

Wenn Daten zwischen zwei Parteien ausgetauscht werden, ist es wichtig, dass sie beide das Format und die Struktur der Daten deutlich verstehen. Berücksichtigen Sie die folgenden Teile des Datenformats:

• Das Dateiformat, z. B. JSON, Parquet, CSV oder XML

• Das Schema, z. B. die Liste der enthaltenen Felder, Datumsformate und Nullierbarkeit von Feldern

Wenn Sie mit einem mehrinstanzenfähigen System arbeiten, standardisieren Sie, wenn möglich, dasselbe Datenformat und verwenden Sie es für alle Ihre Mandanten. Dieser Ansatz hilft Ihnen zu vermeiden, Ihre Integrationskomponenten für die Anforderungen der einzelnen Mandanten anzupassen und erneut zu testen. Einige Szenarien erfordern jedoch unterschiedliche Datenformate, um mit verschiedenen Mandanten zu kommunizieren, daher müssen Sie möglicherweise mehrere Integrationen implementieren. Einen Ansatz, der diese Art von Szenario vereinfachen kann, finden Sie unter Komponenten für die komponierbare Integration.

Zugriff auf Mietersysteme

Bei einigen Integrationen müssen Sie eine Verbindung mit den Systemen oder Datenspeichern Ihres Mandanten herstellen. Wenn Sie eine Verbindung mit den Systemen Ihres Mandanten herstellen, müssen Sie sowohl die Netzwerk- als auch die Identitätskomponenten der Verbindung sorgfältig berücksichtigen.

Netzwerkzugriff

Erwägen Sie die Netzwerktopologie für den Zugriff auf das System Ihres Mandanten, die möglicherweise die folgenden Optionen enthalten:

• Internetverbindungen können Bedenken hinsichtlich der Sicherung der Verbindung und verschlüsselung der Daten auslösen. Bestimmen Sie, wie die Verbindung gesichert und die Daten verschlüsselt werden, wenn Sie eine Verbindung über das Internet herstellen. Wenn Ihre Mandanten den Zugriff basierend auf Ihren IP-Adressen einschränken möchten, stellen Sie sicher, dass die von Ihrer Lösung genutzten Azure-Dienste statische IP-Adressen für ausgehende Verbindungen unterstützen können. Erwägen Sie z. B. die Verwendung des Azure NAT-Gateways , um bei Bedarf statische IP-Adressen bereitzustellen. Wenn Sie ein VPN benötigen, überlegen Sie, wie Sie Schlüssel sicher mit Ihren Mandanten austauschen.

• Agents, die in der Umgebung eines Mandanten bereitgestellt werden, können einen flexiblen Ansatz bieten. Agenten können Ihnen auch dabei helfen, dass Ihre Mandanten keine eingehenden Verbindungen zulassen müssen.

• Relays, z. B. Azure Relay, bieten auch einen Ansatz, um eingehende Verbindungen zu vermeiden.

Weitere Informationen finden Sie unter Networking-Ansätze für mehrinstanzenfähige Mandanten.

Authentifizierung

Überlegen Sie, wie Sie sich bei jedem Mandanten authentifizieren, wenn Sie eine Verbindung initiieren. Berücksichtigen Sie die folgenden Ansätze:

• Geheime Informationen, z. B. API-Schlüssel oder Zertifikate. Es ist wichtig zu planen, wie die Anmeldeinformationen Ihrer Mandanten sicher verwaltet werden sollen. Das Leck der Mandantengeheimnisse könnte zu einem schwerwiegenden Sicherheitsvorfall führen, der potenziell viele Mandanten betreffen kann.

• Microsoft Entra-Token, bei denen Sie ein Token verwenden, das das Microsoft Entra-Verzeichnis des Mandanten ausgibt. Das Token kann direkt an Ihre Workload ausgestellt werden, indem Sie eine mehrstufige Microsoft Entra-Anwendungsregistrierung oder einen bestimmten Dienstprinzipal verwenden. Alternativ kann Ihre Workload eine delegierte Berechtigung anfordern, um im Namen eines bestimmten Benutzers im Verzeichnis des Mandanten auf Ressourcen zuzugreifen.

Je nachdem, welchen Ansatz Sie auswählen, stellen Sie sicher, dass Ihre Mandanten dem Prinzip der geringsten Berechtigungen folgen und Ihrem System keine unnötigen Berechtigungen erteilen. Wenn Ihr System beispielsweise nur Daten aus dem Datenspeicher eines Mandanten lesen muss, sollte die identität, die Ihr System verwendet, nicht über Schreibberechtigungen verfügen.

Zugriff der Mieter auf Ihre Systeme

Wenn Mandanten eine Verbindung mit Ihrem System herstellen müssen, sollten Sie dedizierte APIs oder andere Integrationspunkte bereitstellen. Anschließend können Sie diese Integrationspunkte als Teil der Oberflächenfläche Ihrer Lösung modellieren.

In einigen Szenarien können Sie sich entscheiden, Ihren Mandanten direkten Zugriff auf Ihre Azure-Ressourcen zu gewähren. Berücksichtigen Sie die Konsequenzen sorgfältig und stellen Sie sicher, dass Sie verstehen, wie Sie den Zugang zu Mandanten auf sichere Weise gewähren können. Sie können beispielsweise einen der folgenden Ansätze verwenden:

• Verwenden Sie das Valet Key-Muster, das Sicherheitsmaßnahmen wie SAS-Token (Shared Access Signatures) verwendet, um eingeschränkten Zugriff auf bestimmte Azure-Ressourcen zu gewähren.

• Verwenden Sie dedizierte Ressourcen für Integrationspunkte, z. B. ein dediziertes Speicherkonto. Es empfiehlt sich, Die Integrationsressourcen von Den wichtigsten Systemressourcen getrennt zu halten. Dieser Ansatz hilft Ihnen, den Strahlradius eines Sicherheitsvorfalls zu minimieren. Außerdem wird sichergestellt, dass der Rest Ihres Systems weiterhin läuft, selbst wenn ein Mandant versehentlich eine große Anzahl von Verbindungen zu der Ressource herstellt und deren Kapazität erschöpft.

Einhaltung

Wenn Sie direkt mit den Daten Ihrer Mandanten interagieren oder diese übertragen, ist es wichtig, dass Sie über ein klares Verständnis der Governance- und Complianceanforderungen Ihrer Mandanten verfügen.

Ansätze und Muster

Verfügbarmachen von APIs

Echtzeitintegrationen umfassen häufig das Verfügbarmachen von APIs für Ihre Mandanten oder andere Parteien. APIs erfordern besondere Überlegungen, insbesondere, wenn externe Parteien sie verwenden. Berücksichtigen Sie die folgenden Faktoren:

• Definieren Sie, wer auf die API zugreifen kann.

• Authentifizieren Sie Benutzer der API mithilfe einer sicheren und zuverlässigen Methode.

• Legen Sie einen Grenzwert für die Anzahl der Anforderungen fest, die jeder API-Benutzer über einen bestimmten Zeitraum vornehmen kann.

• Stellen Sie klare Informationen und Dokumentationen für jede API bereit. Implementieren Sie gegebenenfalls ein Entwicklerportal, um die Ermittlung und das Onboarding zu unterstützen.

Es empfiehlt sich, ein API-Gateway wie Azure API Managementzu verwenden, um diese Bedenken und viele andere zu behandeln. API-Gateways bieten Ihnen einen einzigen Ort zum Implementieren von Richtlinien, die Ihre APIs befolgen. Sie vereinfachen auch die Implementierung Ihrer Back-End-API-Systeme. Weitere Informationen finden Sie unter Verwenden der API-Verwaltung in einer Mehrinstanzenlösung.

Muster „Valet-Schlüssel“

Gelegentlich benötigt ein Mandant möglicherweise direkten Zugriff auf eine Datenquelle, z. B. Azure Storage. Beachten Sie das Valet Key-Muster, um Daten sicher zu teilen und den Zugriff auf den Datenspeicher einzuschränken.

Sie können zum Beispiel diesen Ansatz verwenden, um eine große Datendatei im Batchmodus zu exportieren. Nachdem Sie die Exportdatei generiert haben, können Sie sie in einem BLOB-Container in Azure Storage speichern und dann eine zeitgebundene, schreibgeschützte SAS generieren. Diese Signatur kann dem Mandanten zusammen mit der Blob-URL übermittelt werden. Der Mandant kann die Datei dann aus Azure Storage bis zum Ablaufdatum der Signatur herunterladen.

Ebenso können Sie eine SAS mit Berechtigungen zum Schreiben in ein bestimmtes Blob generieren. Wenn Sie einem Mandanten eine SAS bereitstellen, können sie ihre Daten in das Blob schreiben. Mithilfe der Event Grid-Integration für Azure Storage kann Ihre Anwendung benachrichtigt werden, um die Datendatei zu verarbeiten und zu importieren.

webhooks

Webhooks ermöglichen Ihnen das Senden von Ereignissen an Ihre Mandanten unter einer URL, die sie Ihnen zur Verfügung stellen. Wenn Sie Informationen zum Senden haben, initiieren Sie eine Verbindung mit dem Webhook des Mandanten und fügen Ihre Daten in die HTTP-Anforderungsnutzlast ein.

Wenn Sie Ihr eigenes Webhook-Ereignissystem erstellen möchten, sollten Sie den CloudEvents--Standard verwenden, um die Integrationsanforderungen Ihrer Mandanten zu vereinfachen.

Alternativ können Sie einen Dienst wie Event Grid verwenden, um Webhook-Funktionen bereitzustellen. Das Ereignisraster funktioniert nativ mit CloudEvents und unterstützt Ereignisdomänen, die für Multitenant-Lösungen nützlich sind.

Delegierter Benutzerzugriff

Wenn Sie auf Daten aus den Datenspeichern eines Mandanten zugreifen, überlegen Sie, ob Sie die Identität eines bestimmten Benutzers für den Zugriff auf die Daten verwenden müssen. Wenn Sie dies tun, unterliegt Ihre Integration den gleichen Berechtigungen wie dem Benutzer. Dieser Ansatz wird häufig als delegierter Zugriffbezeichnet.

Angenommen, Ihr mehrinstanzenfähiger Dienst führt maschinelle Lernmodelle über die Daten Ihrer Mandanten aus. Sie müssen auf die Dienstinstanzen jedes Mandanten zugreifen, z. B. auf Microsoft Fabric-Arbeitsbereiche für Analysen, Azure Storage und Azure Cosmos DB. Jeder Mandant verfügt über ein eigenes Microsoft Entra-Verzeichnis. Ihre Lösung kann delegierten Zugriff auf den Datenspeicher erhalten, damit Sie die Daten abrufen können, auf die ein bestimmter Benutzer zugreifen kann.

Der delegierte Zugriff ist einfacher, wenn der Datenspeicher die Microsoft Entra-Authentifizierung unterstützt. Viele Azure-Dienste unterstützen Microsoft Entra-Identitäten.

Angenommen, Ihre mehrstufigen Webanwendungs- und Hintergrundprozesse müssen mithilfe der Benutzeridentitäten Ihrer Mandanten aus Microsoft Entra auf Azure Storage zugreifen. Möglicherweise führen Sie die folgenden Schritte aus:

1. Erstellen Sie eine mehrinstanzenfähige Microsoft Entra-Anwendungsregistrierung, die Ihre Lösung darstellt.

2. Gewähren Sie der Anwendung delegierte Berechtigung für den Zugriff auf Azure Storage als angemeldeten Benutzer.

3. Konfigurieren Sie Ihre Anwendung für die Authentifizierung von Benutzern mithilfe der Microsoft Entra-ID.

Nachdem sich ein Benutzer angemeldet hat, gibt die Microsoft Entra ID ihrer Anwendung ein kurzlebiges Zugriffstoken aus, das für den Zugriff auf Azure Storage im Namen des Benutzers verwendet werden kann, sowie ein längeres Aktualisierungstoken. Ihr System muss das Aktualisierungstoken sicher speichern, damit Ihre Hintergrundprozesse neue Zugriffstoken abrufen und weiterhin im Namen des Benutzers auf Azure Storage zugreifen können.

Nachrichtenübermittlung

Messaging ermöglicht asynchrone, lose gekoppelte Kommunikation zwischen Systemen oder Komponenten. Messaging wird häufig in Integrationsszenarien verwendet, um die Quell- und Zielsysteme zu entkoppeln. Weitere Informationen zu Messaging und Mehrinstanzenfähigkeit finden Sie unter Architekturansätze für Messaging in Multitenant-Lösungen.

Wenn Sie Messaging als Teil einer Integration mit den Systemen Ihrer Mandanten verwenden, überlegen Sie, ob Sie SAS-Token für Service Bus oder Event Hubs verwenden sollten. SAS-Token gewähren eingeschränkten Zugriff auf Ihre Messagingressourcen für externe Benutzer oder Systeme, ohne dass sie auf den Rest Ihres Messaging-Subsystems zugreifen können.

In einigen Szenarien können Sie unterschiedliche Vereinbarungen auf Serviceebene oder Dienstqualitätsgarantien für unterschiedliche Mandanten bereitstellen. Eine Teilmenge Ihrer Mandanten kann z. B. erwarten, dass ihre Datenexportanforderungen schneller verarbeitet werden als andere. Mithilfe des Musters "Prioritätswarteschlange" können Sie separate Warteschlangen für unterschiedliche Prioritätsebenen erstellen. Anschließend können Sie verschiedene Arbeitsinstanzen verwenden, um sie entsprechend zu priorisieren.

Komponenten für die komponierbare Integration

Manchmal müssen Sie sich möglicherweise mit vielen verschiedenen Mandanten integrieren, von denen jeder unterschiedliche Datenformate oder Arten der Netzwerkkonnektivität verwendet.

Ein gängiger Ansatz bei der Integration besteht darin, einzelne Schritte zu erstellen und zu testen, die die folgenden Arten von Aktionen ausführen:

• Abrufen von Daten aus einem Datenspeicher.
• Transformieren von Daten in ein bestimmtes Format oder Schema.
• Daten mit einem bestimmten Netzwerkprotokoll oder zu einem bekannten Zieltyp übertragen.

In der Regel erstellen Sie diese einzelnen Elemente mithilfe von Diensten wie Azure Functions und Azure Logic Apps. Anschließend definieren Sie den allgemeinen Integrationsprozess mithilfe eines Tools wie Logic Apps oder Azure Data Factory, das jeden vordefinierten Schritt aufruft.

Wenn Sie mit komplexen Multitenant-Integrationsszenarien arbeiten, ist es hilfreich, eine Bibliothek wiederverwendbarer Integrationsschritte zu definieren. Sie können Workflows für jeden Mandanten erstellen, indem Sie die anwendbaren Teile basierend auf den Anforderungen dieses Mandanten erstellen. Alternativ können Sie einige der Datasets oder Integrationskomponenten direkt für Ihre Mandanten verfügbar machen, damit sie ihre eigenen Integrationsworkflows erstellen können.

Ebenso müssen Sie möglicherweise Daten aus Mandanten importieren, die ein anderes Datenformat oder einen anderen Transport verwenden als andere. Ein guter Ansatz für dieses Szenario besteht darin, mandantenspezifische Connectors zu erstellen. Connectors sind Workflows, die die Daten in ein standardisiertes Format und einen standardisierten Speicherort normalisieren und importieren. Sie lösen dann Ihren Haupt-Gemeinsamen Importprozess aus.

Wenn Sie mandantenspezifische Logik oder Code erstellen müssen, sollten Sie das Muster der Antikorruptionsschicht befolgen. Dieses Muster hilft Ihnen, mandantenspezifische Komponenten einzuschließen und den Rest Ihrer Lösung nicht über die zusätzliche Komplexität zu informieren.

Wenn Sie ein gestaffeltes Preismodell verwenden, benötigen Sie möglicherweise, dass Mandanten mit niedrigen Preisniveaus einem Standardansatz mit einer begrenzten Gruppe von Datenformaten und Transportmethoden folgen. Mandanten mit höheren Preisstufen haben möglicherweise Zugriff auf mehr Anpassungen oder Flexibilität in den von Ihnen bereitgestellten Integrationskomponenten.

Zu vermeide Antimuster

• Direktes Exposieren Ihrer primären Datenspeicher an Mandanten. Wenn Mandanten auf Ihre primären Datenspeicher zugreifen, kann es schwieriger werden, diese Speicher zu sichern. Sie können auch versehentlich Leistungsprobleme verursachen, die sich auf Ihre Lösung auswirken. Vermeiden Sie die Bereitstellung von Anmeldeinformationen für Ihre Datenspeicher für Kunden. Replizieren Sie Rohdaten aus Ihrer primären Datenbank nicht direkt in die Lesereplikate des gleichen Datenbanksystems der Kunden. Erstellen Sie stattdessen dedizierte Integrationsdatenspeicher. Verwenden Sie das Valet Key-Muster , um die Daten verfügbar zu machen.

• Verfügbarmachen von APIs ohne API-Gateway. APIs haben besondere Bedenken hinsichtlich der Zugriffssteuerung, Abrechnung und Messung. Auch wenn Sie nicht beabsichtigen, API-Richtlinien anfänglich zu verwenden, ist es ratsam, ein API-Gateway frühzeitig einzuschließen. Auf diese Weise müssen Sie, wenn Sie Ihre API-Richtlinien später anpassen müssen, keine änderungen an den URLs vornehmen, von denen ein externer Client abhängt.

• Unnötige enge Kopplung. Lose Kopplung, z. B. mithilfe von Messaging-Ansätzen, kann eine Reihe von Vorteilen für Sicherheit, Leistungsisolation und Resilienz bieten. Wenn möglich, sollten Sie Ihre Integrationen mit externen Systemen locker koppeln. Wenn Sie eng mit einem externen System gekoppelt werden müssen, stellen Sie sicher, dass Sie bewährte Methoden wie das Wiederholungsmuster, das Schaltkreistrennmuster und das Bulkhead-Muster befolgen.

• Benutzerdefinierte Integrationen für bestimmte Mandanten. Mandantenspezifische Features oder Code können es schwieriger machen, Ihre Lösung zu testen. Außerdem ist es schwieriger, Ihre Lösung in Zukunft zu ändern, da Sie mehr Codepfade verstehen müssen. Versuchen Sie stattdessen, komponierbare Komponenten zu erstellen, die die Anforderungen für einen bestimmten Mandanten abstrahieren und für mehrere Mandanten wiederverwenden, die ähnliche Anforderungen haben.

Beitragende

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

Hauptautoren:

• John Downs | Principal Software Engineer, Azure Patterns & Practices
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack für Azure

Andere Mitwirkende:

• Will Velida | Customer Engineer 2, FastTrack für Azure
• Filipe Moreira | Cloud-Lösungsarchitekt

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

Zugehörige Ressource

• Architekturansätze für das Messaging in mehrinstanzenfähigen Lösungen