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
Top comments (0)