Cloud-Kontrollebene
Eine Cloud-Kontrollebene ist die Schicht aus Schnittstellen, APIs und Diensten, mit denen Sie Infrastruktur bereitstellen, konfigurieren und verwalten – getrennt von der Datenebene, die Ihre Workloads tatsächlich ausführt und Ihren Traffic transportiert. Jeder Anbieter bringt seine eigene mit; der Begriff umfasst auch Systeme, die mehrere Anbieter als eine einzige Ebene verwalten.
Jede Infrastruktur hat zwei getrennte Schichten. Die Datenebene ist die Infrastruktur selbst: die virtuellen Maschinen, auf denen Ihre Anwendung läuft, das Netzwerk, das Pakete zwischen ihnen transportiert, die Festplatte, die Lese- und Schreibzugriffe bedient. Die Kontrollebene ist alles, womit Sie festlegen, wie diese Infrastruktur aussehen soll, und womit Sie sie ändern – die API, die Konsole, die CLI, das Berechtigungssystem, das entscheidet, wer eine Änderung vornehmen darf. Wenn Sie in einer Cloud-Konsole eine VM erstellen, eine Festplatte vergrößern oder einen Firewall-Port öffnen, bedienen Sie die Kontrollebene. Die Instanz, die hochfährt, die zusätzlichen Gigabyte, die verfügbar werden, der Traffic, der zu fließen beginnt – das ist die Datenebene, die auf das reagiert, was die Kontrollebene ihr aufgetragen hat.
Die Unterscheidung wird nützlicher, sobald ein Team mehr als einen Anbieter einsetzt. AWS hat eine Kontrollebene. Google Cloud, Azure, Hetzner und jeder andere Anbieter ebenso – jeder mit eigener Konsole, eigener API-Form, eigenen Zugangsdaten, eigener Vorstellung davon, wie eine „Security Group" oder eine „Firewall-Regel" heißt. Ein Team, das drei Clouds und zwanzig Bare-Metal-Server betreibt, bedient in Wirklichkeit drei oder vier separate Kontrollebenen nebeneinander – plus was auch immer es zur Verwaltung der Server nutzt, die in gar keiner Cloud liegen. Nichts zwingt diese Kontrollebenen dazu, sich gegenseitig abzugleichen, und nichts außerhalb des eigenen Prozesses sorgt dafür, dass eine in einer von ihnen vorgenommene Änderung für jemanden sichtbar bleibt, der auf eine andere blickt.
„Cloud-Kontrollebene" wird auch enger gefasst verwendet – innerhalb von Kubernetes ist die Kontrollebene der API-Server, der Scheduler und der Controller-Manager, die entscheiden, wo Pods laufen, im Unterschied zu den Kubelets und Containern, die sie tatsächlich auf den Nodes ausführen. Eine „Multi-Cloud"- oder „vereinheitlichte" Kontrollebene überträgt dieselbe Idee auf mehrere Anbieter: ein einziger Ort, um Infrastruktur zu sehen und darauf zu handeln, die physisch in mehreren verschiedenen Accounts, Regionen und bei mehreren Anbietern liegt, statt einer Oberfläche pro Anbieter. Sie ersetzt nicht die zugrunde liegenden Kontrollebenen der Anbieter – eine Anfrage landet am Ende immer noch als API-Aufruf bei AWS, bei Hetzner oder beim Fleet-Agent auf einem Bare-Metal-Server –, sondern legt sich davor, sodass die Person, die die Änderung vornimmt, nur ein System lernen muss.
Warum die Unterscheidung operativ wichtig ist
Die meisten Infrastruktur-Vorfälle und Lücken bei Audits lassen sich auf Probleme der Kontrollebene zurückführen, nicht der Datenebene: eine Änderung, die niemand protokolliert hat, eine Berechtigung, die niemand entzogen hat, eine Firewall-Regel, die in der Konsole eines Anbieters geöffnet wurde und die sonst niemand im Team sieht. Wenn jede Cloud ihre eigene Kontrollebene und ihren eigenen Audit-Trail hat, wird „wer hat das wann geändert\" zu einer Frage, die Sie beantworten, indem Sie sich in drei oder vier verschiedenen Konsolen anmelden und Zeitstempel von Hand vergleichen – oder die Sie gar nicht beantworten. Für Teams unter Compliance-Rahmenwerken wie NIS2 ist diese Lücke nicht nur unpraktisch: Änderungshistorie, Zugriffskontrolle und Vorfallsnachweise sind genau das, wonach ein Prüfer oder eine Aufsichtsbehörde zuerst fragt, und eine fragmentierte Kontrollebene ist der Grund, warum diese Nachweise oft nicht an einem Ort existieren.
Wie Sencai dazu passt
Sencai ist eine Kontrollebene, die sich über die nativen legt: Sie verbindet sich mit Accounts bei elf Cloud-Anbietern sowie mit On-Premise- und Bare-Metal-Servern über einen leichtgewichtigen Fleet-Agent und inventarisiert in dem Moment, in dem ein Account verbunden wird, was dort bereits läuft – ohne dass eine Migration nötig ist. Von da an funktionieren Bereitstellung, Start, Stopp, Größenänderung und Löschen von Instanzen anbieterunabhängig auf die gleiche Weise. Sie können bestehende Accounts verbinden (nichts wird verschoben, Zugangsdaten bleiben beim Anbieter jederzeit widerrufbar) oder Sencai Kapazität direkt bereitstellen und abrechnen lassen – und beides in einer Organisation mischen. Jede Aktion bei jedem verbundenen Anbieter landet in einem einzigen, unveränderlichen und hash-verketteten Audit-Log (append-only), sodass „wer hat das wann geändert\" eine Abfrage ist, keine Ermittlung.
Inventarisierung und Provisioning ansehen →