Online Boutique: la demo Kubernetes de Google para DevOps

En pocas palabras: Es la demo de microservicios Online Boutique de Google Cloud, lanzada en 2020, con 11 servicios en Go, Python, Java, C# y Node.js corriendo sobre Kubernetes. Sirve para armar un portfolio DevOps real, probar service mesh y CI/CD en cloud-native.

Google mantiene en GitHub el código de Online Boutique, una demo de microservicios que corre sobre Kubernetes y que en 2026 sigue siendo el proyecto de referencia para entrevistas DevOps, workshops corporativos y portfolios. Son 11 microservicios reales que simulan una tienda online con frontend, carrito, checkout, catálogo, envíos y hasta un motor de recomendaciones (sí, en serio, incluye un motor de recomendaciones), todo desplegable con un par de comandos kubectl. Si estás buscando un proyecto para ensuciarte las manos con cloud-native, este es.

Online Boutique es una aplicación de ejemplo de Google Cloud Platform que implementa un ecommerce con arquitectura de microservicios sobre Kubernetes. Usa 11 servicios escritos en Go, Python, Java, C# y Node.js, comunicados por gRPC y HTTP, y está pensada para demostrar patrones de service mesh, observabilidad, CI/CD y escalado en entornos cloud-native.

En 30 segundos

  • Google Cloud liberó Online Boutique, una demo de 11 microservicios que corre sobre Kubernetes, ideal para practicar DevOps y cloud-native.
  • El proyecto es open source y está en GitHub desde 2018, pero en 2026 sigue siendo el estándar para workshops oficiales de Google Cloud.
  • Incluye frontend, backend, base de datos, motor de recomendaciones y está preparado para Istio, Prometheus, Grafana y CI/CD con Cloud Build o GitHub Actions.
  • Se despliega con un simple kubectl apply y funciona en cualquier clúster Kubernetes, desde GKE hasta minikube o kind en tu máquina local.

¿Qué es Online Boutique y para qué sirve en Kubernetes?

Online Boutique es, en criollo, un ecommerce de juguete que Google armó para que puedas probar todas las herramientas del ecosistema Kubernetes sin arriesgar un sistema real. La aplicación vende productos de mentira como velas aromáticas, tazas y remeras (todo ficticio, obvio), pero la arquitectura es 100% profesional: 11 microservicios independientes, cada uno en su propio contenedor, comunicándose por gRPC y HTTP, con base de datos, caché y cola de mensajes.

El punto fuerte de Online Boutique es que no es un “hola mundo” con dos pods. Acá tenés servicios que llaman a otros servicios, que dependen de una base de datos, que fallan si configuraste mal el service mesh. Es el tipo de complejidad que te encontrás en un laburo real, pero empaquetada para que puedas romper todo sin consecuencias. Ya lo cubrimos antes en integración de la API de Google Gemini.

¿Qué microservicios incluye la demo de Online Boutique?

Según el repositorio oficial en GitHub, Online Boutique tiene 11 microservicios. Cada uno está escrito en un lenguaje distinto a propósito, para que practiques con polyglot persistence y comunicación entre servicios heterogéneos.

  • Frontend: la interfaz web en React, el punto de entrada para los usuarios. Corre en Go.
  • Cart Service: maneja el carrito de compras. Escrito en C#.
  • Product Catalog Service: el catálogo de productos. Go.
  • Currency Service: convierte monedas. Python.
  • Payment Service: procesa pagos (simulados, no te emociones). JavaScript/Node.js.
  • Shipping Service: calcula envíos. Go.
  • Email Service: manda correos de confirmación. Python.
  • Checkout Service: orquesta la compra. Go.
  • Recommendation Service: te sugiere productos basados en el historial. Python.
  • Ad Service: publicidad contextual. Java.
  • Redis: caché para el carrito.

El flujo es más o menos así: entrás al frontend, elegís productos del catálogo, los metés en el carrito que se guarda en Redis, y cuando hacés checkout el checkout service llama al payment service, al shipping service y al email service en secuencia, mientras el recommendation service te tira sugerencias basadas en lo que llevás, todo con tracing distribuido y métricas expuestas para Prometheus.

Requisitos para desplegar Online Boutique en tu clúster Kubernetes

