A few weeks ago, my team and I worked on a cloud-native deployment for the Spring PetClinic microservices application as part of a DevOps capstone project. The application consisted of eight discrete services: the Config Server (operating on port 8888), the Discovery Server (operating on port 8761), the API Gateway, the Customers Service, the Vets Service, the Visits Service, the GenAI Service, and the Admin Server. All of these services needed to run smoothly within an Amazon Elastic Kubernetes Service (Amazon EKS) cluster.

While my teammates focused on infrastructure provisioning, continuous integration and continuous delivery (CI/CD) pipeline construction, and system monitoring, my role was narrowly but critically defined: configuring Helm values for every microservice. This document provides a detailed account of my responsibilities, the technical challenges I encountered, the solutions I implemented, and the lessons I learned about configuration management in a Kubernetes native environment.

My Role in the Team

I was responsible for managing the values.yaml files that controlled how each service behaved in Kubernetes. In the Helm packaging system, values.yaml it serves as the primary configuration file that overrides default parameters defined in a Helm chart. My responsibilities included configuring the following elements for every service:

• Ports: Ensuring that each service listened on the correct internal and external ports. For example, the Config Server needed to run on port 8888, the Discovery Server on port 8761, and the API Gateway on port 8080.

• Image tags: Pinning specific Docker image versions (for example, petclinic-customers:1.2.3) so that updates were intentional, version-controlled, and traceable across deployments.

• Environment variables: Passing service-specific configuration data without hardcoding values into container images or Kubernetes manifest files.

• Resource limits: Setting central processing unit requests and limits as well as memory requests and limits to prevent resource contention, commonly referred to as the "noisy neighbor" problem in multi-tenant clusters.

• Database connections: Configuring the Customers, Vets, and Visits services to point to the correct database endpoints, which included connection strings, authentication credentials, and pool settings.

• OpenAI application programming interface integration: Securely passing application programming interface keys via Kubernetes Secrets for the GenAI service, which provides artificial intelligence-powered features to the PetClinic application.

I also made sure that services could discover one another properly. If the Discovery Server was not configured correctly, the API Gateway could not route traffic to the backend business services. If the database connection strings were wrong, the Customers, Vets, or Visits services would fail to start or would produce runtime errors. Every small misconfiguration broke something, and my role required me to anticipate, prevent, and resolve these issues systematically.

What I Actually Did: A Detailed Breakdown

For each of the eight microservices, I defined Helm values in a structured values.yaml file. Below is a detailed explanation of what I configured and why each element mattered.

1. Port Configuration

Each service required specific container ports and service ports to enable communication within the Kubernetes cluster. I defined these ports in the Helm values so that the associated Kubernetes Service and Deployment objects could reference them consistently.

For example, the Config Server required port 8888 for configuration retrieval. The Discovery Server required port 8761 for service registration and lookup. The API Gateway required port 8080 for accepting external HTTP traffic. The GenAI Service required port 8080 as well, which meant I had to ensure no port conflicts occurred within the same pod or service namespace.

I also configured service.port and containerPort fields separately to distinguish between how the service was exposed internally to the cluster and which port the container actually listened on.

2. Image Tag Management

I pinned specific image tags for each service to enable reproducible deployments. Instead of using the latest tag, which introduces non-deterministic behavior, I used semantic version tags such as 1.2.3 or Git commit hashes.

When a developer pushed new code, the CI/CD pipeline built a new Docker image, pushed it to Amazon Elastic Container Registry (Amazon ECR), and produced a unique image tag. My responsibility was to manually or automatically update that tag in the corresponding Helm values file. This practice ensured that the cluster always ran a known, auditable version of each service.

3. Environment Variables

I passed service-specific environment variables through Helm values to avoid hardcoding sensitive or environment-specific data into the application code. For instance, the Customer Service needed a SPRING_DATASOURCE_URL variable pointing to its database. The GenAI Service needed an OPENAI_MODEL variable specifying which artificial intelligence model to use.

Environment variables were defined under a env Key in the Helm values, and the Helm template would translate these into Kubernetes environment variable definitions inside the pod specification.

4. Resource Limits and Requests

This was one of the most critical aspects of my role. Kubernetes uses resource requests to schedule pods on nodes with sufficient available capacity. It uses resource limits to enforce caps on resource consumption. Without proper limits, a single misbehaving service could consume all available central processing units or memory on a node, affecting other services.

