Spring Boot: sviluppare più servizi in locale

Aggiornato: 14 agosto 2026

Un servizio Spring Boot sulla tua macchina è un problema risolto: esegui la classe principale e stai lavorando. Cinque, che parlano fra loro, con un Kafka e un Postgres sotto, è dove se ne va la mattina.

Cosa costa davvero tempo

• L'ordine. Chi si registra deve essere su prima di chi lo cerca, e «su» significa che risponde a /actuator/health, non che ha un PID.
• Le porte. Due servizi portano 8080 di default. Il terzo che avvii ne trova una occupata e tocca a te scoprire quale.
• Gli URL. Ogni servizio ha una proprietà che punta a un altro —app.catalog.url e le sue quindici sorelle— e puntarne tre altrove significa modificare file di cui poi bisogna ricordarsi di non fare commit.
• L'infrastruttura. Kafka, Redis e PostgreSQL, avviati sempre allo stesso modo, con i topic e lo schema che i servizi si aspettano.
• Le tue librerie. Una libreria condivisa che per giunta devi modificare significa mvn install, alzare la versione e sperare che nessun altro si sia preso lo snapshot.

Cosa ci fa Aseptic

Aseptic rileva un servizio Spring Boot dal suo manifest —Maven o Gradle— e sa come avviarlo, dov'è il suo endpoint di salute e come passargli la configurazione. La configurazione viene iniettata all'avvio, come proprietà di sistema -D o variabili d'ambiente, quindi gli URL fra i servizi vengono riscritti senza toccare application.yml né nulla del tuo repository. Niente da committare, niente da ricordarsi di annullare.

Uno scenario raggruppa i servizi di un flusso e li avvia in ordine di dipendenza, aspettando la salute e non il processo. Le porte che collidono vengono rimappate da sole, e il valore nuovo è quello che viene comunicato agli altri servizi. Kafka, Redis e PostgreSQL partono in Docker, gestiti dall'app.

Per ogni dipendenza scegli dove si risolve: un altro servizio che hai aperto in locale, il vostro ambiente condiviso nel cloud —con la VPN, se è così che ci arrivate— o un mock. Quella scelta è per dipendenza, non per ambiente, quindi «questi due in locale e il resto contro il cloud» è un normale martedì e non un esercizio di configurazione.

Librerie senza pubblicarle

Se la modifica abbraccia un servizio e una tua libreria, Aseptic costruisce la libreria e la collega presso chi la usa dove Maven e Gradle la cercano —il tuo repository locale ~/.m2— e può ricostruirla e ricollegarla quando cambia. Non modifica il pom.xml né il build.gradle del consumatore, e scollegare disfa solo ciò che ha fatto.

Cosa non fa

Non sostituisce la tua build. Maven e Gradle restano esattamente dove sono, e Aseptic li chiama. Non esegue un cluster Kubernetes, quindi se quello che devi verificare è una probe, un ingress o un sidecar, questo è lo strumento sbagliato —un cluster locale è quello giusto—. E ha bisogno di Docker per l'infrastruttura comune, quindi serve avere Docker Desktop o un motore Docker installato.

È in beta pubblica, esce per Windows, macOS e Linux, ed è gratis per uso personale.

Dove si colloca rispetto ai soliti sospetti

Se i tuoi servizi hanno già immagini e manifest che mantieni, Tilt o Skaffold tengono il ciclo locale nella forma della produzione, in cambio di una build e un deploy a ogni modifica. La pagina delle alternative a Docker Compose apre l'intero campo, e il confronto ampio copre Compose e Kubernetes locale direttamente.

Ci sono equivalenti di questa pagina per Quarkus e per Node.

← Torna alla home