kcp-Arbeitsbereiche vs. Namensräume vs. vcluster

Einführung

Jedes Plattformteam steht vor derselben Frage: Wie kann man mehreren Teams isolierte Kubernetes-Umgebungen zur Verfügung stellen, ohne für jedes Team einen eigenen Cluster einzurichten? Dedizierte Cluster bieten maximale Isolation, doch am Ende muss man eine Infrastruktur verwalten, deren Umfang linear mit der Anzahl der Teams wächst. Nutzt man einen einzigen gemeinsamen Cluster, tauscht man den Betriebsaufwand gegen andere Probleme ein – CRD-Konflikte, störende Nachbarn und RBAC-Regeln, die immer komplexer werden, bis sie schließlich niemand mehr vollständig versteht.

Zur Lösung dieses Problems haben sich drei Ansätze herauskristallisiert, die sich in ihrer Architektur grundlegend unterscheiden. Namespaces sind in Kubernetes integriert und ermöglichen eine logische Unterteilung innerhalb eines einzelnen Clusters. vcluster erstellt virtuelle Kubernetes-Cluster, die als Pods innerhalb eines Host-Clusters ausgeführt werden. kcp-Workspaces bieten eine reine API-Isolation – vollständige Kubernetes-API-Bereiche ohne zugehörige Rechenebene.

Jede Lösung geht das Problem der Mandantenfähigkeit auf unterschiedliche Weise an, wobei jeweils unterschiedliche Kompromisse hinsichtlich Isolationsstärke, Ressourcenaufwand und Komplexität eingegangen werden. In diesem Leitfaden werden alle drei Lösungen verglichen, damit Sie die für Ihre Situation passende auswählen können.

Das Problem der Mehrmandantenfähigkeit

Sie haben 10 Teams. Jedes Team möchte eine eigene Kubernetes-„Umgebung“, in der es Anwendungen bereitstellen, Operatoren installieren, benutzerdefinierte Ressourcen definieren und eigenständig arbeiten kann. Sie haben zwei naheliegende Optionen.

Option 1: Jedem Team einen eigenen Cluster zuweisen. Maximale Isolation, maximale Kosten. Sie verwalten nun 10 Cluster, von denen jeder über eine eigene Steuerungsebene, einen eigenen Knotenpool, einen eigenen Überwachungsstack, einen eigenen Upgrade-Zyklus und einen eigenen Betriebsaufwand verfügt. Bei 50 Teams haben Sie 50 Cluster. Die Kosten und die betriebliche Komplexität steigen linear an.

Option 2: Einen Cluster gemeinsam nutzen. Das spart Geld, aber die Teams geraten sich in die Quere. CRDs gelten nur auf Cluster-Ebene, sodass zwei Teams nicht unterschiedliche Versionen derselben benutzerdefinierten Ressourcendefinition verwenden können. Ein außer Kontrolle geratener Pod im Namespace eines Teams kann den Knoten Speicher und CPU-Leistung entziehen, was sich auf alle auswirkt. Die RBAC-Regeln für Ressourcen auf Cluster-Ebene werden zu einem Wirrwarr aus ClusterRoles und ClusterRoleBindings.

Die drei folgenden Ansätze sind allesamt unterschiedliche Antworten auf die Frage: „Wie können wir Daten gemeinsam nutzen, ohne dass es zu Konflikten kommt?“ Sie reichen von einfachen Metadaten-Grenzen (Namespaces) über vollständige virtuelle Cluster (vcluster) bis hin zur reinen API-Isolierung (kcp-Workspaces).

