Avviare solo parte dei microservizi
Il tuo sistema ha dodici servizi e tu ne toccherai due. La macchina regge dodici —a stento— ma avviarli tutti richiede quattro minuti, si mangia la memoria e non aggiunge nulla alla modifica che stai facendo. La domanda non è se si possa tagliare: è dove chiamano quelli che avvii.
Il taglio non è il problema; la destinazione sì
Avviare un sottoinsieme è banale in qualsiasi strumento: ne scegli due e parti. Quello che nessuno risolve per te è cosa succede quando uno di quei due ne chiama un terzo che non c'è più.
Ogni dipendenza che esce dal taglio ha esattamente tre destinazioni possibili:
- Locale — è su proprio lì accanto. Il caso facile, e anche quello che si tira dietro: se lo avvii, ti tiri dietro la sua coda di dipendenze.
- Il cloud — il vostro ambiente condiviso. Ti risparmia di avviarlo, in cambio della VPN, di dati che cambiano sotto i tuoi piedi, e del fatto che se quell'ambiente è giù, lo sei anche tu.
- Un mock — perfetto quando la sua risposta non è ciò che stai testando. In cambio di mantenere lo stub.
La decisione è per dipendenza, non per ambiente. Lì sta la differenza con quasi tutto il resto: non vuoi una «modalità locale» o una «modalità cloud», vuoi che questa chiamata vada al servizio che hai aperto, quella al cloud e una terza a un mock, e cambiare idea a metà pomeriggio.
Perché un compose non fa la differenza
docker compose up bff orders avvia effettivamente due servizi. Ma dentro un
compose tutto è un container della stessa rete, e gli URL fra loro sono
nomi di servizio di quella rete. La configurazione di bff dice
http://payments:8081, e payments ora non esiste: ottieni un
errore di risoluzione del nome.
L'uscita abituale è modificare l'URL a mano nella configurazione di bff —un
repository che spesso non è tuo—, ricordarsi di non committarlo, e disfarlo quando vuoi
provare altro. Moltiplicato per servizi e per volte al giorno, è da lì che esce il
LOCAL_SETUP.md di quaranta passi.
Cosa si rompe quando si taglia male
Due guasti, e il secondo è molto peggio del primo:
-
Fallisce rumorosamente.
connection refused, o un nome che non si risolve. Fastidioso, ma onesto: te ne accorgi al primo tentativo. - Funziona senza che nessuno l'abbia deciso. La configurazione portava come predefinito l'URL dell'ambiente condiviso, quindi la chiamata esce verso il cloud, risponde, e sembra tutto a posto. Te ne accorgi il giorno in cui quella chiamata scrive: una migrazione, un ordine di prova, un'email inviata a un cliente vero dalla tua macchina.
Il secondo è ciò che giustifica farne una decisione esplicita invece di un valore predefinito. Un ambiente locale che arriva in produzione per distrazione non avvisa.
E un caso che quasi tutti sbagliano
Se un servizio è effettivamente su lì accanto, la chiamata dovrebbe andare a lui —anche se il file di configurazione generale dice «cloud»—. Sembra ovvio e quasi nessuno strumento lo fa: finisci con un servizio avviato sulla tua macchina che il suo vicino chiama via internet. Consuma VPN, è più lento, e il giorno in cui la VPN cade hai un intero scenario locale che non parte per colpa di un servizio che avevi lì accanto.
La regola corretta: ciò che è avviato lì accanto si chiama in locale, e la configurazione generale decide solo su ciò che non è nello scenario.
Come lo risolve Aseptic
Uno scenario è esattamente questo: il sottoinsieme che vuoi avviare, con la decisione presa per ogni dipendenza che ne esce.
- Scegli cosa entra. Due su dodici, o quanti siano, raggruppati per flusso —«Checkout», «Registrazione cliente»— e salvati con un nome, per non doverlo decidere di nuovo domani.
- Per ogni dipendenza scegli una destinazione —locale, cloud o mock— e
il motore riscrive l'URL all'avvio, iniettato come property
-Do variabile d'ambiente. I tuoi repository non si toccano. - Ciò che è nello scenario si chiama in locale, al di sopra di quanto dica il manifest: la decisione recente e specifica batte quella generale.
- Se le dichiarazioni si contraddicono, l'avvio viene interrotto invece di risolvere il pareggio in silenzio. Due verità sulla stessa dipendenza è il bug che finisce con il pannello che dice «cloud» mentre un servizio chiama il vicino locale.
- Lo scenario si condivide come file autonomo: chi arriva importa e avvia, senza leggersi il documento di nessuno.
Quanto serve davvero avviare
La regola che funziona: solo i servizi che cambierai, più quelli di cui stai verificando il comportamento. Tutto il resto è un URL che punta altrove. In pratica, la maggior parte dei pomeriggi sono due o tre servizi su un sistema di dodici.
Se tagliando scopri che uno dei due non parte, c'è perché un microservizio non si alza in locale; e se quello che ti serve è sostituire quelli che lasci fuori, mockare un servizio che non controlli. Il quadro completo è in che cosa serve a un ambiente locale di microservizi.
Domande frequenti
Posso avviare solo due servizi su dodici e far funzionare il resto?
Sì, ma bisogna decidere dove chiamano quelli che avvii. Ogni dipendenza che punta a un servizio che non è su deve andare altrove: al tuo ambiente nel cloud o a un mock. Se non si decide, si decide da sola e fallisce.
Perché docker compose non me lo lascia fare senza modificare il file?
Perché dentro un compose tutto è un container della stessa rete e gli URL sono nomi di servizio. docker compose up bff orders ne avvia due, ma l'URL che bff usa per chiamarne un terzo continua a puntare a un nome che ora non esiste.
Cosa si rompe quando si taglia male?
Il caso tipico è un connection refused verso un nome di servizio che non c'è più, o peggio: una chiamata che esce per impostazione predefinita verso l'ambiente condiviso senza che nessuno l'abbia deciso. Il secondo è peggio perché funziona, e te ne accorgi solo quando scrivi nel database di tutti.
Quanto di un sistema serve davvero avviare?
Meno di quanto si avvii di solito. La regola utile: solo i servizi che cambierai o di cui stai verificando il comportamento. Tutto il resto è un URL che punta altrove.