iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Google’s Online Boutique is designed to run on Kubernetes, so its application source can be deployed on Amazon EKS without assuming you need to rewrite it. But “works on any Kubernetes cluster” does not make the GKE quickstart an EKS production recipe: you still need to choose and configure the EKS cluster, networking, and AWS-aware frontend exposure. A running storefront alone does not establish production readiness.
What Online Boutique contains—and what portability means
Google describes Online Boutique as a cloud-first e-commerce demo: visitors can browse products, add items to a cart, and place an order. The application comprises 11 services written in different languages that communicate over gRPC: frontend, cart, product catalog, currency, payment, shipping, email, checkout, recommendation, ad, and load generation. Payment, shipping, and email are mock behaviors; the load generator imitates shopping flows. It is a demonstration application, not a complete production commerce platform.
The project README says, “This application works on any Kubernetes cluster.” Its documented quickstart is nevertheless explicitly for GKE: it creates a GKE cluster, applies ./release/kubernetes-manifests.yaml, waits for Pods, and retrieves the external frontend service address. That supports adapting the workload to EKS; it does not prove the default manifests create an appropriate EKS ingress design or that a particular deployment ran unchanged.
What you need to decide before deploying to EKS
- Cluster and compute: choose an EKS operating mode and node configuration, plus the AWS region, VPC, subnets, and endpoint access. AWS’s EKS Auto Mode quickstart demonstrates an automated infrastructure path, but its sample deploys 2048, not Online Boutique.
- Identity and permissions: document how workloads and operators receive AWS permissions. The application’s Kubernetes portability does not select an IAM approach for you.
- Frontend exposure: choose the AWS load-balancing path and adjust Kubernetes resources or annotations as needed. The upstream GKE external-service example is not, by itself, an EKS ingress design.
- Operations: decide how you will patch nodes, restrict network access, monitor and retain logs, and handle workload availability. These controls are not demonstrated by seeing the storefront load.
Choose how EKS will provision infrastructure and load balancing
| Decision area | EKS Auto Mode | Conventional EKS with AWS Load Balancer Controller |
|---|---|---|
| Infrastructure provisioning | AWS’s quickstart describes Auto Mode as provisioning nodes dynamically and providing block storage. Exact configuration still depends on the cluster and workload. | Cluster operators manage the node and add-on arrangement; the cited AWS material does not prescribe one universal configuration. |
| Load-balancer integration | AWS says Auto Mode provides load-balancing capability without installing the AWS Load Balancer Controller. | The controller reconciles Kubernetes Service and Ingress resources; manifests need suitable configuration and annotations. |
| HTTP/HTTPS frontend | Use the Auto Mode capability with the corresponding Kubernetes configuration. | AWS describes ALB for HTTP/HTTPS. |
| TCP/UDP or client source-IP needs | Confirm the Auto Mode configuration meets the protocol and source-IP requirements. | AWS describes NLB for TCP/UDP or client source-IP preservation. |
| Operational control | More infrastructure management is automated; AWS’s cited material does not establish that this is cheaper or the right fit for every workload. | Operators select and maintain the controller-based integration and associated cluster components. |
The table describes AWS’s documented options, not a claim about which one was used for a particular Online Boutique deployment. Select one path and record the actual resource type, target type, health-check behavior, TLS and domain configuration, and ingress or service settings. Do not mix an assumed controller setup with Auto Mode instructions.
#1 Best Overall
Deploy the application in stages
This sequence separates the upstream workload from AWS infrastructure choices. It is not a copy-paste production recipe: the available project instructions describe GKE, and no specific EKS version, region, IAM setup, VPC, or frontend configuration is established here.
- Pin the application source. Use the
GoogleCloudPlatform/microservices-demorepository and record the exact tag or commit you deploy. The README quickstart refers to thev0branch; a branch name alone is not an immutable revision. Keep the application source distinct from any EKS-specific manifest edits. - Create and document the EKS cluster. Choose Auto Mode or a conventional arrangement, then specify the region, Kubernetes version, VPC and subnet layout, endpoint access, node configuration, and operator/workload permissions. AWS’s Auto Mode quickstart is a platform reference, not an Online Boutique deployment guide.
- Connect kubectl to the intended cluster. Confirm the active context and that the expected cluster nodes are available before applying workload manifests. This avoids sending resources to the wrong cluster.
- Review the upstream Kubernetes manifest. Inspect
./release/kubernetes-manifests.yaml, particularly the frontend Service and any assumptions about external exposure. Preserve application source if no app-code change is needed, but make and track infrastructure or manifest changes required for the selected EKS load-balancing path. - Apply the workload and check readiness. The upstream quickstart applies the manifest with
kubectl apply -f ./release/kubernetes-manifests.yaml. On EKS, use that only after reviewing whether the service and ingress configuration are appropriate. Watch Pod readiness and inspect Services and events; a pending load balancer or unhealthy target is an exposure/configuration issue to diagnose, not proof that the application code needs changing. - Configure public access deliberately. Set up the selected ALB or NLB route through Auto Mode or the AWS Load Balancer Controller, as appropriate. Validate listener protocol, target type, health checks, DNS, and TLS if required. The project’s GKE quickstart does not specify these EKS choices.
- Verify the user path and operational signals. Confirm the storefront is reachable through the intended endpoint and exercise the demo shopping flow. Check component-level health, logs, metrics, and—where configured—traces; retain logs outside short-lived Pods if they need to survive restarts.
When is the setup production-ready?
“Production” is an operational claim, not a synonym for “the Pods started.” AWS distinguishes control-plane responsibility from shared data-plane reliability. With managed node groups, AWS builds patched EKS-optimized AMIs, but customers remain responsible for deploying patched AMI versions to their node groups. The application’s successful startup does not establish high availability, security, disaster recovery, or supportability.
- Reliability: identify the node and workload availability design, readiness and health checks, scaling behavior, and disruption handling that are actually configured.
- Updates: record the cluster and node update process, including how patched node images reach node groups.
- Network security: document endpoint access, subnet and traffic boundaries, and the controls limiting communication to and between workloads.
- Observability: define how logs are retained and how metrics and traces are collected across the microservices. Kubernetes does not automatically retain Pod logs.
- Recovery and cost: state the backup or recovery approach and how resources are removed when the environment is no longer needed. A demo deployment is not evidence of a tested recovery plan or a known recurring cost.
Before describing a specific setup as complete or production-ready, publish its repository revision, EKS version and region, cluster mode and node configuration, IAM approach, network design, frontend resource and load-balancer configuration, TLS/domain details, readiness and health checks, scaling and disruption controls, patch procedure, security controls, and logging/metrics/tracing arrangement. If any item is not configured or verified, say so rather than implying it exists.
Can you claim zero application-code changes?
Yes, but only as a bounded statement about the specific deployment. Identify the upstream revision, state whether application source files were untouched, and list any Kubernetes manifests or AWS infrastructure configuration that changed. “No app-code changes” does not mean “no deployment changes”: EKS networking, permissions, and frontend exposure may require separate configuration. The project’s portability statement supports the possibility; it does not verify an individual deployment.
Quick Recap
Best Value
Rank #3
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