I configured the following for each service:

• central processing unit requests: The minimum amount of central processing unit guaranteed to the container.

• central processing unit limits: The maximum central processing unit that the container could consume.

• Memory requests: The guaranteed memory allocation.

• Memory limits: The maximum memory allowed before the container would be terminated by the Kubernetes out-of-memory killer.

For example, the Config Server required modest resources, so I set a central processing unit request of 0.1 core and a memory request of 256 megabytes. The GenAI Service, being more computationally intensive, received higher allocations.

5. Database Connection Configuration

The Customers, Vets, and Visits services each needed to connect to a database. In our deployment, these services used a shared MySQL database instance running outside the Kubernetes cluster for demonstration purposes, though in production, they might use separate databases.

I configured the following database-related Helm values:

• Database hostname or endpoint

• Database port (typically 3306 for MySQL)

• Database name (for example, customer_db, vet_db, visit_db)

• Username and password references (via Kubernetes Secrets)

• Connection pool settings, such as maximum active connections and connection timeout

I used Helm value references to Kubernetes Secrets so that database credentials never appeared in plain text in the values.yaml file.

6. OpenAI Application Programming Interface Integration for the GenAI Service

The GenAI Service required an OpenAI application programming interface key to authenticate requests to OpenAI's models. Initially, this key was hardcoded in the values.yaml file, which posed a security risk because values.yaml Files are often stored in version control systems like Git.

I refactored the Helm templates to reference a Kubernetes Secret using the secretKeyRef construct. This meant the actual application programming interface key lived only in the cluster's Secret resource, never in the values.yaml file. The Helm values contained only the name of the Secret and the key within that Secret to reference.

This change ensured that sensitive information remained outside of version control while still being accessible to the GenAI Service container at runtime.

Key Challenge I Solved

Challenge: The GenAI Service Crashed Repeatedly Under Load

Shortly after deploying the full stack to Amazon EKS, the GenAI Service began crashing intermittently under modest traffic. The pod would start successfully, handle a few requests, and then be terminated by Kubernetes. The logs showed out-of-memory errors.

Diagnosis: After analyzing the pod events and using kubectl describe pod To inspect the termination reason, I discovered that the default memory limit for the GenAI Service was set to 512 megabytes (512Mi). When processing requests to OpenAI's application programming interface, the service needed to load model responses into memory, parse them, and perform additional processing. Under concurrent requests, memory usage exceeded 512Mi, triggering the out-of-memory killer.

Solution: I modified the Helm values for the GenAI Service by increasing the memory limit from 512 megabytes to 1 gigabyte (1Gi). I also set a memory request of 512 megabytes to ensure the pod would be scheduled on a node with at least that much memory available. Additionally, I increased the central processing unit limit from 0.5 cores to 1.0 cores to reduce request processing latency.

After reapplying the Helm chart with the updated values, the GenAI Service stabilized immediately. No further crashes occurred during the remainder of the project.

Secondary Challenge: Hardcoded OpenAI Application Programming Interface Keys

The original Helm values file contained the OpenAI application programming interface key in plain text under a env section. This was a security vulnerability because the values.yaml file was stored in a Git repository accessible to multiple team members.

Solution: I performed the following steps:

1. Created a Kubernetes Secret manually using kubectl create secret generic openai-secret --from-literal=api-key=<actual-key>

2. Modified the Helm values file to remove the plain text key and instead reference the Secret using secretKeyRef

3. Updated the Helm template for the GenAI Service to conditionally include the Secret reference

4. Documented the change so that future deployments would create the Secret before installing the Helm chart

This change ensured that the application programming interface key never appeared in version control, logs, or command line histories.

What Went Well

Helm Values Became Our Single Source of Truth

Before using Helm, my team had experimented with manually written Kubernetes YAML files. Any change required editing multiple files and applying them with kubectl apply. This approach was error-prone and difficult to audit.

With Helm values, every configuration parameter for every service lives in a predictable location. When a developer pushed new code, the CI/CD pipeline built an image, pushed it to Amazon Elastic Container Registry, and produced a new image tag. I updated the image tag in the relevant service's values.yaml file, committed the change to Git, and ArgoCD detected the change automatically. ArgoCD then synchronized the deployment to the Amazon EKS cluster without any manual kubectl commands.

