Jedes Pitch für eine Hybrid-Cloud-Management-Plattform beginnt am selben Punkt: ein Diagramm mit Ihren On-Premise-Servern links, einer Public Cloud rechts, und einem Pfeil dazwischen, beschriftet mit Migration. Der Pfeil ist das Produkt. Er ist auch der Grund, warum die meisten dieser Projekte ins Stocken geraten, denn der Pfeil kostet achtzehn Monate, und der Nutzen kommt erst an deren Ende. Die nützlichere Frage ist, was Sie schon morgen von einem Ort aus verwalten könnten, ohne dass etwas verschoben oder neu geschrieben werden muss.
Hybrid ist keine Architekturentscheidung, die die meisten Teams bewusst getroffen haben. Es ist das, was nach einem Jahrzehnt übrig bleibt: ein Rack mit eigener Hardware, auf dem noch immer das läuft, was niemand leicht verschieben kann, ein ERP, das niemand anfassen will, Workloads bei einem Hyperscaler, weil ein Kunde danach gefragt hat, günstigeres Compute irgendwo in Europa, weil jemand nachgerechnet hat, und ein paar Server in einer Colocation-Anlage, die älter sind als die Hälfte des aktuellen Teams. Niemand hat das entworfen. Jeder muss es betreiben.
Warum Hybrid meist zwei Teams bedeutet
Die praktischen Kosten von Hybrid sind organisatorisch. Cloud-Ressourcen werden im Browser mit API-Tokens und Tags verwaltet; die physische Umgebung wird mit SSH, einem Konfigurationstool und institutionellem Wissen verwaltet. Zwei Toolchains, zwei mentale Modelle, zwei Sätze von Runbooks, und meist zwei Gruppen von Menschen, die die Arbeit der jeweils anderen als die Legacy-Seite oder die teure Seite bezeichnen. Das Inventar wird zu einem Zusammenführen von Exporten. Das Access-Review wird zu zwei Access-Reviews. Incidents, die die Grenze überschreiten, werden zu einer Diskussion darüber, wessen Problem das eigentlich ist.
Die übliche Antwort der Anbieter ist, eine Seite wie die andere aussehen zu lassen: einen Private-Cloud-Stack auf der eigenen Hardware installieren, oder alles in die Public Cloud heben und die Sache erledigt haben. Beides sind legitime Strategien, und beides ist enorm aufwendig. Beide teilen außerdem eine Annahme, die es zu hinterfragen lohnt - dass Vereinheitlichung auf der Infrastruktur-Ebene stattfinden muss. Das muss sie nicht. Das meiste, was ein Team tatsächlich vereinheitlicht braucht, liegt eine Etage höher: Inventar, Zugriff, Änderungsprotokolle, Kosten und die Fähigkeit zu handeln.
Was eine Hybrid-Cloud-Management-Plattform nicht tun darf
Eine Hybrid-Cloud-Management-Plattform verdient sich ihren Platz durch das, was sie sich weigert vorauszusetzen. Sie darf nicht verlangen, dass Sie einen Workload verschieben, bevor sie nützlich wird. Sie darf keinen Agent auf jeder Maschine voraussetzen, um Ihnen Ihre Cloud-Umgebung zu zeigen, und kein Cloud-Konto, um Ihnen Ihre Racks zu zeigen. Sie darf nicht zu einer neuen Abhängigkeit in Ihrem kritischen Pfad werden - fällt sie aus, laufen Ihre Systeme weiter, und Sie verlieren Sichtbarkeit, nicht Verfügbarkeit. Und sie darf Ihre Infrastruktur nicht in ihrem eigenen Format als Geisel halten.
Deshalb haben wir Sencai import-first gebaut. Sie verbinden ein Provider-Konto mit begrenzten Credentials, und Ihre bestehenden Instanzen, Netzwerke und Storage erscheinen so, wie sie sind - nicht als etwas, das Sie neu aufbauen müssen. Niemand, der eine Infrastrukturplattform evaluiert, hat leere Infrastruktur, und ein Produkt, das erst dann Wert zeigt, wenn Sie etwas darin neu aufgebaut haben, hat sich seine eigene Demo selbst verbaut. Die erste Sitzung sollte Ihnen Ihre Umgebung zeigen - inklusive der Teile, die Sie insgeheim vergessen hatten.
Bei dem anfangen, was bereits existiert
Auf der Cloud-Seite bedeutet das elf Provider hinter einer Oberfläche: Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Akamais Linode und Oracle Cloud. Keine Abstraktion nach dem kleinsten gemeinsamen Nenner, die alles Interessante versteckt - Netzwerke, Firewall-Regeln und DNS-Einträge werden direkt beim Provider erstellt und geändert, sodass das, was Sie sehen, dem entspricht, was der Provider tatsächlich hat. Und alles, was Sie konfigurieren, funktioniert weiter, wenn Sie uns morgen früh nicht mehr nutzen.
Auf der physischen Seite bringt ein Host-Agent Ihre eigenen Server in dasselbe Inventar: eine Maschine im eigenen Rack, in einem Colocation-Käfig, oder eine Box bei einem Provider, den wir nicht direkt integrieren. Sie steht neben den Cloud-Ressourcen statt in einem eigenen Abschnitt, denn der ganze Sinn ist, dass „Was betreiben wir eigentlich“ eine einzige Antwort haben soll. Für Teams, deren Rahmenbedingungen eine gehostete Control Plane grundsätzlich ausschließen, gibt es eine On-Premise-Edition, jährlich lizenziert, mit Support.
Die On-Premise-Hälfte ist keine Legacy
In diesem Markt gibt es die bequeme Annahme, dass eigene Hardware ein Übergangszustand auf dem Weg zu etwas Besserem ist. Manchmal stimmt das. Oft ist es die richtige Antwort: vorhersehbare, schwere Workloads, bei denen Sie die Abschreibung selbst tragen, Daten, die Regulierung oder Vertrag in einem bestimmten Gebäude halten müssen, Latenzanforderungen, die keine Region erfüllen kann, und Hardware mit noch Jahren an Nutzungsdauer. Diese Umgebung in Ihrem Tooling als zweitklassig zu behandeln, beschleunigt ihre Ablösung nicht. Es sorgt nur dafür, dass sie schlechter überwacht wird.
Eine Control Plane über beide Hälften hinweg verändert kleine Dinge, die sich summieren. Spend wird providerübergreifend mit Caps erfasst, sodass die Frage, was eine Umgebung kostet, eine einzige Antwort hat statt fünf Exporte. Rollen und Einladungen gelten pro Organisation, sodass ein Access-Review genau ein Review ist. Und jede Änderung, ob Cloud oder On-Premise, landet im selben Append-only-, hash-verketteten Audit-Trail, exportiert mit dem Hash jedes Eintrags und dem seines Vorgängers, sodass ein Auditor die Abfolge unabhängig verifizieren kann.
Was eine einzige Control Plane Ihnen bringt
Die ehrliche Einordnung ist: Nichts davon macht Hybrid einfach. Zwei Hosting-Modelle haben weiterhin zwei unterschiedliche Ausfallcharakteristiken, zwei Beschaffungsprozesse und zwei Kostenstrukturen, und keine Oberfläche beseitigt das. Was sie beseitigt, ist die Steuer, die Sie für die Grenze zwischen beiden zahlen: die doppelten Inventare, das zweite Access-Review, der Incident, bei dem niemand sagen kann, was die On-Premise-Seite zu diesem Zeitpunkt getan hat. Diese Steuer zahlt Ihr kleinstes Team, fortlaufend, und deshalb fühlt sich Hybrid schlimmer an, als es tatsächlich ist.
Der Test, den wir an jede Hybrid-Cloud-Management-Plattform anlegen würden, unsere eingeschlossen, ist deshalb kurz. Können Sie innerhalb einer Stunde alles sehen, was Sie betreiben, gemietet wie eigenes, in einer Liste, ohne irgendetwas zu migrieren? Können Sie sagen, wer letzten Monat was geändert hat, auf beiden Seiten der Grenze? Können Sie beantworten, was das kostet, ohne fünf Konsolen zu öffnen? Wenn ja, ist Hybrid wieder einfach nur Infrastruktur. Wenn nein, haben Sie keine Plattform, sondern eine weitere Konsole.