Aseptic vs DevSpace
DevSpace antwortet auf die langsame innere Schleife, indem es dich in den Cluster holt: dein Code läuft in einem Entwicklungscontainer, die Dateien werden hineinsynchronisiert und du hast dort ein Terminal. Aseptic antwortet, indem es gar nicht erst in den Cluster geht.
In einem Satz
DevSpace ist ein CLI, das deine Anwendung in Kubernetes deployt und
dann eine oder mehrere ihrer Workloads durch einen Entwicklungscontainer ersetzt, in den
deine Quellen synchronisiert werden, sodass der Prozess im Cluster neu startet, statt neu
gebaut und neu deployt zu werden. Konfiguriert wird das mit einer
devspace.yaml.
Aseptic führt die Services eines Szenarios auf deiner eigenen Maschine aus, verdrahtet jede Abhängigkeit zu einem lokalen Service, einer gemeinsamen Cloud-Umgebung oder einem Mock und schreibt die URLs beim Start um. Dein Code läuft dort, wo dein Editor und dein Debugger ohnehin schon sind.
Die Tabelle
| DevSpace | Aseptic | |
|---|---|---|
| Braucht einen Kubernetes-Cluster | Ja, lokal oder entfernt | Nein |
| Wo dein Code läuft | In einem Container des Clusters | Auf deiner Maschine |
| Wie die Änderungen ankommen | Dateisynchronisation in den Container | Sie sind schon da; das Framework lädt neu |
| Konfiguration | devspace.yaml im Repo | Szenarien außerhalb der Repos |
| Abhängigkeiten zum Rest des Systems | Was im Namespace deployt ist | Pro Abhängigkeit: lokal, Cloud oder Mock |
| Funktioniert offline | Nur mit einem lokalen Cluster | Ja, außer eine Abhängigkeit zeigt in die Cloud |
| Oberfläche | CLI | Desktop-App und ein CLI mit voller Parität |
| Lizenz | Open Source | Kostenlos für private Nutzung, kostenpflichtig für kommerzielle |
Bleib bei DevSpace, wenn…
- Deine Services von Dingen abhängen, die es nur im Cluster gibt —Service Accounts, gemountete Secrets, ein Service Mesh, ein Operator— und es sich nicht lohnt, sie außerhalb nachzubauen.
- Deine Maschine das System nicht trägt, ein gemeinsamer Cluster aber schon, und jeder Entwicklerin einen Namespace zu geben die Lösung ist, die ihr schon habt.
- Du willst, dass die Laufzeitumgebung der Entwicklung buchstäblich die Laufzeitumgebung der Produktion ist.
- Deinem Team nichts daran unangenehm ist, einen Prozess auf der anderen Seite eines Port-Forwards zu debuggen.
Bleib bei Aseptic, wenn…
- Was du debuggst, Geschäftslogik ist, die auf zwei oder drei Services verteilt liegt, und alles, was der Cluster hinzufügt, im Weg steht.
- Du aufhören willst, davon abzuhängen, dass ein gemeinsamer Cluster läuft oder ein VPN steht, um an einer Funktion zu arbeiten.
- Du willst, dass dir die Infrastruktur des Systems —Kafka, Redis, PostgreSQL— in Docker gestartet wird, ohne dass du die Manifeste schreibst.
- Du eine eigene Bibliothek gegen ihre Verbraucher testen willst, ohne sie vorher zu veröffentlichen.
Wo Aseptic zu kurz greift
Alles, was es nur in Kubernetes gibt, liegt außer Reichweite: eine Konfiguration, die ein Operator injiziert, ein im Cluster ausgestelltes Zertifikat, das Verhalten eines Sidecars. Wenn deine Services ohne das wirklich nicht starten können, ist der Ansatz von DevSpace keine Zeremonie: er ist der einzige, der funktioniert.
Aseptic ist außerdem in öffentlicher Beta, erscheint für Windows, macOS und Linux und ist nicht quelloffen.
Was am Ende meistens passiert
Die entscheidende Frage ist nicht, welches Werkzeug besser ist, sondern wo deine Services starten können. Wenn sie mit einer Handvoll Umgebungsvariablen und einer Datenbank hochkommen, ist es schneller und einfacher, sie lokal auszuführen. Wenn sie nur in einem Namespace hochkommen, den jemand vorbereitet hat, ist der Cluster nicht optional und DevSpace macht ihn erträglich.
Sieh dir auch Tilt, Skaffold und den breiten Vergleich an.
Häufige Fragen
Lösen DevSpace und Aseptic dasselbe?
Dasselbe Symptom, nicht dasselbe Problem. DevSpace holt deine innere Schleife in einen Entwicklungscontainer innerhalb von Kubernetes; Aseptic lässt sie auf deiner Maschine und nimmt den Cluster aus der Gleichung.
Kann ich in beiden gleich gut debuggen?
In Aseptic ist der Service ein ganz normaler lokaler Prozess, der Debugger hängt sich also an wie immer. In DevSpace geht es, aber es führt über Port-Forwarding und die Konfiguration des Entwicklungscontainers.
Und wenn mein Team DevSpace schon aufgesetzt hat?
Dann sind die Wechselkosten real und gehören abgewogen. Der Vergleich zählt vor allem dann, wenn das, was täglich bezahlt wird, der Zyklus aus Synchronisieren und Neu-Deployen ist, um eine Änderung zu sehen.