I Deployed 8 Microservices With One Command — Here Is Everything That Happened

Introduction

Eight Spring Boot microservices. A service registry. A config server. An API gateway. Prometheus. Grafana. Zipkin. All of it, running on my local machine, started with a single command.

This post documents exactly what I did, what I saw, and what I learned deploying Spring PetClinic microservices using Docker Compose as part of the DMI Cohort 2 programme.

What Is Spring PetClinic?

Spring PetClinic is a sample application maintained by the Spring team. The microservices version splits it into 8 independent services, each doing one job:

•      Config Server (port 8888) — centralised configuration store. Every other service reads its settings from here. Must start first.

•      Discovery Server / Eureka (port 8761) — service registry. Every service registers here so others can find them. Must start second.

•      API Gateway (port 8080) — single entry point for all external traffic. Routes requests to the correct downstream service.

•      Customers Service (port 8081) — manages pet owner records

•      Visits Service (port 8082) — manages veterinary appointment records

•      Vets Service (port 8083) — manages veterinarian records

•      GenAI Service (port 8084) — AI chatbot powered by Azure OpenAI

•      Admin Server (port 9090) — Spring Boot Admin dashboard for all services

Plus the observability stack: Prometheus (9091), Grafana (3030), and Zipkin (9411).

Prerequisites

Everything you need before you start:

•      Docker Desktop installed and running (I used Docker 29.4.2)

•      Git installed

•      At least 8GB RAM allocated to Docker

•      The repository cloned locally

Step 1 — Clone the Repository

git clone https://github.com/spring-petclinic/spring-petclinic-microservices.git

cd spring-petclinic-microservices

ls

You will see the docker-compose.yml file alongside the individual service directories. Each service directory contains the Spring Boot source code and its Dockerfile.

Step 2 — Start Everything

docker compose up -d

That is the entire command. Docker Compose pulls the images, creates the network, and starts all containers in the correct order based on the depends_on and healthcheck configuration in docker-compose.yml.

Important: this takes 3-5 minutes on first run as Docker pulls images. On subsequent runs it is much faster.

Step 3 — Verify All Services Running

docker compose ps

You should see all 11+ containers with status Up or Up (healthy). Config Server and Discovery Server appear healthy first — this is by design.

Step 4 — The Startup Order: Why It Matters

This was the biggest learning from the deployment. The startup order is not optional — it is enforced by the depends_on configuration in docker-compose.yml.

Config Server starts first. It holds all configuration for every other service: database connection strings, port numbers, feature flags. If any service tries to start before Config Server is healthy, it cannot read its own configuration and crashes.

Discovery Server starts second, after Config Server reports healthy. It needs its own configuration from Config Server before it can start the Eureka registry.

All other services — API Gateway, Customers, Vets, Visits, GenAI, Admin — wait for both Config Server and Discovery Server to be healthy before they start. They register themselves with Eureka on startup so the API Gateway knows where to route traffic.

Get this order wrong and you get a cascade of crash-loops. The services are healthy — the startup order is wrong. The depends_on with condition: service_healthy in docker-compose.yml is what enforces the correct sequence automatically.

Step 5 — Verify the Application

Open your browser and check each URL:

•      http://localhost:8080 — Spring PetClinic homepage. You should see the Welcome to Petclinic page with the cat and dog image.

•      http://localhost:8761 — Eureka dashboard. All 8 services should be registered here within 90 seconds of startup.

•      http://localhost:9090 — Spring Boot Admin. Shows health status, metrics, and log levels for every registered service.

•      http://localhost:9411 — Zipkin. Distributed trace viewer.

•      http://localhost:9091 — Prometheus. Metrics collection and query interface.

•      http://localhost:3030 — Grafana. Dashboards showing live metrics.

Step 6 — Functional Test

Navigate to http://localhost:8080 and click Find Owners. You should see the default owner list loaded from the in-memory database.

Click any owner to see their pet and visit history. Click Add Visit on a pet, enter a date and description, and submit. The visit appears immediately — confirming the Visits Service, Customers Service, and database are all working correctly through the API Gateway.

Navigate to Veterinarians. The vet table with specialties loads, confirming the Vets Service is healthy.

Step 7 — The Observability Stack

This was the most impressive part of the deployment. Within 60 seconds of all services starting, Prometheus was already scraping metrics from all 8 services via the /actuator/prometheus endpoint that Spring Boot Actuator exposes automatically.

In Grafana, dashboards showed HTTP request rates, error rates per service, JVM heap usage, and database connection pool status — all live, all without any additional configuration beyond what ships in the repository.

In Zipkin, I could trace a single browser request as it entered the API Gateway, was routed to the Customers Service, hit the database, and returned — each hop recorded as a span with timing. A request that felt instant to the user was actually 4 service calls in 87 milliseconds.

Step 8 — Stop and Clean Up

docker compose down

This stops all containers and removes them and their network. The volumes persist unless you add -v. All data is gone — the next docker compose up starts fresh.

Key Takeaway

Microservices look simple from the outside — one command starts everything. But the operational discipline underneath is significant: you need centralised configuration, service discovery, distributed tracing, and health-check-enforced startup ordering. Docker Compose encodes all of that correctly. This is why learning from a production-architecture project like Spring PetClinic teaches you things that a tutorial TODO app never will.

This Is Part of DMI

This deployment was completed as part of the DevOps Micro Internship (DMI) programme run by Pravin Mishra. DMI Cohort 3 starts 27 June 2026. If you want to build real skills with real tools — not just watch tutorials — apply here:

https://docs.google.com/forms/d/e/1FAIpQLSel7ai7nyb0P1qLW4vEyfB_nEsD4lUF1XG88vmAaFGBOb6hPA/viewform

#DMI #DevOps #Docker #Microservices #SpringBoot #Observability #TheCloudAdvisory