Deploying Spring Petclinic Microservices Locally with Docker Compose

Introduction

As part of the DevOps Mentorship Initiative (DMI), I deployed the Spring Petclinic Microservices application locally using Docker Compose and explored how a modern microservices architecture operates in practice.

Spring Petclinic is a cloud-native sample application built with Spring Boot and Spring Cloud. Instead of running as a single application, it consists of multiple independent services that communicate with one another.

The deployment included:

Config Server
Discovery Server (Eureka)
API Gateway
Customers Service
Vets Service
Visits Service
GenAI Service
Admin Server

In addition, the observability stack included:

Prometheus
Grafana
Zipkin

This project provided hands-on experience with service discovery, centralized configuration, container orchestration, and observability.

Prerequisites

Before starting, I installed the following tools:
Docker engine for WSL.
Docker engine in WSL was used to run and manage all application containers.

Verify installation:
docker --version
docker compose version
Git

Git was used to clone the project repository.

Verify installation:
git --version

Step 1: Clone the Repository
Clone the Spring Petclinic Microservices repository:

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

Move into the project directory:
cd spring-petclinic-microservices

Step 2: Start the Entire Application
The most interesting part of the project was that the entire platform could be started with a single command:

docker compose up -d

Docker Compose automatically:
Pulled required images
Created containers
Connected services through a shared network
Applied startup dependencies
Started the monitoring stack

To confirm everything was running:
docker ps

Expected containers:
config-server
discovery-server
api-gateway
customers-service
vets-service
visits-service
genai-service
admin-server
prometheus-server
grafana-server
tracing-server

Step 3: Verify the Deployment
API Gateway

Check the gateway health endpoint:

curl http://localhost:8080/actuator/health
Expected response:
{"status":"UP"}

Eureka Dashboard
Open:
http://localhost:8761

All services should appear as registered instances.

Spring Boot Admin
Open:
http://localhost:9090

This dashboard provides visibility into application health and metrics.
Understanding the Startup Order

One important concept in this deployment is service startup dependency.
The Docker Compose file ensures that the Config Server and Discovery Server start before the other services.

Why Config Server Starts First
The Config Server stores centralized configuration for all services.
When services such as Customers Service or API Gateway start, they immediately request configuration from the Config Server.

Without it:
Services cannot retrieve configuration
Startup may fail
Environment settings become unavailable
Why Discovery Server Starts Second

The Discovery Server (Eureka) acts as a service registry.

Every microservice registers itself with Eureka when it starts.

Without Eureka:
Services cannot discover each other
API Gateway routing fails
Inter-service communication breaks

In short:

Config Server
↓
Discovery Server
↓
All Other Services

This startup sequence is critical for a healthy deployment.

Observability and Monitoring
One of the most valuable parts of this project was learning how observability tools provide visibility into distributed systems.

Prometheus
Prometheus continuously collects metrics from the Spring Boot Actuator endpoints.

Metrics include:
CPU usage
Memory usage
HTTP request counts
Application performance statistics

Access:
http://localhost:9091

Prometheus acts as the data collection layer for monitoring.

Grafana
Grafana visualizes metrics collected by Prometheus.

Access:
http://localhost:3000

Using Grafana dashboards, I could monitor:
Service health
JVM memory consumption
Request throughput
System performance trends

Instead of reading raw metrics, Grafana transforms them into easy-to-understand charts and dashboards.

Zipkin
Zipkin provides distributed tracing.

Access:
http://localhost:9411

Distributed tracing allows engineers to follow a request as it travels across multiple services.

For example:

Client
↓
API Gateway
↓
Customers Service
↓
Database

Zipkin records timing information for every step, helping identify bottlenecks and performance issues.

Although tracing required additional verification during testing, understanding how distributed tracing works was one of the most educational parts of the project.

Docker Compose Up vs Down
Start Everything
docker compose up -d

This command:
Creates containers
Creates networks
Starts services
Runs containers in the background
Stop Everything
docker compose down

This command:
Stops containers
Removes containers
Removes networks created by Compose

Using these two commands makes managing the entire environment simple and repeatable.

What I Learned
The biggest lesson from this deployment was that running microservices is much more than simply starting containers.

A successful deployment depends on:
Correct startup sequencing
Service discovery
Centralized configuration
Monitoring
Distributed tracing
Health checks

I also learned how observability tools such as Prometheus, Grafana, and Zipkin help engineers understand what is happening inside a distributed system.

These tools become increasingly important as systems grow larger and more complex.

Looking Ahead to Production

If deploying this architecture to AWS, I would replace local Docker Compose components with managed cloud services:

Local Deployment | AWS Production
Docker Compose | Amazon EKS
Local containers | Kubernetes Pods
Local networking | Kubernetes Services
Local monitoring | Amazon Managed Prometheus + Grafana
Local storage | Amazon EBS/EFS
Local secrets | AWS Secrets Manager
Local images | Amazon ECR
Manual deployment | CI/CD with GitHub Actions and ArgoCD

This would provide better scalability, availability, security, and operational reliability.

Conclusion
Deploying Spring Petclinic Microservices gave me practical experience with modern cloud-native architecture and DevOps practices.

From centralized configuration and service discovery to monitoring and tracing, this project demonstrated many of the concepts used in real-world production environments.

This project was completed as part of the DevOps Mentorship Initiative (DMI).

Interested in joining the next cohort?

DMI Cohort 3 Registration:
https://docs.google.com/forms/d/e/1FAIpQLSel7ai7nyb0P1qLW4vEyfB_nEsD4lUF1XG88vmAaFGBOb6hPA/viewform

Author: Olanrewaju Awe
GitHub: https://github.com/Ralphlarry
LinkedIn: www.linkedin.com/in/olanrewaju-awe-62761758