Flussdiagramm LR
    Teilgraph NS["Namensräume"]
        NS_API[Gemeinsamer API-Server]
        NS_CRD[Gemeinsame CRDs]
        NS_A["ns: team-a"]
        NS_B["ns: team-b"]
        NS_API --> NS_A
        NS_API --> NS_B
    Ende

    Teilgraph VC["vcluster"]
        Host[Host-Cluster]
        VC_A["vcluster A
eigene API + CRDs
Pods, die mit dem Host synchronisiert sind"]
        VC_B["vcluster B
eigene API + CRDs
Pods, die mit dem Host synchronisiert sind"]
        Host --> VC_A
        Host --> VC_B
    Ende

    Teilgraph KCP["kcp-Arbeitsbereiche"]
        KCP_API[kcp-API-Mechanismus]
        WS_A["Arbeitsbereich A
eigene CRDs + RBAC"]
        WS_B["Arbeitsbereich B
eigene CRDs + RBAC"]
        Operator[Mandantenfähiger Operator]
        Compute[(Real k8s cluster)]
        KCP_API --> WS_A
        KCP_API --> WS_B
        WS_A -. APIBinding .-> Operator
        WS_B -. APIBinding .-> Operator
        Operator --> Compute
    end

Namensräume: Der integrierte Ansatz

So funktionieren sie

Kubernetes-Namespaces sind ein integrierter Mechanismus zur Aufteilung eines einzelnen Clusters in logische Partitionen. Jeder Namespace verfügt über eigene Ressourcen – Pods, Services, ConfigMaps, Secrets – sowie eigene RBAC-Regeln. Mithilfe von ResourceQuotas und LimitRanges können Sie steuern, wie viele Ressourcen jeder Namespace beanspruchen darf. NetworkPolicies können den Datenverkehr zwischen Namespaces einschränken.

Jeder Kubernetes-Cluster verfügt standardmäßig über Namespaces. Keine zusätzliche Installation, keine zusätzlichen Prozesse, keine Abhängigkeiten von Drittanbietern. Sie erstellen einen Namespace mit kubectl create namespace team-a, richten Sie einige RBAC-Regeln ein, wenden Sie eine ResourceQuota an und stellen Sie dem Team eine Kubeconfig zur Verfügung, die auf diesen Namespace beschränkt ist.

Stärken

Keine zusätzlichen Tools erforderlich. Namespaces sind Bestandteil jeder Kubernetes-Distribution. Sie funktionieren auf EKS, GKE, AKS, von KubeOne verwalteten Clustern und Bare-Metal-Setups. Es muss nichts installiert werden.

Geringer Overhead. Ein Namespace ist eine Metadaten-Grenze, kein laufender Prozess. Das Erstellen von 100 Namespaces führt nicht dazu, dass 100 API-Server oder 100 etcd-Instanzen hinzukommen. Der Ressourcenverbrauch des Clusters bleibt gleich, egal ob Sie 5 oder 500 Namespaces haben.

Das ist jedem Kubernetes-Nutzer bestens bekannt. Jeder, der schon einmal mit Kubernetes gearbeitet hat, hat auch schon mit Namespaces zu tun gehabt. Das Konzept ist einfach, die Dokumentation ist umfassend und die Fehlerbehebung ist unkompliziert.

Das funktioniert gut bei Teams, die sich gegenseitig vertrauen. Wenn Ihre Teams alle zur selben Organisation gehören, sich gegenseitig vertrauen und ähnliche Arbeitslasten bewältigen, bieten Namespaces eine ausreichende Trennung, ohne die Komplexität zu erhöhen.

Einschränkungen

CRDs gelten für den gesamten Cluster. Wenn Sie ein CRD in einem Namespace installieren, ist es in allen Namespaces sichtbar. Zwei Teams können nicht unterschiedliche Versionen desselben CRD verwenden. Wenn Team A „cert-manager“ v1.12 benötigt und Team B v1.14, entsteht ein Konflikt, den Namespaces nicht lösen können.

Risiko durch „Noisy Neighbors“. Ein Pod im Namespace A, der den gesamten Speicher des Knotens beansprucht, beeinträchtigt Pods im Namespace B. ResourceQuotas begrenzen zwar, was ein Namespace anfordern kann, verhindern jedoch nicht, dass ein einzelner Pod seine Grenzen überschreitet und OOM-Kills auslöst, die sich auf den gesamten Knoten auswirken.

RBAC wird schnell komplex. Ressourcen auf Cluster-Ebene – Knoten, persistente Volumes, CRDs, Cluster-Rollen – erfordern sorgfältig definierte RBAC-Regeln, um einen mandantenübergreifenden Zugriff zu verhindern. Mit zunehmender Anzahl von Namespaces wächst die Anzahl der RBAC-Regeln noch schneller. Ein Fehler in einem ClusterRoleBinding kann dazu führen, dass Ressourcen in allen Namespaces offengelegt werden.

Keine echte API-Isolierung. Alle Namespaces nutzen denselben API-Server, dasselbe etcd und dieselben Admission-Webhooks. Ein fehlerhafter Admission-Webhook wirkt sich auf jeden Namespace aus. Ein langsamer benutzerdefinierter Controller, der alle Namespaces überwacht, beeinträchtigt den API-Server für alle Nutzer.

Am besten geeignet für: Kleine Teams, vertrauenswürdige Umgebungen, einfache Anwendungen, bei denen CRD-Konflikte unwahrscheinlich sind.

vcluster: Virtuelle Cluster

So funktionieren sie

vcluster, entwickelt von Loft Labs, erstellt virtuelle Kubernetes-Cluster, die innerhalb von Pods auf einem Host-Cluster laufen. Jeder vcluster verfügt über einen eigenen API-Server – basierend auf k3s, k0s oder Vanilla Kubernetes – sowie einen eigenen Backing Store (etcd oder SQLite). Aus Sicht des Mandanten steht ihm ein vollständiger Kubernetes-Cluster mit Cluster-Admin-Zugriff zur Verfügung. Aus Sicht des Host-Clusters ist ein vcluster lediglich eine Reihe von Pods, die in einem Namespace laufen.

Der zentrale Mechanismus ist der Syncer. Wenn ein Mandant einen Pod in seinem Vcluster erstellt, wandelt der Syncer diesen in einen realen Pod im Host-Cluster um. Der Pod läuft auf den Knoten des Host-Clusters und beansprucht dessen Rechenressourcen. Dienste, Endpunkte und andere Ressourcen werden bidirektional zwischen dem Vcluster und dem Host synchronisiert.

Sie installieren einen vcluster mit einem einzigen Helm . Innerhalb von 30 bis 60 Sekunden verfügen Sie über einen voll funktionsfähigen virtuellen Cluster mit eigener Kubeconfig.

Stärken

Starke Isolierung. Jeder Mandant erhält einen eigenen API-Server, einen eigenen Satz an CRDs und eine eigene Zulassungskonfiguration. Zwei Mandanten können völlig unterschiedliche CRD-Versionen, unterschiedliche Operatoren und unterschiedliche Webhook-Konfigurationen nutzen, ohne dass es zu Konflikten kommt.

Mandanten erhalten vollständigen Cluster-Admin-Zugriff. Im Gegensatz zu Namespaces, in denen Mandanten auf Vorgänge innerhalb des jeweiligen Namespaces beschränkt sind, können vcluster-Mandanten innerhalb ihres virtuellen Clusters ClusterRoles erstellen, CRDs installieren und Einstellungen auf Cluster-Ebene konfigurieren.

Schnelle Erstellung. Das Einrichten eines neuen vClusters dauert 30 bis 60 Sekunden. Dadurch eignen sich vCluster besonders gut für CI/CD-Pipelines, bei denen für jeden Testlauf ein isolierter Cluster benötigt wird.

Echte Kubeconfig-Datei. Mandanten erhalten eine Standard-Kubeconfig-Datei, die mit kubectl, Helm, ArgoCD und allen anderen Kubernetes-Tools kompatibel ist. Es sind keine speziellen clientseitigen Tools erforderlich.

Einschränkungen

Ressourcen-Overhead. Jeder Vcluster betreibt einen API-Server und einen Syncer-Pod. Bei 50 Vclustern sind das 50 API-Server, die auf dem Host-Cluster Speicher und CPU-Leistung beanspruchen. Der Overhead pro Mandant ist zwar gering (etwa 200–500 MB Speicher pro Vcluster), summiert sich jedoch bei steigender Anzahl.

Die Rechenleistung wird weiterhin gemeinsam genutzt. Der Host-Cluster führt alle Workloads aus allen vClustern aus. Ein vCluster-Mandant kann nicht mehr Ressourcen beanspruchen, als seine Quote auf dem Host-Cluster zulässt. Eine Isolierung auf Knotenebene zwischen Mandanten erfordert zusätzliche Tools wie Regeln zur Knotenaffinität oder dedizierte Knotenpools.

Komplexität des Netzwerks. Der Syncer übersetzt Dienste und Endpunkte zwischen dem virtuellen Cluster und dem Host-Cluster. Diese Übersetzungsschicht kann zu Latenz führen und erschwert die Fehlerbehebung im Netzwerk. Ist ein Dienst nicht erreichbar, müssen Sie sowohl den virtuellen Cluster als auch den Host-Cluster überprüfen, um das Problem zu diagnostizieren.

Kommerzielle Komponenten. Der Open-Source-vCluster ist für grundlegende Anwendungsfälle voll funktionsfähig. Die vollständige Plattform – vCluster Platform (ehemals Loft) – bietet zusätzliche Funktionen wie einen Ruhemodus, Zugriffskontrolle und Kostenmanagement, ist jedoch ein kommerzielles Produkt, für das Lizenzgebühren anfallen.

Am besten geeignet für: CI/CD-Umgebungen (temporäre Cluster für Testzwecke), Teams, die Zugriff auf die Cluster-Verwaltung benötigen, Unternehmen mit einer moderaten Anzahl von Mandanten (10–50).

kcp Workspaces: Isolierung nur über die API

So funktionieren sie

kcp stellt Workspaces bereit – isolierte API-Bereiche, die wie eigenständige Kubernetes-Cluster funktionieren. Jeder Workspace verfügt über eigene Ressourcen, CRDs, RBAC-Regeln und eine eigene Zulassungskonfiguration. Die Interaktion mit einem Workspace erfolgt über Standard-kubectl-Befehle und fühlt sich genauso an wie die Interaktion mit einem regulären Kubernetes-Cluster.

Der grundlegende Unterschied zwischen kcp und sowohl Namespaces als auch vcluster besteht darin, dass kcp keine Rechenebene besitzt. Es gibt keine Pods, keine Knoten, keinen Scheduler und keine Container-Laufzeitumgebung. kcp ist eine reine API-Infrastruktur – die Kubernetes-Steuerungsebene, reduziert auf CRDs, RBAC, Zulassungskontrolle und Ressourcenverwaltung.

Wenn tatsächliche Rechenleistung benötigt wird, führt ein API-Anbieter eine Betreiber mit mehreren Mandanten das über die mit ihm verbundenen Arbeitsbereiche wacht APIExport und bündelt Ressourcen in einem echten Backend – einem oder mehreren physischen Kubernetes-Clustern, einer Cloud-Anbieter-API oder einem anderen System, das der Betreiber versteht. Frühere Versionen von kcp enthielten einen Syncer- und einen Transparent-Multi-Cluster-Code (TMC) für die Workload-Planung, aber Beide wurden im Mai 2023 entfernt um das Projekt wieder auf das reine API-Management auszurichten. Die Rechenleistung liegt beim Betreiber, nicht bei kcp selbst.

Stärken

Echte API-Isolierung bei minimalem Overhead. Workspaces sind API-Bereiche in einer gemeinsamen Steuerungsebene und keine laufenden Prozesse. Die Erstellung eines neuen Workspaces ist hinsichtlich des Ressourcenverbrauchs nahezu kostenlos. Eine einzige KCP-Instanz kann auf bescheidener Hardware Tausende von Workspaces hosten.

CRD-Isolierung. Jeder Arbeitsbereich verfügt über eine eigene CRD-Registrierung. Zwei Arbeitsbereiche können völlig unterschiedliche Versionen derselben CRD definieren, ohne dass es zu Konflikten kommt. Dies ist derselbe Vorteil, den vcluster bietet, jedoch ohne den Overhead eines API-Servers pro Mandant.

Hierarchische Arbeitsbereiche. Arbeitsbereiche können untergeordnete Arbeitsbereiche enthalten, wodurch eine organisatorische Hierarchie ermöglicht wird. Ein Arbeitsbereich auf oberster Ebene für einen Geschäftsbereich kann untergeordnete Arbeitsbereiche für jedes Team enthalten, die wiederum untergeordnete Arbeitsbereiche für jede Umgebung enthalten können. Richtlinien und Konfigurationen können sich über die Hierarchie hinweg durchsetzen.

API-Freigabe über APIExport und APIBinding. Serviceteams können APIs mithilfe von APIExport veröffentlichen, und andere Arbeitsbereiche können diese APIs mithilfe von APIBinding nutzen. Dadurch entsteht ein nativer Servicekatalogmechanismus. Ein Datenbankteam kann eine Datenbank Die API ermöglicht es Anwendungsteams, eine Verbindung herzustellen und Datenbankinstanzen zu erstellen, ohne die zugrunde liegende Implementierung zu verstehen.

Skalierbar auf Tausende von Mandanten. Da die Arbeitsbereiche keine Rechenaufgaben ausführen, kann die Steuerungsebene weitaus mehr Mandanten verwalten als vcluster. Der begrenzende Faktor ist die Kapazität des KCP-Servers, API-Anfragen zu bearbeiten, und nicht der gesamte Speicherverbrauch der API-Server pro Mandant.

Einschränkungen

Keine native Rechenkapazität. kcp führt Workloads nicht selbst aus. Sie benötigen einen Multi-Tenant-Betreiber und mindestens einen physischen Kubernetes-Cluster (oder ein gleichwertiges Backend) für die eigentlichen Pods. Dies erhöht die Komplexität der Architektur – Sie verwalten sowohl eine kcp-Steuerungsebene als auch die nachgelagerte Rechenkapazität, die hinter Ihren APIs liegt.

Reifegrad der CNCF Sandbox. kcp befindet sich in aktiver Entwicklung. Die API-Oberfläche kann sich zwischen den einzelnen Releases ändern. Der Einsatz in der Produktion erfordert eine sorgfältige Bewertung und die Bereitschaft, Änderungen im Upstream-Projekt zu verfolgen.

Lücken bei den Ökosystem-Tools. Standard-Tools wie Prometheus, ArgoCD und Flux unterstützen kcp-Workspaces derzeit noch nicht nativ. Die Überwachung des Status über Workspaces hinweg und ihrer nachgelagerten Recheninstanzen erfordert eine individuelle Integration. Diese Lücke wird sich mit der Zeit schließen, bedeutet aber derzeit noch zusätzlichen technischen Aufwand.

Eine steilere Lernkurve. Das Modell aus Workspace, APIExport und APIBinding ist neu und den meisten Kubernetes-Anwendern noch unbekannt. Teams müssen nicht nur Kubernetes-Konzepte verstehen, sondern auch kcp-spezifische Konzepte wie Workspace-Hierarchien, Multi-Tenant-Operatoren und die gemeinsame Nutzung von APIs.

Warnung: kcp ist ein CNCF-Sandbox-Projekt. Prüfen Sie es sorgfältig, bevor Sie es in der Produktion einsetzen. Die Mechanismen „APIExport“ und „APIBinding“ befinden sich noch in der Entwicklungsphase, und zwischen den einzelnen Versionen sind kompatibilitätsbrechende Änderungen möglich.

Am besten geeignet für: Plattformteams, die interne Entwicklerplattformen oder SaaS-Steuerungsebenen aufbauen, sowie Unternehmen mit vielen Mandanten (100+), bei denen die Isolierung der Rechenressourcen weniger wichtig ist als die Isolierung der APIs.

Direkter Vergleich

Entscheidungsrahmen

Nutzen Sie diese Fragen, um den richtigen Ansatz für Ihre Situation zu finden.

Fangen Sie hier an: Wie viele Mieter haben Sie?

• Weniger als 10 Mandanten, bewährte Teams. Namespaces sind wahrscheinlich ausreichend. Füge ResourceQuotas und NetworkPolicies hinzu. Übertreibe es nicht.
• 10–50 Mandanten; erfordert CRD-Isolation oder Cluster-Admin. vcluster bietet Ihnen eine starke Isolation bei vertretbarem Overhead. Besonders gut geeignet für CI/CD- und kurzlebige Umgebungen.
• Über 50 Mandanten, Aufbau einer Plattform. kcp workspaces lassen sich besser skalieren und bieten Isolation auf API-Ebene, ohne dass pro Mandant Rechenkosten anfallen. Die Investition lohnt sich, wenn Sie eine interne Entwicklerplattform aufbauen.

Weitere zu berücksichtigende Faktoren:

• Wenn Mieter ihre eigenen Operatoren installieren müssen, benötigen Sie vcluster oder kcp. Namespaces können keine CRD-Isolation gewährleisten.
• Wenn Sie schnelle, kurzlebige Umgebungen für CI-Pipelines benötigen, ist die Startzeit von vcluster von nur 30 Sekunden kaum zu übertreffen.
• Wenn Sie einen Servicekatalog mit Self-Service-APIs erstellen, sind die Mechanismen „APIExport“ und „APIBinding“ von kcp genau für diesen Anwendungsfall konzipiert.
• Wenn Sie heute bewährte, produktionsreife Tools benötigen, bietet vcluster das ausgereifteste Ökosystem. Greifen Sie auf Namespaces zurück, falls Ihnen selbst vcluster zu viel erscheint.

Tipp: Diese Ansätze schließen sich nicht gegenseitig aus. Sie können Namespaces innerhalb eines KCP-Arbeitsbereichs verwenden oder VCluster auf Clustern ausführen, die von KCP verwaltet werden. Betrachten Sie sie als Ebenen und nicht als Alternativen.

Kombination verschiedener Ansätze

In der Praxis werden auf realen Plattformen oft mehrere Ansätze kombiniert. Hier sind drei Muster, die sich in der Praxis bewährt haben.

kcp für die Isolierung auf Organisationsebene, Namespaces für die Trennung der Teams. Richten Sie pro Geschäftsbereich einen kcp-Arbeitsbereich ein, wodurch jeder Bereich auf API-Ebene isoliert wird und über eigene CRDs und RBAC verfügt. Verwenden Sie innerhalb jedes Arbeitsbereichs Namespaces für die Trennung auf Teamebene. So profitieren Sie von der Skalierbarkeit von kcp auf Organisationsebene und der Einfachheit von Namespaces auf Teamebene.

vcluster für temporäre Entwicklungs- und Testumgebungen. vclusters werden auf einem gemeinsam genutzten Rechencluster ausgeführt, der von KubeOne oder KKP verwaltet wird. Entwickler richten einen vcluster für einen Feature-Branch ein, führen ihre Integrationstests darauf durch und lösen ihn auf, sobald der Branch zusammengeführt wurde. Der Host-Cluster übernimmt die Ressourcenverwaltung und die Kostenkontrolle.

Namespaces als Ausgangspunkt, mit dem Ziel einer stärkeren Isolierung. Beginnen Sie mit kleinen Teams und Namespaces. Wenn die Anforderungen eines Teams über das hinausgehen, was Namespaces bieten können – wenn es eigene CRDs, eigene Operatoren oder Cluster-Admin-Zugriff benötigt –, führen Sie es in einen vcluster oder einen kcp-Workspace über. So vermeiden Sie in der Anfangsphase eine übermäßige Komplexität und bieten gleichzeitig einen klaren Wachstumspfad.

Nächste Schritte

• Was ist KCP? – Erfahren Sie mehr über die Grundlagen von KCP und wie es sich von Kubernetes unterscheidet
• kcp installieren und Ihren ersten Arbeitsbereich erstellen – probieren Sie kcp anhand einer Schritt-für-Schritt-Anleitung aus
• vcluster-Dokumentation – Entdecken Sie den vcluster-Ansatz und probieren Sie ihn auf Ihrem eigenen Cluster aus

Zusammenfassung

Namespaces bieten eine grundlegende Isolierung ohne Overhead, versagen jedoch, sobald es zu Konflikten mit CRDs, Problemen mit „Noisy Neighbors“ oder mehr als ein paar Dutzend Mandanten kommt. vcluster stellt jedem Mandanten einen vollständigen virtuellen Cluster mit starker Isolation zur Verfügung, was jedoch mit einem Ressourcen-Overhead pro Mandant verbunden ist, der die praktische Skalierbarkeit auf etwa 100 Mandanten begrenzt. kcp-Workspaces bieten Isolation auf API-Ebene mit minimalem Overhead und lassen sich auf Tausende von Mandanten skalieren, erfordern jedoch eine separate Rechenebene und bringen die Kompromisse eines noch in der Entwicklung befindlichen Projekts mit sich.

Entscheiden Sie sich für Namespaces, wenn Ihre Teams einander vertrauen und Sie nur wenige Mandanten haben. Wählen Sie vcluster, wenn Sie eine starke Isolierung bei moderatem Skalierungsbedarf benötigen, insbesondere für CI/CD- und Entwicklungsumgebungen. Entscheiden Sie sich für kcp, wenn Sie eine interne Entwicklerplattform oder eine SaaS-Steuerungsebene aufbauen, die viele Mandanten bedienen muss, ohne dass pro Mandant Kosten für den Betrieb virtueller Cluster anfallen.

Das Wichtigste ist, dass es sich hierbei nicht um konkurrierende Technologien handelt. Sie arbeiten auf verschiedenen Ebenen des Stacks und lassen sich miteinander kombinieren. Beginnen Sie mit dem einfachsten Ansatz, der Ihren aktuellen Anforderungen entspricht, und bauen Sie im Zuge des Wachstums Ihrer Plattform eine stärkere Isolierung auf.