Hinter einer einzelnen virtuellen Maschine stecken sieben Systeme, die zusammenspielen müssen. Diese Komplexität verschwindet nicht — man kann sie nur verschieben. Warum wir das Cockpit so bauen, wie wir es bauen.
Das Schwierigste beim Bau einer Cloud? Nicht, sie skalierbar zu machen. Sondern sie trotz aller Komplexität einfach zu halten.
Hinter einer einzelnen virtuellen Maschine stecken Compute, Storage, Netzwerk, Firewalls, Identitäten, Monitoring und Abrechnung. Sieben Dinge, die zusammenspielen müssen, damit am Ende ein Rechner läuft, mit dem jemand arbeiten kann.
Jedes dieser Systeme hat eigene Begriffe, eigene Zustände und eigene Fehlerfälle. Ein Netzwerk-Port kann existieren, während die Maschine, zu der er gehört, längst gelöscht ist. Eine Firewall-Regel kann korrekt sein und trotzdem den Zugriff verhindern, weil eine zweite Regel eine Ebene tiefer greift. Ein Volume kann verfügbar sein, aber an der falschen Stelle hängen.
Wer eine Cloud betreibt, verbringt einen erheblichen Teil seiner Zeit damit, genau solche Zustände auseinanderzuhalten.
Diese Komplexität verschwindet nicht. Man kann sie nur verschieben. Entweder sie liegt bei uns, oder sie liegt jeden Tag beim Kunden.
Das ist die eigentliche Produktentscheidung hinter jeder Cloud-Oberfläche, und sie wird viel zu selten offen ausgesprochen. Eine Plattform, die jede Einstellung durchreicht, ist einfacher zu bauen. Sie ist mächtig, sie ist ehrlich in dem Sinne, dass sie nichts versteckt — und sie kostet jeden Kunden jeden Tag Zeit.
Wir haben uns für die andere Seite entschieden.
Deshalb bauen wir das Brillianza Cockpit mit einem einfachen Anspruch:
Das klingt banal. In der Umsetzung ist es das überhaupt nicht.
Jede dieser Regeln heißt, dass bei uns jemand länger nachdenkt, damit später jemand anderes weniger nachdenken muss. Und man sieht dem Ergebnis am Ende nie an, wie lange es gedauert hat.
Gute Bedienbarkeit sieht immer aus, als wäre sie einfach gewesen.
Die zweite Regel ist die, die am meisten Arbeit macht.
Ein Preis pro Stunde ist schnell angezeigt. Schwieriger ist die Frage, die Kunden tatsächlich haben: Was kostet mich diese Konfiguration am Monatsende — mit Storage, mit Lizenz, mit allem?
Das heißt, die Abrechnungslogik muss schon beim Anlegen greifen, nicht erst im Rechnungslauf. Ändert jemand die Größe einer Maschine, muss sich der Preis daneben mitändern. Das ist technisch deutlich unangenehmer, als es aussieht — und es ist der Unterschied zwischen einer Cloud, deren Rechnung man nachvollzieht, und einer, über die man sich am Monatsende ärgert.
Wer durchrechnen möchte, wie sich das auf eine konkrete Umgebung auswirkt, kann das im Konfigurator tun.
Denn eine gute Cloud macht Komplexität beherrschbar.
Eine wirklich gute Cloud hält sie vom Kunden fern.
Das ist kein Gegensatz zu Kontrolle. Wer die volle Tiefe braucht, bekommt sie — über die API, über Kubernetes, über die Ebenen darunter. Die Standardaufgabe darf nur nicht die Tiefe voraussetzen. Eine virtuelle Maschine anzulegen ist eine Standardaufgabe.
Welche Funktion ist bei eurem heutigen Cloud-Anbieter unnötig kompliziert? Ich bin ernsthaft an Antworten interessiert — solche Beispiele landen bei uns direkt im Backlog. Der Kontakt steht offen.
Wir zeigen unverbindlich, wie eine souveräne Umgebung für euren Anwendungsfall aussehen würde — technisch und preislich.
Es wird immer einen Grund geben, den vermeintlich leichten Weg zu gehen — Know-how, Kapital, äußere Umstände. Warum wir Brillianza trotzdem gegründet haben und was Unabhängigkeit im Alltag konkret bedeutet.
Ein deutscher Standort allein macht keine souveräne Cloud. Entscheidend sind zwei Grundpfeiler — Open Source und Interoperabilität. Warum OpenStack und Kubernetes dafür die richtige Kombination sind.