Deployment-Modell für mehrmandantenfähige Anwendungen auf OCI

In der heutigen Cloud-First-Welt verwandeln Unternehmen und unabhängige Softwareanbieter (ISVs) traditionelle Anwendungen zunehmend in Software-as-a-Service-Angebote (SaaS). Eine wichtige Komponente dieser Transformation ist das Multi-Tenant-Bereitstellungsmodell, mit dem mehrere Kunden dieselbe Anwendung gemeinsam nutzen und gleichzeitig Sicherheit, Performance und Kosteneffizienz sicherstellen können. Oracle Cloud Infrastructure (OCI) bietet ein robustes Set von Services, mit denen Sie problemlos SaaS-Anwendungen mit gemeinsam verwendeten Mandanten- und Hybridansätzen bereitstellen können.

Informationen zu Mandanten

Es ist wichtig, OCI Tenancy nicht mit dem Konzept eines Mandanten in einer SaaS-Anwendung zu verwechseln.

OCI-Mandant: Dies ist der Account, den Sie bei der Registrierung für OCI-Services erhalten. Er stellt Ihren Root-Account dar und dient als sichere, isolierte Partition, in der Sie Ihre OCI-Ressourcen organisieren und verwalten.

Ein Mandant (in einem SaaS-Kontext): Angenommen, ein ISV erstellt eine SaaS-Plattform auf OCI. Wenn der ISV seine eigenen Kunden in die Plattform stellt, wird jeder dieser Kunden als Mieter betrachtet. Ein Mandant repräsentiert in diesem Sinne eine Kundenorganisation, und jedem Mandanten können mehrere Benutzer zugeordnet sein.

Kurz gesagt bezieht sich ein OCI-Mandant auf den OCI-Account selbst, während ein Mandant auf eine Organisation (wie einen SaaS-Kunden) verweist, die eine Anwendung verwendet, die von einer anderen Entität, wie einem ISV, auf OCI gehostet wird.

Architektur

Diese Architektur stellt ein mehrmandantenfähiges Anwendungs-Deployment-Modell auf OCI auf einer hohen Ebene dar.

Das folgende Diagramm veranschaulicht diese Referenzarchitektur:


Beschreibung von multi-tenant-app-oci.png folgt
Beschreibung der Abbildung multi-tenant-app-oci.png

mehrmandantenfähig-app-oci-oracle.zip

Diese flexible Architektur ist in drei Schichten unterteilt:

Layer Zweck Schlüsselaktion
Anfängliche Authentifizierung (OCI IAM) Globale Identität verifizieren JSON Web Token (JWT) nach Zugangsdatenvalidierung ausgeben
Authentifizierungs-Middleware Identität pro Anforderung prüfen Mandanten- und Benutzerkontext aus JWT extrahieren
Datenzugriffsebene oder ORM-Hooks Durchsetzung der Datenisolierung Alle Abfragen automatisch nach tenant_id filtern

Jede Schicht wird im Folgenden beschrieben:

Anfängliche Authentifizierung und Einrichtung des Mandantenkontexts

  • Authentifizierungsservice: Der Benutzer meldet sich an, in der Regel mit einer mandantenspezifischen URL (z.B. mycompany.app.com) oder durch Auswahl eines Mandanten während der Anmeldung.
  • OCI Identity and Access Management (OCI IAM) als Identitätsprovider: OCI IAM (insbesondere eine dedizierte Identitätsdomain) validiert die Zugangsdaten des Benutzers. Entscheidend ist, dass der Benutzer nicht nur gültig ist, sondern auch Mitglied der spezifischen Mandantengruppe (z. B. mycompany-Benutzer) ist, auf die er zugreifen möchte.
  • JWT-Ausgabe: Nach erfolgreicher Authentifizierung gibt die OCI-IAM-Identitätsdomain ein signiertes JSON Web Token (JWT) aus. Dieses Token enthält die folgenden kritischen Behauptungen:
    • sub: Die eindeutige ID des Benutzers.
    • Gruppen: Ein Array von OCIDs für die IAM-Gruppen, zu denen der Benutzer gehört. Dies ist der Schlüssel zur Identifizierung des Mandanten.
    • Ein benutzerdefinierter Claim, wie tenant_id oder tenant_name, kann mit benutzerdefinierten Attributen in OCI IAM hinzugefügt werden. (Optional)

Authentifizierungs-Middleware – Schicht "Who"

