DEV Community: Rita Gitamo

Deploying Spring PetClinic Microservices Locally with Docker Compose

Rita Gitamo — Fri, 12 Jun 2026 18:32:49 +0000

There is something different about deploying an application yourself, from scratch, on your own machine. Our team had already deployed Spring PetClinic on AWS EKS as part of our DMI capstone project. But when I sat down to run the same application locally using Docker Compose, I learned things the cloud deployment never taught me.
What Is Spring PetClinic?
Spring PetClinic is a veterinary clinic management application built as 8 independent Spring Boot microservices. It covers everything from managing pet owners and their animals to scheduling vet visits and browsing veterinarian profiles. What makes it interesting as a learning project is not what it does, but how it is structured — 8 services that each own a piece of the system, all needing to work together seamlessly.

Prerequisites
Before running anything, make sure you have the following installed:

Docker
Git
A terminal — I used Ubuntu on WSL2

Getting Started
bash

git clone https://github.com/gitamoo/spring-petclinic-microservices.git
cd spring-petclinic-microservices
docker compose up -d

That single command spins up the entire stack:

Config Server and Eureka Discovery Server — the foundation
API Gateway, Customers, Visits, Vets, and GenAI services — the application layer
Spring Boot Admin, Prometheus, Grafana, and Zipkin — the full observability stack

The Startup Order
The first thing that stood out was watching the startup sequence play out. Config Server boots first and has to reach a healthy state before anything else moves. Discovery Server follows. Only once both are healthy do the remaining services start.
This is enforced in docker-compose.yml using depends_on with health checks. It is not just a convention — it is a hard requirement. Every service fetches its configuration from Config Server the moment it starts. Without it, they fail immediately. Then each service registers itself in Eureka so other services can find it by name. Without Discovery Server, the whole routing layer breaks.
Watching this happen in real time made the concept of distributed service dependencies feel very concrete.

The Zipkin Problem
Once everything was running I opened Zipkin at http://localhost:9411, ran a query, and got nothing. No traces, no errors — just an empty screen.
The container was healthy. The UI loaded fine. But nothing was showing up.
After investigating I found the root cause: the individual services had no configuration telling them where to send their trace data. Zipkin was running but completely isolated — none of the application services knew it existed.
The fix was adding two environment variables to each service in docker-compose.yml:
yamlenvironment:

- MANAGEMENT_ZIPKIN_TRACING_ENDPOINT=http://tracing-server:9411/api/v2/spans
  - MANAGEMENT_TRACING_SAMPLING_PROBABILITY=1.0

Once I brought the stack back down and up again with those variables in place, the traces started flowing immediately. I could see requests moving through api-gateway → customers-service in real time.
That experience taught me something I will carry into every deployment going forward: a container being healthy and a container being correctly wired up to the rest of the system are two completely different things. Health checks tell you the process is running. They do not tell you it is connected.

Verifying Everything Works
Once the stack was up I verified each service:

Service                    URL
Spring PetClinic App       http://localhost:8080
Eureka Dashboard           http://localhost:8761
Spring Boot Admin          http://localhost:9090
Zipkin                     http://localhost:9411
Prometheus                 http://localhost:9091
Grafana                    http://localhost:3030

Everything worked as expected. The only service that did not function fully was the GenAI chatbot, which requires a paid OpenAI API key. The service starts and registers with Eureka cleanly — it just cannot respond to AI requests without the key configured.
Cleaning Up
bash

docker compose down

This stops and removes all containers and the network, freeing up all ports and memory.
Final Thoughts
Running this application locally gave me a ground-level understanding of how microservices behave that the cloud deployment, with all its automation, had abstracted away. The startup order, the service wiring, the observability configuration — these are things you only truly understand when you have to get them right yourself.
This deployment was part of the DMI DevOps Micro-Internship. If you want hands-on experience like this, DMI Cohort 3 starts 27 June 👇

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

Deploying Spring PetClinic Microservices on AWS EKS: A Team Story

Rita Gitamo — Fri, 12 Jun 2026 18:18:16 +0000

When our group of 11 was handed the brief for our DMI DevOps Micro-Internship capstone project, the goal was clear: take a real-world microservices application and deploy it end-to-end on AWS using production-grade tooling. No shortcuts, no simulated environments. The kind of setup you'd actually find in a professional engineering team.
The application we worked with was Spring PetClinic — a veterinary clinic management system built as 8 independent Spring Boot microservices. On the surface it's a simple app. Under the hood it's a distributed system with service discovery, centralised configuration, an API gateway, a generative AI chatbot, and a full observability stack. It was the perfect candidate for what we were trying to learn.
What We Built
The final architecture brought together a wide range of tools across every layer of the stack:

Terraform to provision the AWS infrastructure — VPC, EKS cluster, RDS, ECR repositories, IAM roles, and the AWS Load Balancer Controller
Docker and ECR to containerise all 8 services and store the images in a private registry
Kubernetes to deploy and manage the application on EKS
GitHub Actions for the CI/CD pipeline — automatically building, tagging, and pushing images on every code push
ArgoCD for GitOps delivery — watching the infrastructure repository and syncing any changes to the cluster automatically
AWS Secrets Manager and External Secrets Operator to manage credentials securely without storing anything sensitive in the repository
Prometheus, Grafana, and Zipkin for metrics collection, dashboards, and distributed tracing

The team was organised around ownership. Each person or pair took a distinct layer and was fully responsible for it. That meant 11 people could work in parallel without stepping on each other.
My Role
I was part of the infrastructure team, working alongside my teammate Bola Balogun. Our job was to lay the foundation that everyone else would build on.
We worked with Terraform to provision everything the cluster needed on AWS. This included reviewing and validating the configuration files, making adjustments where needed, and running terraform plan and terraform apply to bring the resources to life. The infrastructure we provisioned covered the VPC and networking layer, the EKS cluster with its node groups, the IAM OIDC provider for service account permissions, and the AWS Load Balancer Controller for routing external traffic into the cluster.
One decision that proved important was how we structured the Terraform project. ECR repositories were placed in a separate global layer, independent of the dev and prod environments. This meant that when the cluster was torn down at the end of the project to avoid unnecessary AWS charges, the container images were not lost with it. The repositories persisted, and a future rebuild of the cluster could reference them immediately.
One of the trickier issues we ran into was with the IAM OIDC provider. On repeated terraform apply runs, Terraform would attempt to create a new OIDC provider even though one already existed in the account, causing failures. We resolved this by deleting the existing provider and allowing Terraform to own and manage it cleanly from that point forward.
What Went Well
The separation of ownership worked really well. Because each person had a clearly defined scope, there was very little confusion about who was responsible for what. Decisions got made quickly and the project moved at a good pace.
The GitOps workflow was also a highlight. Once ArgoCD was connected to the infrastructure repository, deployments became automatic. Merging a change to the manifests was all it took to trigger a rollout — no manual kubectl apply runs, no risk of someone deploying the wrong version.
What I Would Do Differently
I would invest more time upfront in documenting the Terraform outputs and sharing them with the team earlier. The ECR registry URL, cluster name, and RDS endpoint are referenced by almost every other team member, and any delay in having those values available creates a bottleneck across multiple workstreams simultaneously.
I would also set up a stricter branching and review process for the infrastructure repository. Infrastructure changes have a wider blast radius than application code — a misconfigured security group or a missing IAM permission can block the entire team. A mandatory review step before any terraform apply would add a useful safety net.
Final Thoughts
This project was part of the DMI DevOps Micro-Internship, a hands-on programme that puts you in a real team working on a real project. It is the kind of experience that changes how you think about software delivery — not just the tools, but the coordination, the communication, and the craft of building systems that other people depend on.
DMI Cohort 3 starts 27 June 2026. If you want to build real DevOps skills alongside a team, applications are open here 👇

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