Aseptic vs Telepresence
Telepresence e Aseptic concordano sulla diagnosi —non dovresti dover avviare dodici servizi per lavorare su uno— e discordano su dove debbano vivere gli altri undici. Telepresence li prende in prestito da un cluster. Aseptic ti lascia deciderlo uno a uno.
In una frase
Telepresence collega la tua macchina a un cluster Kubernetes e intercetta il traffico di un servizio scelto, instradandolo verso la copia che hai in esecuzione in locale. Il resto del sistema resta nel cluster, reale, e il tuo processo ci parla come se fosse distribuito lì.
Aseptic avvia i servizi di uno scenario sulla tua macchina e risolve ogni dipendenza verso un servizio locale, un ambiente condiviso nel cloud o un mock, riscrivendo gli URL fra loro all'avvio. Non c'è cluster di mezzo.
La tabella
| Telepresence | Aseptic | |
|---|---|---|
| Serve un cluster Kubernetes | Sì, e distribuito e sano | No |
| Dove gira il resto del sistema | Nel cluster, reale | Dove scegli tu, per dipendenza |
| Quanti servizi avvii in locale | Di solito uno, quello intercettato | Quelli che dice lo scenario |
| Realismo delle dipendenze | Altissimo — sono quelle vere | Quello che gli dai tu; valgono anche i mock |
| Funziona offline | No | Sì, salvo che una dipendenza punti al cloud |
| Rischio per gli ambienti condivisi | Reale — sei dentro uno | Nessuno di default; solo se punti lì una dipendenza |
| Infrastruttura comune per il flusso | Quella del cluster | Kafka, Redis e PostgreSQL avviati in Docker per te |
| Licenza | Nucleo aperto, livelli commerciali | Gratis per uso personale, a pagamento per uso commerciale |
Resta con Telepresence se…
- Il difetto compare solo contro il reale: i volumi di dati veri, il provider di identità vero, il gateway vero davanti.
- Il tuo sistema è troppo grande per una sola macchina e continuerà a esserlo.
- Mantenete già un cluster di sviluppo condiviso che rispecchia la realtà abbastanza bene da valere la pena prenderlo in prestito.
- Stai cambiando un servizio e il resto non è in gioco.
Resta con Aseptic se…
- Vuoi cambiare più servizi insieme e vedere il flusso da capo a fondo, che è ciò che intercettarne uno solo non ti dà.
- Vuoi lavorare su un aereo, su un treno o il giorno in cui il cluster condiviso è giù.
- Preferiresti non avere il tuo codice a metà dentro un ambiente che stanno usando i tuoi colleghi.
- Vuoi poter scegliere: questa dipendenza in locale, quella contro il cloud, questa terza mockata — e cambiarlo con un clic.
Dove Aseptic resta corto
Il realismo. Le dipendenze di Telepresence sono i servizi distribuiti sul serio, con la loro configurazione vera; quelle di Aseptic sono ciò a cui le hai puntate. Se il difetto che insegui vive in quella differenza —qualcosa del networking del cluster, un header che aggiunge il gateway, un payload che nessuno ha documentato—, la copia locale non lo riprodurrà, e cercarlo lì ti costa un pomeriggio.
Aseptic è inoltre in beta pubblica, esce per Windows, macOS e Linux e non è open source.
Quello che di solito finisce per succedere
Questi due convivono meglio della maggior parte: Aseptic per costruire la funzionalità e Telepresence per l'ultimo miglio contro l'ambiente reale, quando qualcosa non torna. E conviene dirlo chiaro, dato che anche Aseptic può puntare una dipendenza al vostro ambiente condiviso: quello è un URL, non un'intercettazione. È più semplice ed è anche meno fedele.
Se quello che stai confrontando è il cluster, guarda Tilt, DevSpace e il confronto ampio.
Domande frequenti
Che cosa fa esattamente Telepresence?
Collega un processo che gira sulla tua macchina a un cluster reale, in modo che il tuo servizio locale prenda il posto di quello distribuito e parli con il resto del cluster.
Allora perché non mi basta Telepresence?
Perché ha bisogno del cluster. Se è giù, se non hai la VPN o se vuoi avviare tre servizi insieme senza toccare l'ambiente condiviso, quel modello non aiuta. Aseptic esegue l'intero flusso sulla tua macchina e punta ogni dipendenza dove scegli tu.
Posso mescolare servizi locali e remoti con Aseptic?
Sì, ed è la sua ragione d'essere: per ogni dipendenza decidi se va al servizio locale, al tuo ambiente nel cloud o a un mock.