Das Backend muss so konzipiert sein, dass der Mandantenkontext sicher extrahiert und propagiert wird. Diese Architektur unterstützt die Verwendung von OCI API Gateway oder OCI Load Balancer, um die Authentifizierung pro Anforderung und die Propagierung des Mandantenkontexts auszuführen.

  • OCI-API-Gateway: Dies ist der empfohlene Einstiegspunkt. Er kann die JWT-Validierung selbst durchführen und diese Zuständigkeit aus dem Anwendungscode auslagern. Sie konfigurieren es so, dass die Signatur anhand des JWKS-Endpunkts Ihrer OCI-IAM-Identitätsdomain validiert wird.
  • OCI Load Balancer: Kann SSL-Beendigung und -Routing verarbeiten, übergibt das JWT jedoch zur Validierung an die Authentifizierungs-Middleware.

Aktion: OCI API Gateway validiert die Signatur und den Ablauf des JWT. Wenn sie ungültig ist, wird die Anforderung sofort abgelehnt. Wenn sie gültig ist, leitet sie die Anforderung an den Upstreamservice weiter, wobei oft das validierte Token oder die extrahierten Claims in Headern übergeben werden (z.B. X-USER-ID, X-TENANT-ID).

Wenn Sie OCI Load Balancer anstelle von OCI API Gateway verwenden, muss die erste Komponente Ihres Anwendungs-Backends Authentifizierungs-Middleware sein.

Aktion: Extrahieren Sie das JWT aus dem Authorization: Bearer <token>-Header, prüfen Sie seine Signatur mit den Public Keys von OCI IAM, dekodieren Sie die Claims, und injizieren Sie user_id und tenant_id (aus dem Gruppen-Claim abgeleitet) in den Anforderungskontext, damit alle nachfolgenden Layer verwendet werden können.

Data Access Layer oder Object-Relational Mapper (ORM) Hook – "What"-Ebene

Dieser Layer injiziert automatisch die Mandanten-ID in jede SQL-Abfrage.

  • Beispiel: Ein Aufruf von getAllInvoices() wird in SELECT * FROM invoices WHERE tenant_id = :tenant_id transformiert.
  • Durchsetzung: Dies wird am besten durch eine zentrale Datenzugriffsschicht oder einen ORM-(wie Hibernate-)Hook oder einen "Mandanten-bewussten" Verbindungspool erzwungen, um menschliche Fehler zu vermeiden.
  • ORM-Hooks: Der Mechanismus, der die echte implizite Mandantenisolation ermöglicht, indem Datenbankvorgänge auf Anwendungs-Framework-Ebene abgefangen und geändert werden.

Strategien zur Isolierung von Mandantendaten:

Diese Architektur unterstützt zwei Optionen für die Isolierung und den Schutz der Mandantendaten:

Option 1: Anwendungsebene

ORM-Hooks/Scopes: Mit Frameworks wie Hibernate (Java), Django ORM (Python) oder Eloquent (PHP) können Sie globale Geltungsbereiche definieren, mit denen der Mandantenfilter automatisch allen Abfragen für ein bestimmtes Modell hinzugefügt wird.

Oder

Option 2: Datenbankebene

