Spring Boot: developing several services locally
One Spring Boot service on your machine is a solved problem: run the main class and you are working. Five of them, talking to each other, with a Kafka and a Postgres underneath, is where the morning goes.
What actually costs time
- The order. The one that registers has to be up before the one
that looks it up, and «up» means answering
/actuator/health, not having a PID. - The ports. Two services default to 8080. The third one you start finds one of them taken and you go looking for which.
- The URLs. Every service has a property pointing at another —
app.catalog.urland its fifteen siblings— and pointing three of them somewhere else means editing files you will later have to remember not to commit. - The infrastructure. Kafka, Redis and PostgreSQL, brought up consistently, with the topics and the schema the services expect.
- Your own libraries. A shared library you also need to change
means
mvn install, a version bump and hoping nothing else picked up the snapshot.
What Aseptic does about it
Aseptic autodetects a Spring Boot service from its manifest —Maven or Gradle— and
knows how to start it, where its health endpoint is, and how to pass configuration
to it. Configuration is injected at startup as -D
system properties or environment variables, so the URLs between services are
rewritten without touching application.yml or anything else in your
repository. Nothing to commit, nothing to remember to revert.
A scenario groups the services of a flow and starts them in dependency order, waiting on health rather than on the process. Ports that collide are remapped automatically and the new value is what the other services are told. Kafka, Redis and PostgreSQL come up in Docker, managed by the app.
For each dependency you choose where it resolves: another service you have open locally, your shared cloud environment —with the VPN, if that is how you reach it— or a mock. That choice is per dependency, not per environment, so «these two local, the rest against the cloud» is a normal Tuesday and not a configuration exercise.
Libraries without publishing them
If the change spans a service and a library of your own, Aseptic builds the library
and links it into the consumers where Maven and Gradle look for it —your local
~/.m2 repository— and can rebuild and relink on change. It does not
edit the consumer's pom.xml or build.gradle, and
unlinking undoes only what it did.
What it does not do
It does not replace your build. Maven and Gradle stay exactly where they are, and Aseptic calls them. It does not run a Kubernetes cluster, so if what you need to check is a probe, an ingress or a sidecar, this is the wrong tool — a local cluster is the right one. And it needs Docker for the shared infrastructure, so Docker Desktop or a Docker engine has to be installed.
It is in public beta, ships for Windows, macOS and Linux, and it is free for personal use.
Where this sits next to the usual suspects
If your services already have images and manifests you maintain, Tilt or Skaffold keep the local loop shaped like production, at the cost of a build and a deploy on every change. The alternatives to Docker Compose page lays out the whole field, and the wider comparison covers Compose and local Kubernetes directly.
There are equivalents of this page for Quarkus and for Node.
Frequently asked questions
How do I run several Spring Boot microservices locally?
You need to solve four things: the shared infrastructure, each service's startup with its profile and variables, where each one points, and the data. The one that usually breaks is the third, which is what ends in hand-edited URLs.
Do I have to touch application.yml to point at another environment?
Not with Aseptic: configuration is injected at startup as -D properties, so the file in the repository stays as it is.
Can I link a library of my own without publishing it?
Yes. Aseptic builds it and links it where Maven or Gradle resolve it —the local ~/.m2 repository— without touching the dependency file of whoever consumes it.