From Terraform to Kubernetes: Building a Production-Grade Microservices Platform on AWS

As part of the DevOps Micro Internship (DMI), our team was tasked with deploying and operating a production-style cloud-native application using modern DevOps practices. Over the course of the project, we worked as a distributed engineering team to provision cloud infrastructure, automate deployments, implement observability, and deploy a complete microservices application to Kubernetes.

The project was based on the Spring PetClinic Microservices application, a distributed veterinary clinic management system built with Java 17 and Spring Cloud. While the application code was already provided, our responsibility was to design and implement the entire DevOps ecosystem required to run it reliably in the cloud.

What We Built

Our team delivered a complete end-to-end deployment platform on AWS.

The project included:

• Containerizing nine Spring Boot microservices using Docker

• Provisioning AWS infrastructure using Terraform

• Building a Kubernetes platform on Amazon EKS

• Creating Amazon ECR repositories for container images

• Implementing CI/CD pipelines using GitHub Actions

• Configuring GitHub OIDC authentication for secure AWS access

• Deploying Prometheus, Grafana, and Zipkin for observability

• Exposing the application through an AWS Application Load Balancer

• Implementing Kubernetes health checks and autoscaling

• Validating application resiliency through self-healing tests

Rather than manually creating cloud resources through the AWS Console, we adopted an Infrastructure as Code approach to ensure every environment could be reproduced consistently.

My Role: Infrastructure Lead

I served as the Infrastructure Lead for the project.

My responsibility was to build and maintain the AWS foundation that every other team depended on. Without the infrastructure layer, Kubernetes deployments, CI/CD pipelines, monitoring, and application delivery would not have been possible.

Some of my key responsibilities included:

• Creating the S3 backend for Terraform remote state storage

• Configuring DynamoDB state locking

• Designing and deploying the AWS VPC

• Creating public and private subnets

• Configuring Internet Gateway and NAT Gateway networking

• Deploying the Amazon EKS cluster

• Configuring EKS managed node groups

• Creating and validating IAM roles and permissions

• Setting up AWS billing alerts and budget monitoring

• Running Terraform deployments and infrastructure validation

One of my primary goals was ensuring that all infrastructure was defined as code, version-controlled, and reproducible.

Solution Architecture

The deployed platform followed a modern cloud-native architecture:

The infrastructure layer was deployed into a custom AWS VPC containing public and private subnets. Amazon EKS hosted the Kubernetes workloads, while Amazon ECR stored container images produced through the CI/CD pipeline.

A Technical Challenge I Solved

One of the most interesting challenges involved Terraform backend initialization.

Terraform was configured to use an S3 bucket for remote state storage and a DynamoDB table for state locking. However, Terraform cannot create the backend resources it depends on during initialization.

This created a classic "chicken-and-egg" problem.

To resolve it, I manually created the S3 bucket and DynamoDB table before running terraform init. Once the backend existed, Terraform successfully initialized and managed the remainder of the infrastructure through code.

Although simple in hindsight, the experience reinforced the importance of understanding how Terraform manages state and how production Infrastructure as Code workflows are designed.

What Went Well

Several aspects of the project were particularly successful.

First, Infrastructure as Code significantly reduced configuration drift and made deployments repeatable. Team members could provision and validate environments using the same Terraform codebase.

Second, the combination of Kubernetes, CI/CD automation, and observability created a deployment platform that closely resembled a real-world production environment.

Finally, collaboration across multiple engineering disciplines worked exceptionally well. Infrastructure, Kubernetes, CI/CD, observability, documentation, and application teams were able to coordinate effectively throughout the project lifecycle.

What I Would Do Differently

If I were to start the project again, there are a few improvements I would make.

I would ensure all team members receive EKS access from the beginning of the project. This would eliminate delays caused by access management and improve productivity during the early stages.

I would also automate deployment of the observability stack earlier in the project and perform complete end-to-end validation at least 24 hours before the final demonstration.

Finally, I would invest more time in operational runbooks and troubleshooting documentation from day one rather than creating them later in the sprint.

Lessons Beyond Technology

One of the most valuable lessons from the project had nothing to do with AWS or Kubernetes.

Our team operated across multiple countries, including Nigeria, Germany, Ghana, Zimbabwe, and Canada. Coordinating meetings, sprint activities, troubleshooting sessions, and presentation rehearsals required strong communication and careful planning across different time zones.

The experience taught me that successful DevOps is not just about tools and automation. It is equally about collaboration, ownership, documentation, and effective communication within a distributed team.

Final Thoughts

This project provided practical experience with AWS, Terraform, Kubernetes, Docker, GitHub Actions, Prometheus, Grafana, and modern DevOps workflows.

More importantly, it demonstrated how multiple engineering disciplines come together to deliver a complete production-ready platform. From infrastructure provisioning to application deployment and observability, every component depended on teamwork and shared responsibility.

The experience strengthened both my technical and collaboration skills and gave me a realistic view of how modern cloud engineering teams operate.

This project was completed as part of the DevOps Micro Internship (DMI).

DMI Cohort 3 is starting soon. If you would like to gain hands-on experience building real-world DevOps projects, you can apply here:

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

#DMI #DevOps #CloudComputing #AWS #Terraform #Kubernetes #EKS #InfrastructureAsCode #TheCloudAdvisory