Sie können eine Diskriminatorspalte, ein separates Schema pro Mandant oder eine separate Datenbank pro Mandant verwenden:

  • Diskriminatorspalte (häufigste):

    Jeder mandantenspezifischen Tabelle oder jedem mandantenspezifischen Dokument wird eine Spalte tenant_id hinzugefügt.

    Die Data Access Layer (DAL) oder ORM der Anwendung ist für das automatische Anhängen der WHERE tenant_id = ?-Klausel an jede Abfrage verantwortlich. Dies wird erreicht durch:

    • Repository-Muster: Alle Datenbankzugriffsflüsse durch eine zentrale Klasse oder eine Gruppe von Klassen. Dieses Repository fügt den Mandantenfilter automatisch jedem SELECT-, INSERT-, UPDATE- und DELETE-Vorgang basierend auf der tenant_id im aktuellen Anforderungskontext hinzu.
    • Verbindungskontext: Bei einigen SQL-Datenbanken (wie Oracle HeatWave MySQL) kann die Anwendung eine Sessionvariable (z.B. SET @tenant_id = 'mycompany123';) festlegen und diese dann in Ansichten oder gespeicherten Prozeduren verwenden. Die Anwendungsschicht ist jedoch weiterhin dafür verantwortlich, diesen Wert pro Verbindung festzulegen.
  • Schema pro Mandant:

    Jeder Mandant verfügt über ein dediziertes Datenbankschema innerhalb derselben Datenbankinstanz.

    Die Anwendungslogik, die auf der Mandanten-ID basiert, muss das aktuelle Schema der Datenbankverbindung wechseln.

    • Verbindungspool pro Mandant: Verwalten Sie einen separaten Verbindungspool für jeden Mandanten, bei dem jede Verbindung für die Verwendung des Mandantenschemas vorkonfiguriert ist (z.B. USE tenant_mycompany;).
    • Dynamisches Verbindungs-Switching: Verwenden Sie einen Verbindungspool, der das Schema beim Checkout basierend auf dem aktuellen tenant_id festlegt (Beispiel: mit einem SET search_path TO tenant_mycompany;-Befehl für PostgreSQL).
  • Datenbank pro Mandant:

    Jeder Mandant verfügt über eine eigene physisch getrennte Datenbankinstanz mit Bring Your Own Keys Encryption for Enterprises.

    Die Anwendung benötigt einen Mandantendaten-Lookup-Service, um eine tenant_id der richtigen Datenbankverbindungszeichenfolge zuzuordnen.

    • Die Anwendung enthält Verbindungspools zu mehreren Datenbanken.
    • Die DAL verwendet die Mandanten-ID aus dem Anforderungskontext, um die richtige Verbindung aus dem Pool abzurufen und die Abfrage für die dedizierte Mandantendatenbank auszuführen.

    Diese Option hat Vor- und Nachteile:

    • Vorteile: Maximale Isolation, Sicherheit und Performance. Mandanten können sich sogar auf verschiedenen Datenbankversionen oder Engine-Typen befinden.
    • Konsumieren: Höchste betriebliche Gemeinkosten, Kosten und Komplexität. Datenbankmigrationen und -patches müssen auf jeder Mandantendatenbank ausgeführt werden.

