Eleven services make a teaching system, not a shop foundation
Online Boutique connects 11 microservices over gRPC and wraps them in a store you can click through. A browser request can cross a Go frontend, a C# cart, Node.js currency and payment services, Python recommendation and email services, and a Java ad service. That variety gives a platform workshop enough seams to demonstrate tracing, service discovery, deployment policy, and a failure in one dependency. It also gives a new contributor five language ecosystems to understand.
The store boundary matters more than the polished screenshot. The project README says the frontend creates sessions automatically and has no signup or login. Payment, shipping, and email are mocks. Product data starts in a JSON file, while the currency service fetches real rates. Those choices are sensible for a disposable demo, but they leave out identity, order durability, refunds, fraud checks, and the other work that makes commerce software costly.
The 11-service design gives platform tools something real to touch
A single toy API cannot show a useful service mesh. Online Boutique has 11 core services, Protocol Buffer contracts, a Redis-backed cart, a load generator, and a checkout service that coordinates several downstream calls. The repository also includes Kubernetes manifests, Helm and Terraform paths, plus Kustomize variations for concerns such as a service mesh and Google Cloud operations. You can change infrastructure behavior while keeping the visible shopping flow recognizable.
The breadth is also the tax. Go, C#, Node.js, Python, and Java each bring their own dependency and build conventions. A lesson about one failed request may cross several runtimes before it reaches the browser. That is useful when the subject is platform engineering. It is wasteful when you only need a short gRPC example or a starter for one service. The repository should be treated as a system to operate, not a library to import.
What happened when we ran it
Our run at commit 38e7348 focused on ./src/checkoutservice/ inside a fresh Debian container with 3 CPUs and 8 GB of RAM. Installation succeeded in 23 seconds and pulled 229 packages. The checkout service built successfully in 36 seconds. The full checkout was 12.7 MB with 364 files and about 24,093 lines of source, while our scan found 9 CI workflow files and a Dockerfile.
The test step failed after 11 seconds, with 2 checks passing and 3 failing out of 5. Go reported main.go:240:45: non-constant format string in call to google.golang.org/grpc/status.Errorf, then marked the checkout service package as a build failure. The money package passed in 0.008 seconds. That log supports a narrow conclusion: the tested checkout commit did not clear its Go test command in our sandbox. It does not explain why the offending call remained in the release.
Our test method did not start a Kubernetes cluster, build every service, or send a purchase through the deployed shop. It measured the Go checkout project named in the lab target. The passing 36-second build therefore should not be read as proof that all 11 containers, the Redis deployment, and every optional overlay work together on a new cluster. Those are separate checks for your own environment.
Local deployment asks for 32 GB of disk and Kubernetes
The development guide asks Minikube users for at least 4 CPUs, 4 GiB of memory, and 32 GB of disk. Docker Desktop users are told to allocate at least 3 CPUs, 6 GiB of memory, and the same 32 GB. Skaffold builds and deploys the images, and the guide warns that its first local run can take about 20 minutes. This is a realistic lab allocation, not a tiny sample you start with one binary.
The GKE quick start trades local capacity for cloud setup. You need a Google Cloud project, gcloud, kubectl, an enabled GKE API, a cluster, and its credentials. Development builds add Artifact Registry configuration. The default application can run on any Kubernetes cluster, but several documented variations demonstrate Google products. Budget both cloud charges and cleanup time, then delete the cluster when the exercise ends.
September 2026 activity supports teaching, not production reuse
GitHub recorded the last push on September 19, 2026, one day after release v0.10.7. The repository had 21,002 stars, 71 combined issues and pull requests, and 40 open issues when fetched. Release v0.10.7 consisted of more than 42 dependency updates, including fixes and security patches. That is active maintenance, and the open dependency dashboard shows automated updates across the many runtimes.
Maintenance cannot change the project's purpose. Online Boutique is a well supplied target for Kubernetes classes, SRE exercises, and vendor demonstrations because its 11 services create enough operational behavior to inspect. Our failed checkout tests are a reason to pin a commit and run the checks before a workshop. The mock business functions are a stronger reason to stop there: learn from the deployment, then build real commerce requirements somewhere else.