Inventar und Provisioning
Die meisten Infrastrukturprobleme beginnen damit, nicht zu wissen, was man tatsächlich hat. Sencai liest aus, was bereits läuft, in dem Moment, in dem Sie ein Cloud-Konto verbinden - Instanzen, Netzwerke, Speicher, DNS - ohne Migration und ohne Wartezeit, und zeigt dasselbe Inventar für jeden Linux-Server, ob Cloud oder Bare Metal, sobald der Fleet-Agent darauf läuft. Von dort aus startet, stoppt, skaliert und löscht dieselbe Konsole Ressourcen über Provider hinweg, mit einem Workflow statt elf verschiedenen. Was Sie sehen, ist nie eine veraltete Kopie: Für DNS-, Firewall- und Netzwerkänderungen handelt Sencai direkt beim Provider.
Was in dem Moment erscheint, in dem Sie sich verbinden
Verbinden Sie ein Cloud-Konto, und Sencai liest aus, was bereits läuft: Instanzen, Netzwerke, Speichervolumes, DNS-Zonen. Das geschieht in dem Moment, in dem Zugangsdaten hinzugefügt werden - es gibt keinen Importschritt, keine Wartezeit, keine Anforderung, zuerst irgendetwas zu verschieben. Erkennung ist standardmäßig nur lesend. Nichts gerät unter aktive Verwaltung, bis Sie es so entscheiden, Ressource für Ressource, sodass eine erste Verbindung nie riskiert, versehentlich die Produktion zu berühren. Das zählt am meisten bei Infrastruktur, von der niemand mehr eine vollständige Karte hat: Konten, die vor Jahren von inzwischen ausgeschiedenen Personen eröffnet wurden, Server, die für ein ausgeliefertes und vergessenes Projekt provisioniert wurden, DNS-Zonen, an deren Registrierung sich niemand erinnert. Das Verbinden des Kontos genügt, um das alles in einem Inventar zu sehen, einheitlich normalisiert, unabhängig davon, bei welchem Provider es liegt. Sie können dabei stehenbleiben und einfach eine Karte haben, oder anfangen, einzelne Ressourcen unter Verwaltung zu bringen - Start/Stopp, Größenänderung, DNS, Firewall-Regeln - eine nach der anderen, in Ihrem eigenen Tempo.
Elf Provider, eine Konsole
Sencai verbindet sich mit Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Akamai/Linode und Oracle Cloud - die vollständige Liste unter Integrationen - plus jedem Linux-Server, den Sie selbst betreiben, Cloud oder Bare Metal, über einen leichtgewichtigen Fleet-Agent. Provisioning, Starten, Stoppen, Größenändern und Löschen einer Instanz ist derselbe Workflow, egal auf welchem der Anbieter sie läuft, sodass Ihr Team aufhört, zwischen elf Konsolen mit elf verschiedenen mentalen Modellen zu wechseln. Diese Konsistenz erstreckt sich darauf, wie Ressourcen dargestellt werden, nicht nur, wie sie bedient werden. Eine EC2-Instanz, ein Hetzner-Cloud-Server und eine Azure-VM erscheinen als dieselbe Art von Objekt mit denselben Feldern, sodass sich das Inventar wie ein System liest statt wie elf von Hand zusammengeflickte Exporte. Für ein Team mit gemischter Infrastruktur - etwas AWS für einen Kunden, Hetzner für den Rest, eine Handvoll Bare-Metal-Boxen in einem Colo - liegt genau in dieser Normalisierung der größte Wert: ein Ort zum Hinschauen, eine Art zu handeln, unabhängig davon, wer die darunterliegende Rechenleistung abrechnet.
Provisioning, bei der Ressource, die Sie tatsächlich gewählt haben
Sobald eine Ressource unter aktiver Verwaltung steht, startet, stoppt, skaliert oder löscht dieselbe Konsole sie - dieselben Aktionen, derselbe Workflow, egal ob es sich um eine über Sencai provisionierte Instanz handelt oder um eine, die bereits lief, als Sie das Konto verbunden haben. Es gibt keinen separaten Pfad für von Sencai erstellte Ressourcen gegenüber gefundenen; entscheidend ist, eine Ressource in die Verwaltung aufzunehmen, nicht ihre Herkunft. Verwaltung wird Ressource für Ressource gewährt, nie kontoweit. Das Verbinden eines Kontos stellt niemals automatisch alles unter Sencais Kontrolle - Sie wählen, welche Instanzen, welche Netzwerke, welche Speichervolumes aktiv verwaltet werden, und alles andere bleibt im Inventar sichtbar, ohne angefasst zu werden. Das ist Absicht: Teams mit Produktionsinfrastruktur, die sie unangetastet lassen wollen, und Dev- oder Testinfrastruktur, die sie automatisiert haben wollen, müssen diese Grenze Ressource für Ressource ziehen, nicht Provider für Provider. Der Lifecycle-Workflow selbst ändert sich nicht danach, wo Sie diese Grenze ziehen - Starten, Stoppen, Größenändern und Löschen funktionieren auf beiden Seiten dieser Grenze gleich.
Live-Kontrolle, keine zwischengespeicherte Kopie
Bei DNS-Einträgen, Firewall- und Security-Group-Regeln sowie virtuellen Netzwerken geschehen Aktionen in Sencai synchron direkt beim Provider, nicht gegen eine gespeicherte Kopie Ihrer Konfiguration, die später nachzieht. Ändern Sie eine Firewall-Regel, geschieht diese Änderung sofort beim Provider; was Sie danach sehen, spiegelt den tatsächlichen aktuellen Zustand beim Provider wider, nicht den letzten Zeitpunkt, zu dem Sencai zufällig synchronisiert hat. Wie tief diese Live-Kontrolle reicht, variiert je nach Fähigkeit und Provider, und wir sagen das offen, statt die Grenze zu verwischen. DNS-, Firewall- und Netzwerkverwaltung sind drei getrennte Fähigkeiten, nicht eine Funktion mit drei Namen, und die Abdeckung ist bei keiner davon über alle Provider identisch - manche Provider unterstützen heute Live-, synchrone Kontrolle für eine der drei, aber noch nicht für die anderen beiden. Das ist Sencais eigener Ausbaustand, keine vom Provider gesetzte Obergrenze, und wir erweitern das Provider für Provider statt alles auf einmal zu versprechen - siehe Integrationen für das, was bei jedem heute live ist.
Eigene Cloud mitbringen, oder Sencai das Konto führen lassen
Die meisten Teams beginnen mit BYOC: Sie verbinden ein bestehendes Konto, Ihre Vertrags- und Abrechnungsbeziehung zum Provider bleibt genau dort, wo sie ist, und Sencai migriert nie etwas. Zugangsdaten sind im Ruhezustand verschlüsselt, und der Zugriff kann beim Provider jederzeit widerrufen werden - Sencai zu trennen ist ebenso endgültig wie den API-Schlüssel jeder anderen Integration zu widerrufen. Für Teams, die lieber kein direktes Konto bei jedem genutzten Provider führen möchten, kann Sencai diese Kapazität stattdessen unter seinem eigenen Konto provisionieren und abrechnen. Sie erhalten einen Vertrag und eine Rechnung, die Infrastruktur über mehrere Provider hinweg abdeckt, berechnet zu dem, was der Provider verlangt, plus einer Marge von 2 %, als eigene Position auf der Abrechnung ausgewiesen statt in eine größere Zahl eingerechnet. Beide Modelle koexistieren innerhalb derselben Organisation: mit BYOC beginnen und später verwaltete Kapazität für einen neuen Provider hinzufügen, oder verwaltet beginnen und ein bestehendes Konto als BYOC einbringen, sobald es sinnvoll ist. Keiner der beiden Wege ist eine Sackgasse für den anderen.
Eine Aufzeichnung darüber, wer was geändert hat
Jede über Sencai vorgenommene Aktion - eine Größenänderung, eine gelöschte Instanz, eine geänderte Firewall-Regel, ein verbundenes Konto - schreibt einen Eintrag in ein nur anfügbares, hash-verkettetes Audit-Log. Einträge lassen sich nachträglich weder bearbeiten noch löschen; der Nachweis ist die Kette selbst. „Wer hat das geändert, und wann" wird zu etwas, das Sie in Sekunden abfragen, statt etwas, das Sie später aus Provider-Konsolen und Chat-Verlauf rekonstruieren. Genau diese Aufzeichnung brauchen die meisten Sicherheitsprüfungen und Vorfallsnachbetrachtungen tatsächlich, und sie ist direkt in Inventar und Provisioning eingebaut statt separat angeflanscht - jeder Erkennungslauf, jede Lifecycle-Aktion, jede Live-Änderung beim Provider landet bereits in derselben Kette. Für die vollständigere Compliance- und Nachweisgeschichte, einschließlich dessen, was Sencai anstelle eines Zertifikats liefert, das es nicht hat, siehe Sicherheit und Compliance.
Sehen Sie Ihre Infrastruktur an einem Ort
Verbinden Sie ein Konto im kostenlosen Plan - ein Nutzer, eine Organisation, fünf verwaltete Ressourcen, keine Kreditkarte erforderlich - oder starten Sie eine 14-tägige Testversion mit vollem Funktionsumfang. Die meisten Teams haben ihr erstes Deployment in unter 30 Minuten laufen.