Deploy an E-Commerce Three-Tier Application on AWS EKS

This comprehensive guide covers the design principles, architectural patterns, and practical deployment workflow of a production-grade three-tier e-commerce application ("Robot Shop") onto an Amazon Elastic Kubernetes Service (AWS EKS) cluster.

1. Why Do We Need a Three-Tier Architecture & Microservices?

Modern cloud-native applications cannot scale effectively if built as a single, tightly-coupled monolithic binary. In a monolithic architecture, a single bug or resource spike in one module (e.g., catalog search) can bring down the entire application.

The Evolution of Application Architecture

• Monolithic Approach: All logic (UI, catalog, payments, shipping, user management) is compiled into a single binary or repository. Testing requires full regression testing; scaling requires duplicating the entire application.
• Microservices Approach: Decomposes the application into independent, decoupled services. Each service handles a specific business domain, communicates via well-defined APIs, and can be developed, tested, and scaled independently.

2. Core Mental Model: The Three-Tier Architecture

A three-tier architecture divides an application into three logical and physical computing tiers, ensuring separation of concerns, modular scalability, and enhanced security.

• Tier 1: Presentation Layer (Frontend): The user interface exposed to the end-user (built with Angular and served via Nginx). Handles user interaction, rendering catalogs, and shopping cart management.
• Tier 2: Application / Logic Layer: Microservices written in diverse programming languages (Python, Java, PHP, Go, Node.js) handling business workflows such as user authentication, pricing calculations, and order dispatching.
• Tier 3: Data Layer: Persistence stores including relational databases (MySQL), document databases (MongoDB), and in-memory data structures (Redis).

3. Real-Life Analogy: The Restaurant Workflow

Real-Life Analogy: Think of a modern restaurant to understand three-tier architecture:

• The Dining Room & Menu (Presentation Layer): Where customers look at pictures and descriptions, select items, and place orders. Customers never step foot in the kitchen.
• The Kitchen Staff / Line Cooks (Logic / Microservices Layer): Specialized chefs working independently. One chef handles grill items (Catalog), another manages drinks (Cart), and another handles billing (Payments). They communicate via an order ticket queue (RabbitMQ / Redis).
• The Walk-In Pantry & Storage Vault (Data Layer): Where raw ingredients (MySQL / MongoDB) and active prep lists (Redis in-memory store) are securely maintained so data persists even if a line cook takes a break.

4. The Demo Project: "Robot Shop" Overview

To demonstrate a robust three-tier deployment, the Robot Shop application (originally created by IBM for Instana monitoring demonstrations) is utilized. It simulates a fully functioning e-commerce platform selling robots and AI-driven products.

Key Functional Workflows

1. User Registration & Authentication: Users sign up or log in, verified against a user database.
2. Catalog Browsing: Users view categories (AI products and robots), inspect high-resolution images, read descriptions, and check pricing and community ratings.
3. Cart Management: Items are added to the cart; data is stored in an in-memory cache/store so user carts persist across sessions.
4. Checkout & Shipping Calculation: Users enter shipping addresses (e.g., region and city calculation) to compute distance and shipping fees.
5. Payment Processing & Order Dispatch: Integrates with simulated payment gateways and pushes completed order IDs into a messaging queue for asynchronous dispatch.

5. Microservices Breakdown & Technology Stack

The Robot Shop application is composed of multiple independent microservices and backing data stores.

6. Naive vs. Production-Grade Kubernetes Deployment Strategies

The Naive Approach (Manual Manifests)

Managing 12+ individual microservices by writing separate YAML files for deployments and services (deployment.yaml, service.yaml) for each component leads to severe configuration drift, maintenance nightmares, and high human error rates during version updates.

The Production-Grade Approach (Helm Charts)

Instead of applying dozens of disconnected manifests, Helm Charts package all Kubernetes resources into a single parameterized chart (Chart.yaml, values.yaml, and a templates/ directory).

• Centralized image repositories and tag versions are managed cleanly in values.yaml.
• Deployment, Service, and Ingress templates dynamically consume parameters, making multi-environment deployments repeatable and robust.

7. AWS EKS Architecture & Infrastructure Prerequisites

Unlike previous lightweight deployments (such as serverless Fargate profiles), running stateful workloads like Redis or utilizing persistent block storage (AWS EBS) requires EC2 worker nodes inside an EKS cluster.

Prerequisites Checklist

• awscli (AWS Command Line Interface configured with proper credentials)
• eksctl (Official CLI for Amazon EKS cluster management)
• kubectl (Kubernetes command-line tool)
• helm (Package manager for Kubernetes)

8. Step-by-Step EKS Cluster & IAM Configuration

Step 1: Create the EKS Cluster with EC2 Worker Nodes

Execute the following eksctl command to provision the EKS cluster on EC2 instances (choosing a region such as us-west-1 to avoid availability zone capacity bottlenecks):

eksctl create cluster \
  --name demo-cluster-eks-robot-shop \
  --region us-west-1 \
  --nodegroup-name standard-workers \
  --node-type t3.medium \
  --nodes 2 \
  --nodes-min 1 \
  --nodes-max 3 \
  --managed

Step 2: Configure OIDC & IAM Service Accounts