This workflow made updates repeatable, auditable, and reversible. If a new image tag introduced a bug, I could revert the values.yaml change, and ArgoCD would roll back to the previous working state.

Environment Parity Across Development and Production

Because Helm values were parameterized, we used the same Helm chart for different environments. Only the values.yaml file changed. The development environment used smaller resource limits and development database endpoints, while production used higher limits and production database endpoints. This approach eliminated environment drift and reduced "it works on my machine" problems.

What I Would Do Differently

Introduce a Shared Helm Values Library

Several services reused identical configuration patterns. For example, the Customers, Vets, and Visits services all needed similar database connection settings and resource limits. However, I maintained these configurations separately in each service's values.yaml file. When I needed to change a common setting, such as increasing the database connection timeout, I had to edit three separate files manually. This led to configuration drift over time.

Improvement: I would create a shared Helm values library or use Helm's _helpers.tpl mechanism to define reusable configuration blocks. Alternatively, I would use a values file hierarchy where a global values.yaml defined common settings and service-specific files overrode only what was necessary.

Add Schema Validation for Values Files

Typos in environment variable names caused silent failures that took hours to debug. For instance, I once typed SPRING_DATSOURC_URL instead of SPRING_DATASOURCE_URL. The container started without error because the missing environment variable simply defaulted to an empty string, but the application failed at runtime with a cryptic database connection error.

Improvement: I would introduce schema validation using tools such as helm lint a custom schema defined via JSON Schema. The schema would enforce that required environment variables are present, that numeric fields such as memory limits contain valid units, and that port numbers fall within acceptable ranges. This validation would run in the CI/CD pipeline before any deployment, catching errors early.

Automate Image Tag Updates

In my role, I updated image tags manually. While this worked, it was slow and introduced the possibility of human error. A more robust approach would be to use a tool such as Renovate or Dependabot to automatically propose pull requests when new image tags become available in Amazon Elastic Container Registry. These tools can parse Helm values files, detect image tag changes, and create pull requests for review. After review, merging the pull request would trigger ArgoCD to synchronize the new version.

Final Reflection

Working in a team taught me that Helm values are not merely configuration files. They are the contract between developers, operations engineers, and the Kubernetes cluster. A single misconfigured port, a missing environment variable, or an overly restrictive memory limit can break service discovery, cause pods to crash, or inadvertently expose secrets to unauthorized parties.

This project gave me hands-on experience with Helm, Kubernetes, Amazon EKS, ArgoCD, and microservice communication patterns. More importantly, I learned that deployment engineers do not simply "set values." We ensure that every service has exactly what it needs to run, communicate, and scale — no more and no less. We translate application requirements into infrastructure configuration. We balance resource efficiency against reliability. And we create systems that are repeatable, auditable, and recoverable.

About the DevOps Micro-Internship

This project was part of the DevOps Micro-Internship (DMI), a program where participants build practical DevOps skills through real-world projects and teamwork. DMI Cohort 3 is starting on 27 June. If you want to build real DevOps skills, you can apply here:

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

However, as I progressed through the process, I quickly realized that local deployment involves more than merely starting containers. It is the stage at which one begins to understand how the application is architected, how the services communicate with one another, and what each component requires before it can operate reliably. For me, this local deployment became the foundational experience that later clarified the more complex cloud deployment.

Understanding the Application

Spring PetClinic is not a single application running as one unified service. It is a microservices-based application composed of several independent services that work in concert. Some of the main services include:

• Config Server

• Discovery Server

• API Gateway

• Customers Service

• Vets Service

• Visits Service

• Admin Server

• GenAI Service

• Monitoring components

Each of these services has a distinct role. The Config Server provides centralized configuration for the other services. This means that instead of each service managing all its settings separately, they can pull configuration from one central source. The Discovery Server allows services to register themselves and discover one another, which is essential in a microservices environment where services must communicate without relying on fixed network addresses. The API Gateway acts as the primary entry point into the application. Rather than clients calling each service directly, requests pass through the gateway and are routed to the appropriate backend service. The Customers, Vets, and Visits services handle the core business logic of the PetClinic application. The Admin Server assists with application monitoring, while the GenAI service adds an artificial intelligence-powered feature.

Before this project, I understood microservices in theory. Running them locally, however, helped me observe how these services depend on one another in practice.

Running the Application with Docker Compose

