The Challenge: Migrating a GKE-Native App to AWS EKS
Google's Online Boutique, an open-source e-commerce demonstration application, is designed to run on Google Kubernetes Engine (GKE). It comprises eleven distinct microservices written in Go, Python, Node.js, C#, and Java, communicating via gRPC. The objective of this project was to deploy this application onto Amazon Web Services (AWS) Elastic Kubernetes Service (EKS) and establish a full production-ready platform around it. Crucially, this had to be accomplished without modifying any of the application's source code. The entire infrastructure—Terraform, EKS, ECR, IAM, Helm, and GitHub Actions—was built from scratch on AWS, leaving the application layer untouched.
Building the AWS Infrastructure with Terraform
The infrastructure deployment relied on a structured Terraform configuration, broken down into seven distinct files, each handling a specific aspect of the AWS environment:
- vpc.tf: Configured a Virtual Private Cloud (VPC) spanning three Availability Zones (AZs), establishing both public and private subnets, and setting up a NAT Gateway for outbound internet access from private instances.
- eks.tf: Deployed the EKS cluster named "online-boutique-production", utilizing Kubernetes version 1.30. The cluster was provisioned with two
t3.smallnodes for the initial setup. - ecr.tf: Created twelve Amazon Elastic Container Registry (ECR) repositories, corresponding to each microservice in the Online Boutique application. Image scanning was enabled on push to ensure security compliance.
- iam.tf: Implemented AWS Identity and Access Management (IAM) roles for service accounts (IRSA), adhering to the principle of least privilege. This ensured that EKS pods had granular permissions without granting broad access to the worker nodes themselves.
- backend.tf: Configured the Terraform backend to use an Amazon S3 bucket for remote state management, ensuring state consistency and enabling collaboration.
This modular approach to infrastructure as code ensures clarity, maintainability, and reproducibility of the deployment.
Containerization and Image Management
Since no application code changes were permitted, the existing container images provided by Google were used directly. These images were pushed to newly created ECR repositories. This step is critical: it ensures that the deployed services are identical to those tested and intended by the original developers. The ECR setup with image scanning on push adds a vital security layer, automatically checking for known vulnerabilities in the container images before they can be deployed.
Orchestration with EKS and Helm
Amazon EKS serves as the managed Kubernetes control plane, abstracting away the complexities of managing Kubernetes masters. The worker nodes, provisioned via Terraform, run within private subnets for enhanced security. Helm was employed as the package manager for Kubernetes applications. While the application manifests were not altered, Helm charts were created to deploy these existing Kubernetes resource definitions (Deployments, Services, Ingresses, etc.) onto the EKS cluster. This allows for templating and managing the lifecycle of the application components in a Kubernetes-native way, even without modifying the application's internal configuration or code.
CI/CD Pipeline with GitHub Actions
A GitHub Actions workflow was established to automate the deployment process. This pipeline integrates with Terraform for infrastructure provisioning and updates, and with Helm for deploying the Online Boutique application itself. The workflow is triggered by changes in the repository, ensuring that infrastructure and application deployments are consistently managed and updated. This automation is key to maintaining a production-ready environment, enabling rapid rollouts of updates and patches without manual intervention.
The Result: A Production-Ready EKS Deployment
The culmination of this effort is a fully functional, production-ready deployment of Google's Online Boutique on AWS EKS. The entire stack—from the underlying AWS infrastructure managed by Terraform, to the container orchestration by EKS, and the application deployment managed by Helm—was built and configured to support the application without any code modifications. This demonstrates a robust approach to migrating cloud-native applications designed for one platform to another, emphasizing infrastructure and operational tooling over application-level changes. The use of IRSA for pod permissions highlights a security-first approach, essential for any production environment.
The surprising detail here is not merely that the deployment was successful, but that it achieved a full production setup—including networking, security, IAM, CI/CD, and orchestration—entirely through infrastructure and deployment tooling, leaving the application's 11 microservices and their gRPC communication untouched. This approach is particularly valuable for organizations looking to leverage cloud-agnostic architectures or migrate complex microservice applications without the prohibitive cost and risk of re-architecting or re-coding the application itself.