Aseptic vs DevSpace
DevSpace répond à la lenteur de la boucle interne en vous mettant dans le cluster : votre code tourne dans un conteneur de développement, les fichiers y sont synchronisés et vous y avez un terminal. Aseptic répond en n'allant pas au cluster du tout.
En une phrase
DevSpace est un CLI qui déploie votre application sur Kubernetes puis
remplace un ou plusieurs de ses workloads par un conteneur de développement avec vos
sources synchronisées dedans, de sorte que le processus redémarre dans le cluster au
lieu d'être reconstruit et redéployé. Il se configure avec un
devspace.yaml.
Aseptic exécute les services d'un scénario sur votre propre machine, câble chaque dépendance vers un service local, un environnement cloud partagé ou un mock, et réécrit les URL au démarrage. Votre code tourne là où se trouvent déjà votre éditeur et votre débogueur.
Le tableau
| DevSpace | Aseptic | |
|---|---|---|
| Nécessite un cluster Kubernetes | Oui, local ou distant | Non |
| Où tourne votre code | Dans un conteneur du cluster | Sur votre machine |
| Comment arrivent les changements | Synchronisation de fichiers vers le conteneur | Ils y sont déjà ; le framework recharge |
| Configuration | devspace.yaml dans le dépôt | Scénarios hors des dépôts |
| Dépendances avec le reste du système | Ce qui est déployé dans le namespace | Par dépendance : local, cloud ou mock |
| Fonctionne hors connexion | Seulement avec un cluster local | Oui, sauf si une dépendance vise le cloud |
| Interface | CLI | Application de bureau et CLI à parité complète |
| Licence | Open source | Gratuit pour un usage personnel, payant en usage commercial |
Choisissez DevSpace si…
- Vos services dépendent de choses qui n'existent que dans le cluster —service accounts, secrets montés, un service mesh, un opérateur— et les reproduire dehors n'en vaut pas la peine.
- Votre machine ne tient pas le système mais un cluster partagé si, et donner un namespace à chaque développeur est l'arrangement que vous avez déjà.
- Vous voulez que l'environnement d'exécution du développement soit, littéralement, celui de la production.
- Déboguer un processus qui vit de l'autre côté d'un port-forward ne gêne pas votre équipe.
Choisissez Aseptic si…
- Ce que vous déboguez est de la logique métier répartie sur deux ou trois services, et tout ce que le cluster ajoute vous encombre.
- Vous voulez cesser de dépendre d'un cluster partagé allumé, ou d'un VPN, pour travailler sur une fonctionnalité.
- Vous voulez que l'infrastructure du système —Kafka, Redis, PostgreSQL— soit démarrée pour vous dans Docker, sans écrire les manifestes.
- Vous voulez tester une bibliothèque à vous face à ceux qui la consomment sans la publier d'abord.
Là où Aseptic est insuffisant
Tout ce qui n'existe que dans Kubernetes reste hors de portée : une configuration injectée par un opérateur, un certificat émis dans le cluster, le comportement d'un sidecar. Si vos services ne peuvent vraiment pas démarrer sans cela, l'approche de DevSpace n'est pas de la cérémonie : c'est la seule qui marche.
Aseptic est par ailleurs en bêta publique, publié pour Windows, macOS et Linux, et il n'est pas open source.
Ce qui finit généralement par arriver
La question qui tranche n'est pas quel outil est meilleur, c'est où vos services peuvent démarrer. S'ils se lèvent avec une poignée de variables d'environnement et une base de données, les exécuter en local est plus rapide et plus simple. S'ils ne se lèvent que dans un namespace préparé par quelqu'un, le cluster n'est pas optionnel et DevSpace le rend supportable.
Voir aussi Tilt, Skaffold et le comparatif général.
Questions fréquentes
DevSpace et Aseptic résolvent-ils la même chose ?
Le même symptôme, pas le même problème. DevSpace déplace votre boucle interne dans un conteneur de développement à l'intérieur de Kubernetes ; Aseptic la laisse sur votre machine et sort le cluster de l'équation.
Puis-je déboguer aussi bien dans les deux ?
Dans Aseptic le service est un processus local ordinaire, donc le débogueur s'attache comme d'habitude. Dans DevSpace c'est possible, mais cela passe par une redirection de ports et par la configuration du conteneur de développement.
Et si mon équipe a déjà DevSpace en place ?
Alors le coût du changement est réel et il faut le peser. La comparaison compte surtout quand ce que l'on paie chaque jour est le cycle de synchroniser et redéployer pour voir un changement.