Aseptic vs DevSpace
O DevSpace responde ao ciclo interno lento metendo-te no cluster: o teu código corre num contentor de desenvolvimento, os ficheiros sincronizam-se lá para dentro e tens um terminal ali. O Aseptic responde não indo ao cluster de todo.
Numa frase
O DevSpace é um CLI que faz deploy da tua aplicação no Kubernetes e depois
troca um ou vários dos seus workloads por um contentor de desenvolvimento com as tuas fontes
sincronizadas lá dentro, de modo que o processo reinicia dentro do cluster em vez de ser
reconstruído e reimplantado. Configura-se com um devspace.yaml.
O Aseptic corre os serviços de um cenário na tua própria máquina, liga cada dependência a um serviço local, a um ambiente partilhado na nuvem ou a um mock, e reescreve os URLs ao levantar. O teu código corre onde já estão o teu editor e o teu depurador.
A tabela
| DevSpace | Aseptic | |
|---|---|---|
| Precisa de um cluster de Kubernetes | Sim, local ou remoto | Não |
| Onde corre o teu código | Num contentor do cluster | Na tua máquina |
| Como chegam as mudanças | Sincronização de ficheiros para o contentor | Já lá estão; o framework recarrega |
| Configuração | devspace.yaml no repo | Cenários fora dos repos |
| Dependências com o resto do sistema | O que estiver implantado no namespace | Por dependência: local, nuvem ou mock |
| Funciona sem ligação | Só com um cluster local | Sim, salvo se uma dependência apontar à nuvem |
| Interface | CLI | App de ambiente de trabalho e um CLI com paridade completa |
| Licença | Código aberto | Grátis para uso pessoal, pago para uso comercial |
Fica-te pelo DevSpace se…
- Os teus serviços dependem de coisas que só existem dentro do cluster —service accounts, segredos montados, uma malha de serviços, um operador— e reproduzi-las fora não compensa.
- A tua máquina não aguenta o sistema mas um cluster partilhado aguenta, e dar um namespace a cada programador é o arranjo que já têm.
- Queres que o ambiente de execução do desenvolvimento seja, literalmente, o ambiente de execução de produção.
- À tua equipa não incomoda depurar um processo que vive do outro lado de um port-forward.
Fica-te pelo Aseptic se…
- O que estás a depurar é lógica de negócio repartida por dois ou três serviços, e tudo o que o cluster acrescenta estorva.
- Queres deixar de depender de que um cluster partilhado esteja de pé, ou de uma VPN, para trabalhar numa funcionalidade.
- Queres que a infraestrutura do sistema —Kafka, Redis, PostgreSQL— seja levantada em Docker por ti, sem escreveres os manifestos.
- Queres testar uma biblioteca tua contra quem a consome sem a publicares antes.
Onde o Aseptic fica curto
Tudo o que só existe no Kubernetes fica fora de alcance: uma configuração que um operador injeta, um certificado emitido dentro do cluster, o comportamento de um sidecar. Se os teus serviços de facto não conseguem arrancar sem isso, a abordagem do DevSpace não é cerimónia: é a única que funciona.
O Aseptic está além disso em beta pública, publica-se para Windows, macOS e Linux, e não é código aberto.
O que costuma acabar por acontecer
A pergunta que decide não é que ferramenta é melhor, é onde é que os teus serviços conseguem arrancar. Se levantam com um punhado de variáveis de ambiente e uma base de dados, executá-los em local é mais rápido e mais simples. Se só levantam dentro de um namespace que alguém preparou, o cluster não é opcional e o DevSpace torna-o suportável.
Vê também o Tilt, o Skaffold e o comparativo amplo.
Perguntas frequentes
O DevSpace e o Aseptic resolvem o mesmo?
O mesmo sintoma, não o mesmo problema. O DevSpace leva o teu ciclo interno para um contentor de desenvolvimento dentro do Kubernetes; o Aseptic deixa-o na tua máquina e tira o cluster da equação.
Posso depurar igualmente bem nos dois?
No Aseptic o serviço é um processo local normal, por isso o depurador liga-se como sempre. No DevSpace pode-se, mas passa por reencaminhamento de portas e pela configuração do contentor de desenvolvimento.
E se a minha equipa já tem o DevSpace montado?
Então o custo de mudar é real e convém pesá-lo. A comparação importa mais quando o que se paga diariamente é o ciclo de sincronizar e voltar a fazer deploy para ver uma mudança.