No necesitás mucho. Según el README del repo, los requisitos son:

  • Un clúster Kubernetes: puede ser GKE, EKS, AKS, minikube o kind. Con 4 vCPUs y 8 GB de RAM alcanza para correr todos los servicios.
  • kubectl configurado contra tu clúster.
  • Istio (opcional pero recomendado): si querés probar service mesh, traffic splitting y fault injection.
  • Helm (opcional): hay charts disponibles en el repo.

Si estás en Argentina y querés probar con un VPS barato para armar tu clúster, podés usar donweb.com para levantar un par de máquinas virtuales y correr k3s o microk8s. No es necesario que contrates un clúster gestionado de GKE para hacer las pruebas.

Cómo instalar Online Boutique paso a paso

El despliegue base es bastante simple. Clonás el repo, aplicás los manifiestos y en unos minutos tenés la tienda corriendo.

  • Cloná el repo: git clone https://github.com/GoogleCloudPlatform/microservices-demo.git
  • Entrá al directorio: cd microservices-demo
  • Aplicá los manifiestos: kubectl apply -f ./release/kubernetes-manifests.yaml
  • Verificá los pods: kubectl get pods (deberías ver 11 pods en Running después de un par de minutos).
  • Exponé el frontend: kubectl port-forward svc/frontend 8080:80 y abrí http://localhost:8080 en el navegador.

¿Y si querés Istio? El repo incluye manifiestos separados en ./istio-manifests/. Aplicás esos en lugar de los kubernetes-manifests.yaml y listo. Lo interesante es que podés jugar con fault injection, delays y circuit breaking sin tocar una línea de código de la aplicación.

¿Cómo adaptar Online Boutique para tu portfolio DevOps?

Acá viene lo bueno. El repo base ya es un proyecto sólido para mostrar, pero si lo dejás tal cual, el recruiter va a ver que hiciste un copy-paste del README oficial. La clave está en las adaptaciones que hagas. Lo explicamos a fondo en guía sobre DNS autoritativos.

Lo que más valora un recruiter en 2026, según charlas con colegas del palo, es que demuestres que entendiste la arquitectura y que podés operarla, no solo desplegarla. Ponele que cambiás los colores y el logo del frontend (son variables de entorno en el deployment.yaml), añadís un pipeline de CI/CD con GitHub Actions que corra tests de integración antes de deployar a staging, documentás todo en un README con diagramas de arquitectura hechos en Mermaid, y configurás alertas en Prometheus para cuando el checkout service tiene latencia alta. Eso es lo que vende.

  • Cambiá la imagen de marca: modificá las variables de entorno FRONTEND_COLOR y FRONTEND_LOGO en el deployment del frontend.
  • Agregá CI/CD: el repo viene con un cloudbuild.yaml de ejemplo para Google Cloud Build, pero podés portarlo a GitHub Actions o GitLab CI.
  • Documentá en tu README: diagrama de arquitectura, decisiones de diseño, cómo escalar servicios, cómo agregar un nuevo microservicio.
  • Integrá herramientas de observabilidad: Prometheus, Grafana, Jaeger para tracing distribuido.
  • Escribí tests de integración: el repo incluye algunos tests en Python, pero podés expandirlos.

Casos de uso reales: empresas que usan Online Boutique para formación

Según el blog oficial de Google Cloud, Online Boutique es el proyecto estrella en los workshops presenciales de Google Cloud y en el curso “Cloud Architecture” de su plataforma de formación. No es un proyecto de juguete que alguien subió un fin de semana: es material oficial de entrenamiento.

Google lo usa para enseñar patrones como circuit breaking, deployments canary, blue/green, y observabilidad con Cloud Operations. También aparece en las certificaciones de Cloud Architect y Cloud DevOps Engineer. Si Google lo usa para entrenar a sus propios clientes enterprise, es porque la arquitectura tiene suficiente chicha como para simular un entorno real.

Ojo: fuera de Google, algunas consultoras latinoamericanas también lo adoptaron para sus bootcamps de DevOps. No tengo cifras oficiales de adopción, pero en comunidades como Kubernetes Argentina y DevOps LATAM se menciona seguido como proyecto de práctica recomendado.

Errores comunes al desplegar Online Boutique por primera vez