Diese Architektur implementiert die folgenden Komponenten:

  • Tenancy

    Ein Mandant ist eine sichere und isolierte Partition, die Oracle bei der Registrierung für OCI in Oracle Cloud einrichtet. Sie können Ihre Ressourcen auf OCI innerhalb Ihres Mandanten erstellen, organisieren und verwalten. Ein Mandant ist ein Synonym für ein Unternehmen oder eine Organisation. Normalerweise hat ein Unternehmen einen einzelnen Mandanten und spiegelt seine Organisationsstruktur innerhalb dieses Mandanten wider. Ein einzelner Mandant ist in der Regel mit einem einzelnen Abonnement verknüpft, und ein einzelnes Abonnement hat in der Regel nur einen Mandanten.

  • OCI Identity and Access Management

    Oracle Cloud Infrastructure Identity and Access Management (IAM) bietet Benutzerzugriffskontrolle für OCI und Oracle Cloud Applications. Mit der IAM-API und der Benutzeroberfläche können Sie Identitätsdomains und die darin enthaltenen Ressourcen verwalten. Jede OCI IAM-Identitätsdomain stellt eine eigenständige Identity and Access Management-Lösung oder eine andere Benutzerpopulation dar.

  • Load Balancer

    Oracle Cloud Infrastructure Load Balancer bietet eine automatisierte Trafficverteilung von einem einzigen Einstiegspunkt auf mehrere Server.

  • OCI API Gateway

    Mit Oracle Cloud Infrastructure API Gateway können Sie APIs mit privaten Endpunkten veröffentlichen, auf die über Ihr Netzwerk zugegriffen werden kann und die Sie bei Bedarf im öffentlichen Internet bereitstellen können. Die Endpunkte unterstützen API-Validierung, Anforderungs- und Antworttransformation, CORS, Authentifizierung und Autorisierung sowie Anforderungsbegrenzung.

  • Oracle Key Management Cloud Service

    OCI Key Management Service Der Oracle Cloud Infrastructure (OCI) Key Management Service (KMS) ist ein cloudbasierter Service, der eine zentralisierte Verwaltung und Kontrolle von Verschlüsselungsschlüsseln für in OCI gespeicherte Daten bietet. OCI KMS ist eine vom Kunden verwaltete Verschlüsselung und bietet OCI Vault (sowohl Virtual Vault als auch Private Vault), OCI Dedicated KMS und OCI External KMS-Services.

  • OCI-Compute

    Mit Oracle Cloud Infrastructure Compute können Sie Compute-Hosts in der Cloud bereitstellen und verwalten. Sie können Compute-Instanzen mit Ausprägungen starten, die Ihren Ressourcenanforderungen für CPU, Arbeitsspeicher, Netzwerkbandbreite und Speicher entsprechen. Nachdem Sie eine Compute-Instanz erstellt haben, können Sie sicher darauf zugreifen, sie neu starten, Volumes anhängen und trennen und beenden, wenn Sie sie nicht mehr benötigen.

  • OCI Functions

    Oracle Cloud Infrastructure Functions ist eine vollständig verwaltete, mehrmandantenfähige, hoch skalierbare, On-Demand-Funktionen-as-a-Service-(FaaS-)Plattform. Sie wird von der Open Source-Engine Fn Project unterstützt. Mit OCI Functions können Sie Ihren Code bereitstellen, direkt aufrufen oder auch als Reaktion auf Ereignisse auslösen. OCI Functions verwendet Docker-Container, die in Oracle Cloud Infrastructure Registry gehostet werden.

  • OCI Kubernetes Engine

    Oracle Cloud Infrastructure Kubernetes Engine (OCI Kubernetes Engine oder OKE) ist ein vollständig verwalteter, skalierbarer und hochverfügbarer Service, mit dessen Hilfe Sie Ihre containerisierten Anwendungen in der Cloud bereitstellen können. Sie geben die Compute-Ressourcen an, die Ihre Anwendungen benötigen, und OKE stellt sie auf OCI in einem vorhandenen Mandanten bereit. OKE automatisiert mit Kubernetes das Deployment, die Skalierung und die Verwaltung containerisierter Anwendungen über Hostscluster hinweg.

  • Oracle HeatWave MySQL

    Oracle MySQL Database Service ist ein vollständig verwalteter Datenbankservice, mit dem Entwickler sichere, native Cloud-Anwendungen mit der weltweit beliebtesten Open-Source-Datenbank schnell entwickeln und bereitstellen können. Oracle HeatWave MySQL ist ein neuer, integrierter, leistungsstarker In-Memory-Abfragebeschleuniger für Oracle MySQL Database Service, der die MySQL-Performance für Analysen und Transaktionsabfragen beschleunigt.

  • Oracle NoSQL Database Cloud Service

    Mit Oracle NoSQL Database Cloud Service können Entwickler ganz einfach Anwendungen mit Dokument-, Festschema- und Schlüsselwert-Datenbankmodellen erstellen. So erhalten sie vorhersehbare Antwortzeiten im einstelligen Millisekundenbereich mit Datenreplikation für High Availability. Der Service bietet eine aktiv-aktive regionale Replikation, ACID-Transaktionen, serverlose Skalierung, umfassende Sicherheit und niedrige Pay-per-Use-Preise für On-Demand- und bereitgestellte Kapazitätsmodi, einschließlich 100% Kompatibilität mit On-Premise-Oracle NoSQL Database.

  • OCI Object Storage

    OCI Object Storage bietet Zugriff auf große Mengen an strukturierten und unstrukturierten Daten eines beliebigen Inhaltstyps, darunter Datenbankbackups, Analysedaten und umfangreiche Inhalte, wie Bilder und Videos. Sie können Daten sicher und sicher direkt aus Anwendungen oder aus der Cloud-Plattform speichern. Sie können den Storage skalieren, ohne dass die Performance oder Servicezuverlässigkeit beeinträchtigt wird.

    Verwenden Sie den Standardspeicher für "Hot Storage", auf die Sie schnell, sofort und häufig zugreifen müssen. Verwenden Sie Archivspeicherung für "Cold Storage", die Sie über lange Zeiträume beibehalten und nur selten darauf zugreifen.

  • Oracle Autonomous Database Serverless

    Oracle Autonomous Database Serverless ist eine Oracle Autonomous Database-Instanz. Sie verfügen über eine vollständig elastische Datenbank, in der Oracle alle Aspekte des Datenbanklebenszyklus von der Datenbankplatzierung bis hin zu Backup und Updates autonom verwaltet.

  • Transparente Datenverschlüsselung

    Transparent Data Encryption (TDE) verschlüsselt Daten im Ruhezustand in einer Oracle AI Database transparent. TDE ist vollständig in Oracle AI Database integriert und kann ganze Datenbankbackups (RMAN), Data Pump-Exporte, ganze Anwendungs-Tablespaces oder bestimmte sensible Spalten verschlüsseln. Verschlüsselte Daten bleiben in der Datenbank verschlüsselt, unabhängig davon, ob sie sich in Tablespace-Speicherdateien, Temporary Tablespaces, Undo Tablespaces oder anderen Dateien wie Redo Logs befinden. Dadurch werden nicht autorisierte Versuche verhindert, auf Datenbankdaten zuzugreifen, ohne dass sich dies auf den Zugriff von Anwendungen mit SQL auswirkt.

