GoogleCloudPlatform/microservices-demo: Online Boutique as a Kubernetes and gRPC Test Bench

What Online Boutique Is and Who It Is Built For

Online Boutique is a web-based e-commerce demo where users browse items, add them to a cart, and purchase them. Google uses it to demonstrate how enterprise applications can be modernized with Google Cloud products, naming Google Kubernetes Engine, Cloud Service Mesh, gRPC, Cloud Operations, Spanner, Memorystore, AlloyDB and Gemini in the README. The same README states the application works on any Kubernetes cluster, which is the sentence that matters most for anyone outside Google Cloud.

The audience is therefore narrow and specific. Platform engineers who need a realistic multi-service workload to validate cluster configuration, mesh sidecar injection, or tracing pipelines are the primary users. Instructors who want students to see gRPC calls crossing language boundaries get a ready-made topology. Developers learning Kubernetes manifests get a set of Deployments and Services that actually talk to each other rather than a hello-world Pod. The repository asks readers to star it to show interest, and there is a note addressed to Googlers about an internal form, both of which signal that this is a sample maintained for demonstration rather than a product with a support contract.

The 11 Services and How Traffic Moves Through Them

The README describes 11 microservices written in different languages that talk to each other over gRPC, with Protocol Buffers definitions in the ./protos directory. That proto directory is the contract layer: each service exposes a defined interface, and the language of the implementation is an implementation detail behind it.

The composition is deliberately varied. frontend is Go and exposes an HTTP server for the website; it requires no signup or login and generates session IDs automatically. cartservice is C# and keeps cart contents in Redis. productcatalogservice is Go and reads products from a JSON file. currencyservice is Node.js, converts money amounts using values fetched from the European Central Bank, and the README calls it the highest QPS service, which makes it the first place to look when a load test shows latency. paymentservice is Node.js and charges mock credit card info. shippingservice is Go and returns mock shipping estimates. emailservice is Python and sends a mock order confirmation. checkoutservice is Go and orchestrates payment, shipping and email after retrieving the cart. recommendationservice is Python. adservice is Java and returns text ads from context words. loadgenerator is Python with Locust and continuously sends requests that imitate realistic shopping flows to the frontend.

The practical consequence is a dependency chain rather than a flat set of services. A checkout request fans out through checkoutservice into payment, shipping and email, so a failure in any of those three surfaces as a checkout failure. Anyone using this for chaos testing should start there, because that path exercises four services and three languages in a single user action.

Installing Online Boutique on GKE and Seeing the Storefront

The README's quickstart targets GKE and assumes gcloud, git and kubectl are present, plus a Google Cloud project. The first step clones the latest major version rather than the default branch, and the --depth 1 flag skips git history, which keeps the download small.

git clone --depth 1 --branch v0 https://github.com/GoogleCloudPlatform/microservices-demo.git
cd microservices-demo/

Next, export the project ID and region and enable the Kubernetes Engine API. The README uses us-central1 as the example region and substitutes <PROJECT_ID> with the ID of your Google Cloud project.

export PROJECT_ID=<PROJECT_ID>
export REGION=us-central1
gcloud services enable container.googleapis.com \
  --project=${PROJECT_ID}

Then create an autopilot cluster and fetch its credentials. The README notes that creating the cluster may take a few minutes.

gcloud container clusters create-auto online-boutique \
  --project=${PROJECT_ID} --region=${REGION} \
  --labels dev-tutorial=online-boutique

Deployment is a single apply against the release manifests, followed by a pod listing. After a few minutes the README says you should see the Pods in a Running state, and it shows a sample listing with one Pod each for adservice, cartservice, checkoutservice, currencyservice, emailservice, frontend, loadgenerator and paymentservice. Note that loadgenerator is part of that default set, so the cluster begins receiving simulated shopping traffic as soon as the Pod is up.

kubectl apply -f ./release/kubernetes-manifests.yaml
kubectl get pods

The repository also ships helm-chart/, kustomize/, istio-manifests/, skaffold.yaml and terraform/ directories at the top level, so the single-manifest path is one of several deployment routes rather than the only one. The homepage listed for the project is a hosted instance, which is the fastest way to look at the UI before spending time on a cluster.

