I Thought Deploying to Kubernetes Was Just YAML Files—Until This AWS Project Changed Everything

A few weeks ago, my team and I completed what has easily been one of the most challenging and rewarding projects of my DevOps journey so far.

The task sounded simple on paper: deploy the Spring PetClinic Microservices application on AWS.

But as we quickly discovered, deploying a modern microservices application is much more than getting containers to run.

It’s about networking.

It’s about automation.

It’s about security.

It’s about making multiple moving parts communicate seamlessly without breaking everything else.

And that’s exactly what made this project such a valuable learning experience.

The Challenge: Turning Complexity into a Working Platform

Spring PetClinic is not a single application.

It’s a collection of independent microservices that must work together as one system.

The platform includes services such as Config Server, Discovery Server, API Gateway, Customer Service, Vet Service, Visit Service, Admin Server, and a GenAI Service.

Each service has its own responsibility, dependencies, configurations, and communication requirements.

Our goal was to deploy the entire platform on AWS using modern DevOps practices rather than relying on manual deployments.

To achieve this, we built a complete cloud-native deployment workflow using:

• Terraform for Infrastructure as Code

• Amazon EKS for Kubernetes orchestration

• Helm for application packaging

• GitHub Actions for CI/CD automation

• Argo CD for GitOps deployments

• AWS Secrets Manager for secret storage

• External Secrets Operator for secret synchronization

• AWS Application Load Balancer for ingress traffic

This wasn’t simply about deploying applications.

We were building a deployment platform.

My Role: Deployment Engineering in Action

As part of the Deployment Team, I was responsible for deploying and configuring several critical components within the Kubernetes cluster.

My focus areas included:

• API Gateway

• GenAI Service

• Ingress

• External Secrets

At the beginning of the project, I thought deployment engineering was mostly about writing Kubernetes manifests and running deployment commands.

I quickly learned how wrong that assumption was.

A deployment is only successful when every service can communicate correctly, secrets are securely available, traffic flows to the right destination, and dependencies start in the correct order.

In other words, deployment engineering sits at the intersection of infrastructure, networking, security, and application architecture.

The Moment Everything Started Making Sense

One of my biggest responsibilities was working with the API Gateway.

The API Gateway acts as the front door of the platform.

Instead of users interacting directly with individual microservices, requests enter through the gateway and are routed to the appropriate backend services.

Sounds straightforward.

Until you realize that a single routing mistake can make an entire application appear broken.

Configuring the gateway forced me to understand how services discover one another, how traffic moves inside Kubernetes, and why service communication is one of the most important parts of a microservices architecture.

That was one of the moments when Kubernetes stopped feeling like a collection of YAML files and started making practical sense.

Security Is Not Optional

Another area I worked on was integrating External Secrets with AWS Secrets Manager.

The GenAI Service required access to sensitive credentials.

Hardcoding secrets into deployment files would have been a terrible security practice.

Instead, we used AWS Secrets Manager as the source of truth and synchronized those secrets into Kubernetes using External Secrets.

This was one of my favorite parts of the project because it demonstrated a principle that every DevOps engineer should understand:

If your deployment is not secure, it is not production-ready.

Learning how cloud-native applications manage secrets securely gave me a deeper appreciation for the operational side of software delivery.

Making Services Reach the Outside World

I also worked on configuring ingress resources that allowed external users to access services running inside the cluster.

Without ingress, applications inside Kubernetes remain isolated.

By integrating ingress with the AWS Application Load Balancer, we were able to route traffic into the cluster and expose services to users.

The first time we successfully accessed the application through the configured ingress felt like a major milestone.

After days of deployments, troubleshooting, and configuration updates, seeing traffic successfully flow from the internet into the cluster was incredibly satisfying.

What Went Well

One thing that stood out throughout this project was teamwork.

Infrastructure engineers provisioned AWS resources.

CI/CD engineers automated image builds and deployments.

Deployment engineers configured workloads and networking.

Together, we created a workflow where code changes could move from GitHub to Kubernetes with minimal manual intervention.

Watching all eight services come online and work together felt like watching individual puzzle pieces finally form a complete picture.

What I Learned

The biggest lesson I took away from this project is that DevOps is not about tools.

Terraform, Kubernetes, Helm, GitHub Actions, and Argo CD are powerful technologies, but they are only enablers.

The real value comes from understanding how systems work together.

A successful deployment requires knowledge of infrastructure, networking, security, automation, service discovery, and collaboration.

This project challenged me technically, stretched my problem-solving abilities, and gave me hands-on experience with technologies used by engineering teams around the world.

Most importantly, it transformed concepts I had only studied into skills I could actually apply.

And for me, that’s where real learning happens.

Big shoutout to my teammates: Nkechi Ihuoma (MBA), Whitney Kataka Candidate) Acha Patience Uke VINCENT ONOTU BELLO Stephen Odunze, CISA, CompTIA Security, CC, ITIL, CCNA Ezennajiofoeze Jacinta
Ogbonna Nwanneka Mary Goodness Ojonuba Adesegun Asunmo Amarachi Nnadi

A heartfelt thank you to Pravin Mishra for allowing us to learn, grow, and gain real hands-on experience throughout this journey.

Special thanks to Praveen Pandey and Ranbir Kaur for your constant support, guidance, and encouragement. Your mentorship made the learning process easier, meaningful, and truly impactful.

I am genuinely grateful for the knowledge, confidence, and experience gained along the way.

DMI Cohort 3 is starting 27 June — if you want to build real DevOps skills, apply here 👇
https://lnkd.in/daAtY_TZ