To run the full application locally, I used Docker and Docker Compose. Docker allowed each service to execute inside its own container, packaging the application together with its dependencies. Docker Compose made it possible to manage all containers from a single file and start them together using one command.

The primary command I used was:

docker compose up -d

This command started the services in detached mode, allowing the containers to run in the background. After starting the stack, I inspected the running containers with:

docker ps

This helped me confirm which services were running and whether they were healthy. When a service failed to start properly, I examined the logs using:

docker logs <container-name>

When I needed to stop the environment, I used:

docker compose down

These commands, though simple in appearance, proved highly useful for troubleshooting.

What I Learned About Startup Order

One of the most significant lessons from the local deployment was understanding startup order. In a microservices application, services do not all start simultaneously and work immediately. Some services must be available before others can function correctly.

For example, the Config Server needs to start early because other services depend on it for configuration. The Discovery Server must also be healthy because services need to register themselves before they can communicate effectively. After those foundational services are running, the business services, such as Customers, Vets, and Visits, can start properly. Only then can the API Gateway route traffic to the services.

This experience helped me understand why health checks and service dependencies are critical. It is not sufficient for a container to be running. The service inside the container must also be ready and healthy. That distinction is very important in DevOps. A container can be running while the application inside it is still failing.

Troubleshooting Locally

Local deployment also provided a safe environment for troubleshooting. Instead of waiting until the application was already deployed to the cloud, I could identify issues early from my local machine. I inspected container logs, monitored for unhealthy services, verified port assignments, and paid attention to environment variables.

Some of the elements I learned to check included:

• Whether the container is running

• Whether the service is healthy

• Whether the required environment variables are set

• Whether the Config Server is available

• Whether the Discovery Server is healthy

• Whether the services are registering correctly

• Whether there are port conflicts

• Whether the logs show connection errors

This process increased my confidence because I was not running commands blindly. I was learning how to investigate problems systematically.

Why Local Deployment Matters Before Cloud Deployment

After completing the local deployment, I understood why this step was important before moving to Amazon Web Services. Cloud deployment adds more layers: networking, Kubernetes, Helm, load balancers, secrets, continuous integration and continuous delivery pipelines, monitoring, and infrastructure provisioning.

If I had not first understood how the application worked locally, it would have been more difficult to troubleshoot issues in the cloud. Running the project locally helped me understand:

• The role of each microservice

• The dependencies between services

• The importance of configuration

• How Docker containers behave

• How logs assist with troubleshooting

• Why health checks matter

• How the application should behave before deployment

By the time my team and I moved to Amazon Web Services, I had a better understanding of what the application needed to run successfully. That made the cloud deployment phase more meaningful for me.

Preparing for the Amazon Web Services Deployment

The local Docker deployment was the first step before the larger team deployment on Amazon Web Services. After understanding the application locally, the next stage involved deploying the microservices with tools such as Kubernetes, Helm, ArgoCD, GitHub Actions, Prometheus, Grafana, and Terraform.

The local setup helped me connect the ideas. Docker helped me understand containers. Docker Compose helped me understand multi-service orchestration at a basic level. Kubernetes later expanded that idea into a more powerful orchestration platform. Helm helped package and manage Kubernetes configurations. ArgoCD introduced GitOps, where Git became the source of truth for deployment. Prometheus and Grafana assisted with observability. Terraform helped with infrastructure as code. Yet it all started locally.

Key Takeaways

This experience taught me that DevOps does not begin only in the cloud. Sometimes, DevOps starts on your local machine, with a terminal, a Docker Compose file, and logs that reveal what is truly happening. Before automation, you need understanding. Before scaling, you need stability. Before cloud deployment, you need to know how the application behaves.

Running Spring PetClinic locally with Docker gave me that foundation. It helped me understand the application from the ground up and prepared me for the team deployment on Amazon Web Services. For me, this was not just a local setup. It was the first real step in understanding how modern microservices move from local development to cloud native deployment.

Final Reflection

Looking back, I am glad I started with local deployment before joining the full Amazon Web Services deployment process. It gave me clarity, confidence, and a stronger technical foundation. I learned that every successful deployment starts with understanding the system. Tools are important, but knowing how the application works is even more important.

This project reminded me that DevOps is not only about using Docker, Kubernetes, or cloud platforms. It is about building reliable workflows, solving problems, improving delivery, and understanding the systems we deploy. For me, running Spring PetClinic locally with Docker was the ideal first step.