Empfehlungen

Verwenden Sie die folgenden Empfehlungen als Ausgangspunkt für das Design Ihrer Architektur. Ihre Anforderungen können von der hier beschriebenen Architektur abweichen.
  • VCN

    Wenn Sie ein VCN erstellen, bestimmen Sie die Anzahl der erforderlichen CIDR-Blöcke und die Größe jedes Blocks basierend auf der Anzahl der Ressourcen, die Sie an Subnetze im VCN anhängen möchten. Verwenden Sie CIDR-Blöcke, die sich innerhalb des standardmäßigen privaten IP-Adressraums befinden.

    Wählen Sie CIDR-Blöcke aus, die sich mit keinem anderen Netzwerk (in Oracle Cloud Infrastructure, Ihrem On-Premise-Data Center oder einem anderen Cloud-Provider) überschneiden, zu dem Sie private Verbindungen einrichten möchten.

    Nachdem Sie ein VCN erstellt haben, können Sie die zugehörigen CIDR-Blöcke ändern, hinzufügen und entfernen.

    Berücksichtigen Sie beim Entwerfen der Subnetze den Verkehrsfluss und die Sicherheitsanforderungen. Hängen Sie alle Ressourcen innerhalb einer bestimmten Tier oder Rolle an dasselbe Subnetz an, das als Sicherheitsgrenze dienen kann.

  • Sicherheitslisten

    Mit Sicherheitslisten können Sie Ingress- und Egress-Regeln definieren, die für das gesamte Subnetz gelten.

  • Netzwerksicherheitsgruppen (NSGs)

    Mit NSGs können Sie ein Set von Ingress- und Egress-Regeln definieren, die für bestimmte VNICs gelten. Es wird empfohlen, NSGs anstelle von Sicherheitslisten zu verwenden, da Sie mit NSGs die Subnetzarchitektur des VCN von den Sicherheitsanforderungen Ihrer Anwendung trennen können.

  • Cloud Guard

    Klonen und passen Sie die von Oracle bereitgestellten Standardrezepte an, um benutzerdefinierte Detektor- und Responder-Rezepte zu erstellen. Mit diesen Rezepten können Sie angeben, welche Art von Sicherheitsverletzungen eine Warnung generieren und welche Aktionen für sie ausgeführt werden dürfen. Beispiel: Sie möchten OCI Object Storage-Buckets ermitteln, deren Sichtbarkeit auf "Öffentlich" gesetzt ist.

    Wenden Sie Oracle Cloud Guard auf Mandantenebene an, um den größten Umfang abzudecken und den Verwaltungsaufwand für die Verwaltung mehrerer Konfigurationen zu reduzieren.

    Sie können auch das Feature "Verwaltete Liste" verwenden, um bestimmte Konfigurationen auf Detektoren anzuwenden.

  • Sicherheitszonen

    Für Ressourcen, die maximale Sicherheit erfordern, empfiehlt Oracle die Verwendung von Sicherheitszonen. Eine Sicherheitszone ist ein Compartment, das mit einem von Oracle definierten Rezept für Sicherheits-Policys verknüpft ist, die auf Best Practices basieren. Beispiel: Ressourcen in einer Sicherheitszone dürfen nicht über das öffentliche Internet zugänglich sein und müssen über vom Kunden verwaltete Schlüssel verschlüsselt werden. Wenn Sie Ressourcen in einer Sicherheitszone erstellen und aktualisieren, validiert OCI die Vorgänge anhand der Policys im Rezept und verhindert Vorgänge, die gegen eine der Policys verstoßen.

Hinweise