To allow Kubernetes pods to securely interact with underlying AWS resources (such as attaching EBS volumes for stateful data stores), configure OpenID Connect (OIDC):

# Export cluster name
export CLUSTER_NAME="demo-cluster-eks-robot-shop"
export REGION="us-west-1"

# Associate OIDC provider
eksctl utils associate-iam-oidc-provider \
  --cluster $CLUSTER_NAME \
  --region $REGION \
  --approve

9. AWS Load Balancer Controller & EBS CSI Driver Integration

ALB Ingress Controller Setup

To expose the internal Nginx frontend service externally to the internet via an Application Load Balancer (ALB), install the AWS Load Balancer Controller.

1. Create IAM Policy for ALB Controller: Download and create the IAM policy allowing EKS pods to manage AWS ALBs.
2. Create IAM Service Account:
   BASH

   Copy

   eksctl create iamserviceaccount \
     --cluster=$CLUSTER_NAME \
     --namespace=kube-system \
     --name=aws-load-balancer-controller \
     --role-name AmazonEKSLoadBalancerControllerRole \
     --attach-policy-arn=arn:aws:iam::ACCOUNT_ID:policy/AWSLoadBalancerControllerIAMPolicy \
     --approve
   

3. Install ALB Controller via Helm:
   BASH

   Copy

   helm repo add eks https://aws.github.io/eks-charts
   helm repo update
   helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
     -n kube-system \
     --set clusterName=$CLUSTER_NAME \
     --set serviceAccount.create=false \
     --set serviceAccount.name=aws-load-balancer-controller \
     --set region=$REGION \
     --set vpcId=<YOUR_VPC_ID>
   

EBS CSI Driver Setup (Persistent Storage for Redis)

Stateful applications like Redis require persistent storage volumes (AWS EBS). The EBS CSI (Container Storage Interface) Driver enables Kubernetes StorageClasses to automatically provision and attach EBS volumes when Persistent Volume Claims (PVCs) are requested.

# Create IAM service account for EBS CSI Driver
eksctl create iamserviceaccount \
  --cluster=$CLUSTER_NAME \
  --namespace=kube-system \
  --name=ebs-csi-controller-sa \
  --role-name AmazonEKS_EBS_CSI_DriverRole \
  --attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \
  --approve

# Add EBS CSI Add-on to EKS
eksctl create addon \
  --cluster=$CLUSTER_NAME \
  --name aws-ebs-csi-driver \
  --region $REGION \
  --force

10. Deploying the Robot Shop Helm Chart & Ingress

With infrastructure, IAM controllers, and CSI drivers active, deploy the complete microservices application stack.

Step 1: Create Namespace and Deploy via Helm

# Create dedicated namespace
kubectl create namespace robot-shop

# Navigate to Helm chart directory and install
cd helm/
helm install robot-shop . -n robot-shop

Step 2: Verify Pod Status

Check that all microservices, databases, and message queues successfully start up:

kubectl get pods -n robot-shop

(Note: Relational and Java-based microservices like shipping and ratings may take a few minutes to fully initialize).

Step 3: Expose Application via Kubernetes Ingress

Apply the Ingress manifest to map external traffic through the AWS Application Load Balancer to the internal web service (port 8080):

kubectl apply -f ingress.yaml -n robot-shop

Check the Ingress resource status to retrieve the ALB DNS endpoint:

kubectl get ingress -n robot-shop

11. Real-World Practical Pitfalls & Troubleshooting

• CloudFormation Stack Rollback Failures: When creating IAM service accounts or ALB controllers via eksctl, if a stack creation fails mid-way, eksctl will fail subsequent runs unless you manually log into the AWS CloudFormation console, delete the failed stack, and re-run the command.
• Fargate Incompatibility with Stateful Workloads: AWS Fargate cannot be used for stateful components like Redis because Fargate lacks support for privileged root containers (net-admin capabilities) and dynamic EBS Persistent Volume attachments. Always use EC2 worker nodes for stateful microservices.
• ALB Provisioning Delay: After applying the Ingress resource, AWS takes 2-4 minutes to provision the Application Load Balancer. Accessing the DNS name immediately will result in a temporary 503 Service Temporarily Unavailable error until the ALB health checks pass and targets become healthy.

12. Complete Flow Walkthrough

13. Summary and Key Takeaways

• Three-Tier Architecture cleanly separates concerns into Presentation (Frontend), Logic (Microservices), and Data (Databases & Caching) layers.
• Microservices Architecture allows independent teams to build, test, and deploy services in different programming languages without monolithic regression overhead.
• AWS EKS with EC2 Worker Nodes provides the underlying compute required for stateful and privileged workloads that serverless options like Fargate cannot support.
• Helm Charts simplify the management of complex, multi-service applications by templating Kubernetes manifests and centralizing configuration values.
• AWS Load Balancer Controller & EBS CSI Driver automate the integration between Kubernetes Ingress resources/Persistent Volume Claims and native AWS infrastructure (ALB and EBS).
• Asynchronous Message Queues (RabbitMQ/Dispatch) decouple time-sensitive order placement from background fulfillment workflows.
• Resource Cleanup: Always delete cloud resources promptly after testing using eksctl delete cluster --name demo-cluster-eks-robot-shop --region us-west-1 to prevent unexpected AWS billing charges.