Civo ist der Cloud-Anbieter, dem ich meine eigenen Produktivsysteme anvertraue. Ich wollte Cluster, S3-Buckets und Firewalls schneller verwalten, ohne den ganzen Tag im Web-Dashboard zu verbringen. Deshalb habe ich CivoCloudManager gebaut, eine native macOS-App, die direkt mit der Civo-API spricht. Dann habe ich sie kostenlos in den App Store gestellt und beschlossen, die weitere Entwicklung öffentlich für die Civo-Community zu führen.
Dieser Beitrag beschreibt die Architektur und die Roadmap. Zwei Monate später läuft die App auf echten Schreibtischen.
Warum selbst bauen und warum verschenken
Civos Web-Dashboard ist gut. Aber auch ein gutes Web-Dashboard bleibt ein Browser-Tab unter vielen, mit Aktualisieren-Knopf und ohne Status in der Menüleiste. Zehn Cluster-Kontexte gleichzeitig im Blick zu behalten, ist so kaum möglich. Eine native App löst das, und die Civo-Community fragt in den Slack-Channels seit Jahren danach.
Ich hatte zwei Möglichkeiten: warten, bis jemand anderes sie baut, oder sie selbst bauen und nichts dafür verlangen. Weil sie kostenlos ist, wird sie Teil dessen, wie sich das Civo-Ökosystem anfühlen sollte. Nebenbei ist sie das ehrlichste Referenzprojekt, das ich Kunden mit Interesse an Cloud-Plattformen zeigen kann.
Die Verteilung über den App Store ist kostenlos; der Quellcode liegt auf GitHub unter einer Lizenz, die sinngemäß sagt: nutzen, forken, daraus lernen.
Die Architektur: keine Abhängigkeiten, reines SwiftUI
Die ganze App ist ein einziges Swift-Package ohne Bibliotheken von Drittanbietern. Das klingt nach Eitelkeit, ist es aber nicht. Es bedeutet eine kleine Binärdatei, eine winzige Angriffsfläche und keine schleichenden Veränderungen durch transitive Abhängigkeiten. Eine App, deren einzige Aufgabe es ist, mit zwei APIs zu sprechen, braucht kein Framework.
Eine Schicht spricht mit Civo
Ein einziger CivoClient-Actor kapselt die HTTP-API von Civo. Das Token kommt aus dem macOS-Schlüsselbund, wird nie auf die Festplatte geschrieben und nie geloggt. Jeder Request nutzt Structured Concurrency: async let für die parallelen Aufrufe (Instanzen, Cluster und Buckets beim Laden eines einzigen Bildschirms), keine Callbacks und keine Combine-Kette, die man debuggen müsste.
Eine Schicht spricht mit Kubernetes
Die Kubernetes-Anbindung läuft direkt gegen die K8s-API, ohne Aufruf von kubectl in einer Shell und ohne Hilfsprogramm. CivoCloudManager lädt die kubeconfig von Civo, liest sie ein und spricht danach mit der Kubernetes-API wie jeder andere Client. Pod-Logs kommen per Websocket; Metriken liefert der metrics-server, sofern vorhanden, und wenn nicht, bleibt die Anzeige sauber leer. Acht Sprachen, alles als SwiftUI-Strings im Paket.
Ein Menüleisten-Modus, der seinen Platz verdient
Ein Klick auf das Symbol in der Menüleiste öffnet ein 480 px breites Fenster mit dem zuletzt genutzten Cluster, laufenden Pod-Metriken und einem Log-Ausschnitt, den Sie anheften können. Kein Tab, kein Aktualisieren. Genau deshalb gibt es die App.
Grundsätze für die öffentliche Entwicklung
An drei Selbstverpflichtungen halte ich mich:
Öffentliche Roadmap. Die nächsten Funktionen stehen mit groben Terminen in den GitHub Issues. Verschiebt sich etwas, wird das Issue aktualisiert und nicht stillschweigend vertagt. Ist etwas früher fertig als geplant, verweist der Commit auf das Issue.
Nachvollziehbare Entscheidungen. Änderungen an der Architektur, etwa der Einbau von Observability, die Art der Speicherung von Zugangsdaten oder was bewusst weggelassen wird, bekommen eine kurze Notiz im Ordner decisions/ des Repositorys. Das ist kein Prozesstheater. Wer das Projekt in einem Jahr forkt, soll sehen können, warum der Code so aussieht, wie er aussieht.
Die Community bestimmt die Reihenfolge. Eine echte Frage im Civo-Community-Slack hat Vorrang vor allem, was auf meiner spekulativen Roadmap steht. Für das Release 2.0 habe ich alles umsortiert, weil drei verschiedene Nutzer in derselben Woche dasselbe DNS-Problem gemeldet hatten.
Was ich bei der Veröffentlichung gelernt habe
Native macOS-Apps sind zurück. Die Leute wollen sie. Die Zeit, in der alles Electron war, geht zu Ende. Eine Swift-App mit 12 MB, die in 80 ms startet, überrascht inmitten von Electron-Werkzeugen mit 400 MB im besten Sinne.
Civos API belohnt einen schlanken Client. Middleware ist nicht nötig. Die Rate-Limits sind großzügig, die Antworten sauber strukturiert, und das Bearer-Token-Modell ist unkompliziert. Wer etwas auf Civo aufbauen will, kann das, und die API steht dabei nicht im Weg.
Kostenlos und gut ist eine Marketingstrategie. Ich habe keine einzige Anzeige geschaltet. Die App bekommt Bewertungen von selbst, weil Civo-Nutzer anderen Civo-Nutzern davon erzählen. Für ein Werkzeug wie dieses ist das die einzige Form von Marketing, die mitwächst.
Was als Nächstes auf der öffentlichen Roadmap steht
- Ein Browser für Object Storage am Bucket-Endpoint (Auflistung über Regionen hinweg, Upload per Drag-and-drop)
- Ein Editor, mit dem sich viele Firewall-Regeln auf einmal bearbeiten lassen (die meistgewünschte Funktion für 2.x)
- Ein Kosten-Dashboard, das die Daten aus der Billing-API bezieht
- Eine Linux-Version über SwiftCrossUI, ein Wunsch der Community aus dem Slack
Wenn Sie Civo nutzen und etwas Bestimmtes brauchen, eröffnen Sie ein Issue. Die Roadmap entwickelt sich in die Richtung, in die die Community drängt.
Sie wollen ein vergleichbares Werkzeug für Ihr Unternehmen
Nicht jedes Team braucht eine öffentliche App. Viele Teams brauchen aber ein natives internes Werkzeug, das mit ihrem Cloud-Anbieter, ihrer Datenbank oder ihrer internen API spricht und ihnen das ständige Hantieren mit Browser-Tabs erspart. Dafür passt dieselbe Architektur: eine schlanke Swift-App, Structured Concurrency, direkter API-Zugriff und keine Abhängigkeiten. Hier starten, wenn Sie so ein Werkzeug für Ihre Systeme wollen.
Im App Store ansehen: CivoCloudManager ist kostenlos im Mac App Store erhältlich. Fügen Sie Ihr Civo-Token ein, und die Menüleiste wird zu der Cluster-Ansicht, die Sie sich vom Dashboard immer gewünscht haben.