Berücksichtigen Sie diese Optionen beim Deployment dieser Architektur.

  • Performance:
    • Mandantenbasierte Ratenbegrenzung für APIs festlegen
    • Verwenden Sie Kubernetes-Ressourcenquotas pro Namespace in OKE, um Pods, CPUs und Arbeitsspeicher pro Mandant zu begrenzen
    • Dedizierte Knotenpools für Mandanten mit hohem Bedarf nutzen
    • Größe eines mandantenfähigen Pools für die Datenbankverbindung festlegen
  • Sicherheit:
    • OCI-IAM-Gruppen steuern, auf welchen Mandanten ein Benutzer zugreifen kann. Diese wird vom JWT durchgesetzt.
    • Oracle Cloud Guard aktivieren, um Fehlkonfigurationen zu erkennen
  • Kostenfaktor:

    Bewerten Sie basierend auf Ihren Geschäftsanforderungen, unabhängig davon, ob Sie Tabellen-, Schema- oder eine dedizierte Datenbank für Kunden auf Unternehmensebene benötigen. Beispiel:

    • Stufe 1: Standard (Diskriminatorspalte): Mandanten verwenden dieselben Tabellen/Schemas.
    • Stufe 2: Premium (Schema pro Mandant): Mandanten erhalten ein dediziertes Schema innerhalb derselben Datenbank.
    • Tier 3: Enterprise (Datenbank pro Mandant): Mandanten erhalten eine dedizierte Datenbankinstanz.
  • Patching und Anwendungsupdates

    In einer mehrmandantenfähigen SaaS-Architektur mit einer einzelnen Instanz können Sie keinen Mandanten patchen, ohne alle zu patchen. Alle Ihre Kunden nutzen dieselbe Anwendungscodebasis, Laufzeit und Infrastruktur. Diese Realität stellt eine große Herausforderung dar: Wie führen Sie Updates sicher, effizient und ohne störende Ausfallzeiten für Ihre gesamte Benutzerbasis aus? Die Antwort liegt in modernen DevOps-Bereitstellungsstrategien, die speziell für diesen Zweck entwickelt wurden: Verwenden Sie Bereitstellungsstrategien ohne Ausfallzeiten, um nahtlose Übergänge zwischen Versionen zu ermöglichen, ohne Benutzer offline zu setzen.

    • Blue/Green-Deployment: Dabei werden zwei identische Produktionsumgebungen verwaltet: eine "Blue" (aktuelle Version wird ausgeführt) und eine "Green" (neue Version wird ausgeführt). Nachdem Sie die neue Version in Green bereitgestellt und getestet haben, können Sie den gesamten Datenverkehr nahtlos von Blau zu Grün wechseln. Wenn etwas schief geht, wechseln Sie sofort zurück und machen das Rollback zu einem Nicht-Ereignis. Die alte blaue Umgebung wird dann außer Betrieb genommen.
    • Canary-Deployment: Diese Strategie reduziert das Risiko durch einen schrittweisen Rollout. Die neue Version wird in einer kleinen, kontrollierten Teilmenge von Benutzern (den "Kanaren") bereitgestellt. Sie überwachen diese Gruppe genau auf Fehler oder Performanceprobleme. Wenn die Metriken gut aussehen, führen Sie das Update schrittweise auf mehr Benutzer aus, bis alle Benutzer die neue Version verwenden.

    Sie benachrichtigen die Benutzer über ein obligatorisches Upgrade-Fenster (Beispiel: "Wenn kein Upgradedatum angegeben wird, findet das Upgrade automatisch um 12:00 Uhr am Sonntag, mm/dd/yyyy") statt. Nach dem Fenster beenden Sie Sessions für die alte Version und leiten den gesamten Traffic zur neuen Version um. Der alte Anwendungscode wird dann vollständig heruntergefahren.

  • Überlegungen zur Datenbank

    Sie können das Datenbankschema nicht wechseln, sobald Sie die Anwendungsversion wechseln. Die meisten SaaS-Unternehmen vermeiden dies, indem sie:

    • Abwärtskompatible Änderungen des Datenbankschemas
    • Feature-Flags/-Schalter
    • Metadatenbasierte Versionskontrolle für Mandanten

    Dadurch kann neuer Code während des Rollouts sicher mit alten Schemaversionen ausgeführt werden, sodass Migrationen ohne Ausfallzeiten und sofortiges Rollback möglich sind.

Mehr erfahren

Weitere Informationen zum Deployment von Multi-Tenant-Anwendungen.

Prüfen Sie die folgenden zusätzlichen Ressourcen:

Bestätigungen

  • Autor: Gururaj Mohan, Enterprise Cloud Architect
  • Mitwirkende: Joshua Stanley