Habiendo ayudado a varios colegas a desplegar esto, acá van los tropiezos más frecuentes y cómo solucionarlos: Sobre eso hablamos en comparativa de pipelines CI/CD.

  • Falta de recursos en el clúster: si estás en minikube con 2 GB de RAM, los pods van a quedar en Pending o CrashLoopBackOff. Necesitás al menos 8 GB para que los 11 servicios corran sin problemas. Solución: aumentá los recursos de tu máquina virtual o usá kind con un nodo más grande.
  • Puertos conflictivos: el frontend usa el puerto 80, y si ya tenés algo corriendo ahí, vas a tener problemas. Solución: cambiá el puerto en el servicio o usá port-forward a un puerto distinto, tipo 8080:80.
  • Errores de conexión entre servicios: si desplegaste sin Istio y los servicios no se encuentran, probablemente no configuraste bien los servicios Kubernetes. Solución: verificá que los ClusterIP services estén creados y que los selectors matcheen con los labels de los pods.
  • No esperar a que los pods estén listos: algunos servicios tardan en inicializar porque dependen de Redis o de otros servicios. Si hacés port-forward apenas aplicás los manifiestos, vas a ver errores 500. Solución: esperá 2-3 minutos y verificá con kubectl get pods que todos estén Running.

Tabla comparativa: Online Boutique vs otros demos de microservicios

No es el único proyecto de este tipo. Acá una comparación con otras opciones que también andan dando vueltas en GitHub:

CaracterísticaOnline Boutique (Google)Sock Shop (Weaveworks)Hipster Shop (Google, legacy)
Microservicios11710
LenguajesGo, Python, Java, C#, Node.jsGo, Java, Node.jsGo, Python, Java, Node.js
Service MeshIstio nativoIstio, LinkerdSin soporte nativo
ObservabilidadPrometheus, Grafana, JaegerPrometheus, ZipkinStackdriver
CI/CD incluidoCloud Build, GitHub ActionsNoNo
Estado en 2026Activo, mantenidoArchivado en 2023Deprecado, redirige a Online Boutique
online boutique demo kubernetes diagrama explicativo

La conclusión es bastante obvia: Online Boutique es el proyecto que Google mantiene activo y que recomienda oficialmente. Sock Shop fue muy popular en su momento, pero Weaveworks cerró en 2024 y el repo quedó archivado. Hipster Shop era la versión anterior de Online Boutique, y el repo redirige a este. Así que si estás arrancando en 2026, no te compliques: Online Boutique es el camino.

Preguntas Frecuentes

¿Online Boutique es gratuito?

Sí, es completamente open source bajo licencia Apache 2.0. Podés clonarlo, modificarlo, usarlo en tu portfolio y hasta en proyectos comerciales sin pagar un peso.

¿Qué necesito para correr Online Boutique en mi máquina?

Un clúster Kubernetes local como minikube o kind, kubectl instalado y al menos 8 GB de RAM disponibles. Con eso alcanza para desplegar los 11 microservicios y probar la aplicación completa. Más contexto en precios de Cloud SQL PostgreSQL.

¿Online Boutique sirve para entrevistas de DevOps?

Sí, y mucho. Los recruiters técnicos ya conocen este proyecto y valoran que hayas ido más allá del despliegue básico: agregar CI/CD, observabilidad, tests y documentación propia demuestra que entendés el ciclo de vida completo de una aplicación cloud-native.

¿Online Boutique soporta Istio?

Sí, el repo incluye manifiestos específicos para Istio en el directorio ./istio-manifests/. Podés probar traffic splitting, fault injection, circuit breaking y otras funcionalidades de service mesh sin tocar el código de la aplicación.

¿Cómo monitoreo Online Boutique con Prometheus?

Los microservicios ya exponen métricas en formato Prometheus. Solo necesitás desplegar Prometheus y Grafana en tu clúster y configurar los scrape targets. El repo incluye dashboards de Grafana preconfigurados para que veas latencias, tasas de error y tráfico entre servicios.

Conclusión

Online Boutique no es un proyecto nuevo, pero en 2026 sigue siendo la mejor opción para practicar microservicios en Kubernetes porque es mantenido, tiene una arquitectura realista y está respaldado por Google Cloud como material oficial de formación. Si estás armando tu portfolio DevOps o preparándote para una certificación, no hay mucho que pensar: cloná el repo, desplegalo en tu clúster, rompelo, arreglalo y documentá todo el proceso.

Lo que diferencia a un candidato promedio de uno que destaca es justamente lo que hagas después del kubectl apply. El deploy base lo hace cualquiera en 10 minutos. La magia está en el pipeline de CI/CD que armaste, en el dashboard de Grafana que configuraste, en el README que explica las decisiones de arquitectura. Eso es lo que te va a dar la ventaja en una entrevista.

Fuentes

Te puede interesar...