Where Online Boutique Stops Being the Right Tool

The mock services are the clearest boundary. paymentservice charges mock credit card info and returns a transaction ID; shippingservice ships items to the given address as a mock; emailservice sends a mock confirmation. None of these integrate with a real payment processor, carrier or mail provider, and the README presents them that way rather than as stubs to be swapped. If your goal is to evaluate payment integration or order fulfillment logic, this application gives you nothing to evaluate.

Authentication is absent by design. The frontend does not require signup or login and generates session IDs for all users automatically. Any work on identity, session persistence across devices, or access control has no surface here.

productcatalogservice reads products from a JSON file. That means the catalog is static, and there is no admin path, no inventory decrement, and no write API for products. A project that needs to test catalog ingestion or stock reconciliation will have to add that service itself.

Finally, the demo runs a load generator by default. On a shared or cost-sensitive cluster, a workload that continuously sends shopping traffic is a liability rather than a feature, and the README's quickstart does not call out how to leave it out. The manifests are in the repository, so the decision is yours to make before applying them.

How It Compares with Sock Shop and the OpenTelemetry Demo

Sock Shop is the closest analogue: a polyglot microservices retail demo, also built for demonstrating service discovery, tracing and container orchestration. The difference in approach shows up in the interface layer. Online Boutique's services talk over gRPC with Protocol Buffers definitions checked into ./protos, which makes the contract explicit and typed, and the README frames the project around gRPC, Istio and Kubernetes together. Sock Shop's services are largely REST over HTTP, which is easier to poke at with curl but gives you no generated client and no schema to read. If your interest is gRPC tooling, streaming, or proto-driven code generation, Online Boutique is the more direct fit.

Against the OpenTelemetry Demo, the split is about what is being demonstrated. That project exists to show tracing and metrics instrumentation across many languages, and its services are built around emitting telemetry. Online Boutique's README positions it around Google Cloud products, GKE, Cloud Service Mesh and gRPC, with telemetry as one of several concerns. Someone whose only goal is to see spans flow through a collector will find the OpenTelemetry Demo more focused; someone who wants a mesh and gRPC topology with a shopping UI on top will find Online Boutique closer to the mark.

Licence, Maintenance and the Cost of Upgrading

The repository is licensed under Apache-2.0, which permits commercial use, modification and redistribution provided the licence terms are met. That is a permissive arrangement, and it matters here because the natural use of a demo is to fork it, strip the parts you do not want, and adapt the manifests. Apache-2.0 also includes a patent grant, which some permissive licences do not. This is a description of the licence text, not legal advice; a legal review is the only way to settle obligations for a specific product.

The last push to the default branch was on 2026-09-19, two days before this writing, and the most recent release is v0.10.7 from 2026-09-18. The release cadence visible in the recent list is uneven: v0.10.6 landed on 2026-07-13 and v0.10.5 on 2026-03-11. That pattern suggests bursts of activity rather than a steady drip, which is normal for a sample tied to conference talks and documentation refreshes.

Upgrade cost is dominated by the manifests rather than the code. Because deployment runs through release/kubernetes-manifests.yaml, a fork that edits that file in place will conflict on every upstream change. The kustomize/ and helm-chart/ directories exist precisely so overlays can sit outside the base, and using them is the cheaper path over a year of releases. The terraform/ directory has the same property: infrastructure definitions that are copied rather than referenced will drift.

Editorial conclusion

Adopt it if you need a multi-language gRPC application to exercise a Kubernetes cluster, a service mesh, or a CI pipeline, and you are comfortable that its services are mocks. Skip it if you want a production commerce base: the payment, shipping and email services are explicitly mock implementations, and the frontend has no signup or login. Before deploying, read release/kubernetes-manifests.yaml and decide whether the bundled loadgenerator should run at all, since it starts sending traffic as soon as the Pod is Running.

Frequently asked questions

Official sources

1. GoogleCloudPlatform/microservices-demo on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases