How We Built and Automated Spring PetClinic Microservices on AWS EKS
A few weeks ago, my team and I completed our final DMI capstone project, and it turned out to be one of the most practical DevOps learning experiences I have had so far.
Our task was to deploy and automate the delivery of the Spring PetClinic microservices application on AWS using a modern DevOps approach.
Instead of running services manually, we built a complete GitOps-based deployment platform where application changes could move through a structured flow:
Code → Container Images → Kubernetes → Argo CD Deployment
The goal was to create a delivery system that was automated, controlled, traceable, and closer to how real production platforms are managed.
This project gave us hands-on experience with tools widely used in real production environments, including Terraform, Amazon EKS, Kubernetes, Helm, GitHub Actions, Argo CD, AWS ECR, AWS Secrets Manager, External Secrets, Prometheus, and Grafana.
Project Overview
Spring PetClinic was not a single application. It was made up of multiple microservices that all had to work together.
The services included:
Config Server
Discovery Server
API Gateway
Customers Service
Visits Service
Vets Service
Admin Server
GenAI Service
Each service had to be containerized, pushed to AWS Elastic Container Registry, configured properly with Helm values, and deployed into an Amazon EKS cluster.
Because this was a microservices project, deployment order mattered.
For example, the Config Server needed to be available before other services could read their configuration, and the Discovery Server had to be running so services could register and communicate properly.
So this project was not just about deploying containers. It was about understanding service dependencies, designing a reliable deployment flow, and building automation around the entire process.
My Role: CI/CD Engineer and Team Lead
My role on this project was both technical and leadership-focused.
As a CI/CD Engineer, I worked on the workflows that connected infrastructure provisioning, image management, secrets handling, GitOps automation, and Argo CD deployments.
As Team Lead, I coordinated activities across the different sub-teams, tracked progress, supported collaboration, and helped keep the project aligned with our delivery goals.
This gave me the opportunity to contribute directly to the technical implementation while also helping the team stay organized and focused.
What I Built and Contributed
1. Platform Lifecycle Automation
I worked on the platform.yaml workflow, which managed the platform lifecycle using Terraform across both development and production environments.
This workflow handled:
Terraform validation
Terraform formatting checks
Terraform plan
Terraform apply
Terraform destroy
AWS authentication
EKS access configuration
This helped automate the provisioning and management of the cloud infrastructure needed for the platform.
2. Post-Deployment Platform Bootstrap
After the infrastructure was provisioned, the cluster still needed important setup steps before applications could run properly.
I automated parts of the post-deployment setup, including:
Configuring
kubectlConfiguring Helm
Creating Kubernetes namespaces
Validating External Secrets prerequisites
Installing shared secrets
Bootstrapping initial Argo CD applications
This helped prepare the EKS cluster for application deployment.
3. Image Tag Automation
I developed the update-image-tags.yaml workflow.
This workflow listened for application image build events and automatically updated the correct Helm values files with the new image tags.
After updating the values files, it committed the changes back to the platform repository and triggered the GitOps deployment flow.
This was an important part of the automation because it connected the application build process to the deployment process.
4. Argo CD Deployment Workflow
I also supported a teammate in building the deploy-argocd.yml workflow.
This workflow connected to the EKS cluster, verified Argo CD readiness, applied AppProject and Application manifests, refreshed updated services, and waited for applications to reach a synced and healthy state.
This made the deployment process more reliable and easier to track.
5. Connecting CI/CD to GitOps
One of my major contributions was helping connect the image update workflow with Argo CD.
Once a new image was built and tagged, the system could automatically update the platform repository and allow Argo CD to deploy the change into Kubernetes.
This meant the deployment flow could happen without manual intervention.
That was one of the best parts of the project for me — seeing automation move from theory to a working system.
Architecture and Deployment Flow
At a high level, our deployment flow looked like this:
Developer pushes code
↓
GitHub Actions builds and scans Docker image
↓
Image is pushed to AWS ECR
↓
Helm values are updated in the platform repository
↓
Argo CD detects the change
↓
Argo CD syncs the application
↓
Services run on Amazon EKS
This workflow helped us separate CI from CD.
The application repository handled the build process, while the platform repository became the source of truth for deployments.
Argo CD then watched the platform repository and kept the Kubernetes cluster aligned with the desired state.
Tools We Used
Terraform
Terraform was used to provision AWS infrastructure, including the VPC, EKS cluster, ECR repositories, and other cloud resources.
Amazon EKS
Amazon EKS provided the Kubernetes environment where all the microservices were deployed and managed.
GitHub Actions
GitHub Actions powered our CI/CD automation, from image build workflows to platform lifecycle and deployment workflows.
AWS ECR
AWS Elastic Container Registry was used to store the Docker images for each microservice.
Helm
Helm helped us package and manage Kubernetes deployments using reusable charts and service-specific values files.
Argo CD
Argo CD handled GitOps-based continuous deployment by monitoring the platform repository and syncing the desired state into the Kubernetes cluster.
AWS Secrets Manager and External Secrets
AWS Secrets Manager and External Secrets helped us manage sensitive values like database credentials and API keys securely without hardcoding them into Kubernetes manifests.
Prometheus and Grafana
Prometheus and Grafana supported observability by helping us monitor the cluster and application services.
What I Learned About CI/CD and GitOps
One major lesson I learned is that CI/CD is not just a group of automated jobs.
It is the connection between infrastructure, container images, secrets, Kubernetes resources, and application delivery.
A good CI/CD system should be reliable, traceable, repeatable, and easy for a team to understand.
This project also helped me understand GitOps more clearly.
In GitOps, the platform repository becomes the source of truth. When a new image tag is committed to the repository, Argo CD detects the change and syncs the Kubernetes cluster to match the desired state.
That made the deployment process more controlled and transparent.
I also learned that automation has to be intentional. Every workflow should have a clear purpose and should fit into the bigger delivery system.
In our case, a build event needed to trigger an image tag update, the image tag update needed to trigger Argo CD, and Argo CD needed to deploy a healthy service into the cluster.
That full connection is what made the project feel like a real DevOps platform.
Challenges We Faced
Like most real-world projects, everything did not work perfectly from the beginning.
We faced challenges with:
Image paths
Service startup order
Kubernetes configuration
Permissions
Deployment dependencies
Argo CD application paths
Helm values files
Some services needed extra attention because they depended on other services being ready before they could start successfully.
We also had to make sure our Argo CD applications were pointing to the correct paths in the platform repository.
A small mistake in an image tag, values file, or application path could stop a service from deploying correctly.
But those challenges made the project more valuable because they pushed us to troubleshoot like a real DevOps team.
What Went Well
Teamwork
Different team members handled different parts of the project, including infrastructure, deployment, Helm configuration, CI/CD, and observability.
Even though we had different responsibilities, everything had to come together as one working platform.
Leading While Building
Leading the team while also contributing technically taught me the importance of communication, coordination, and shared ownership.
A technical project like this does not succeed only because the tools work. It succeeds when the team understands the goal and works together toward it.
End-to-End Automation
The most rewarding part was seeing a code change move through the entire pipeline:
Build → Tag → Update Values → Sync → Deploy
Watching that flow work without manual deployment steps was a major highlight of the project.
What I Would Do Differently
If I were to do this project again, I would spend more time documenting the deployment flow from the beginning.
In a microservices project, documentation is very important because there are many moving parts.
Clear documentation of service dependencies, repository structure, image tags, Helm values, Argo CD application paths, and troubleshooting steps would make onboarding and debugging much easier.
I would also introduce observability earlier in the project instead of adding it later.
Monitoring should be part of the deployment design from the start, not something added only after the services are running.
Final Thoughts
This project gave me a deeper understanding of how CI/CD connects every part of a modern DevOps workflow.
Deploying microservices is not just about Kubernetes commands or pipeline syntax. It is about designing a system where infrastructure, automation, security, monitoring, and deployment processes work together.
As both CI/CD Engineer and Team Lead, I learned that building a deployment platform requires technical skill, structure, communication, and teamwork.
A big shoutout to my amazing teammates:
Ihuoma Nkechi Bridget, Mapula Whitney Kataka, Acha Patience Uke, Vincent Onotu Bello, Stephen Odunze, Ezennajiofoeze Jacinta Chinyere, Ogbonna Nwanneka Mary, Nkechi Queeneth Ogbuji, Adesegun Asunmo, and Amarachi Nnadi.
It was a pleasure learning, collaborating, and building alongside all of you.
Special thanks to our Mentor, Pravin Mishra, Lead Co-Mentor, Praveen Pandey, and Group Co-Mentor, Ranbir Kaur, for their guidance, support, feedback, and encouragement throughout the project.
Your mentorship played a significant role in helping us successfully deliver this solution and deepen our understanding of DevOps practices.
DMI Cohort 3
DMI Cohort 3 starts on 27 June.
If you want to build real DevOps skills through hands-on projects, apply here:
👉 https://docs.google.com/forms/d/e/1FAIpQLSel7ai7nyb0P1qLW4vEyfB\_nEsD4lUF1XG88vmAaFGBOb6hPA/viewform
#DevOps #GitOps #AWS #Kubernetes #ArgoCD #Terraform #Helm #CICD #CloudComputing #DMI #TheCloudAdvisory
