Skip to content

Latest commit

 

History

History
150 lines (113 loc) · 9.28 KB

README.md

File metadata and controls

150 lines (113 loc) · 9.28 KB
Raw

Online Boutique is a cloud-native microservices demo application. Online Boutique consists of a 10-tier microservices application, writen in 5 different languages: Go, Java, .NET, Node, and Python. The application is a web-based e-commerce platform where users can browse items, add them to a cart, and purchase them.

Honeycomb uses this application to demonstrate use of technologies like Kubernetes, gRPC, and OpenTelemetry. This application works on any Kubernetes cluster. It’s easy to deploy with little to no configuration.

OpenTelemetry

Online Boutique is instrumented using the OpenTelemetry framework. There are simple and advanced instrumentation techniques offered by OpenTelemetry that are leveraged in the application. Each service in the src folder explains how OpenTelemetry was used with specific code examples.

Table of Contents

Development

Prerequisites

Kubernetes Quickstart

  1. Launch Kubernetes cluster with Docker Desktop or Minikube:

    1. Launch Docker Desktop. Go to Preferences:
      • choose “Enable Kubernetes”,
      • set CPUs to at least 3, and Memory to at least 6.0 GiB
      • on the "Disk" tab, set at least 32 GB disk space
    2. To launch Minikube (tested with Ubuntu Linux). Please, ensure that the local Kubernetes cluster has at least:
      • 4 CPUs
      • 4.0 GiB memory
      • 32 GB disk space
      minikube start --cpus=4 --memory 4096 --disk-size 32g

  2. Run kubectl get nodes to verify you're connected to the respective control plane.

  3. Add your Honeycomb API key as a secret from the command line. Replace $HONEYCOMB_API_KEY with your actual API key. For example, if your API key is abc123, run the following command:

export HONEYCOMB_API_KEY=abc123
kubectl create secret generic honeycomb --from-literal=api-key=$HONEYCOMB_API_KEY
  1. Install the OpenTelemetry Collector Helm chart.
helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts

helm install opentelemetry-collector open-telemetry/opentelemetry-collector \
   --set mode=deployment \
   --set image.repository="otel/opentelemetry-collector-k8s" \
 --values ./kubernetes-manifests/additional_resources/opentelemetry-collector-values.yaml

  1. Run skaffold run (Note: first time will be slow, it can take ~20 minutes). This will build and deploy the application. If you need to rebuild the images automatically as you refactor the code, run skaffold dev command.

  2. Run kubectl get pods to verify the Pods are ready and running.

  3. Access the web frontend through your browser.

    1. Docker For Desktop should automatically provide the frontend at http://localhost:80
    2. Minikube will require you to run minikube service frontend-external to access the frontend.

Cleanup

If you've deployed the application with skaffold run command, you can run skaffold delete to clean up the deployed resources.

Architecture

Online Boutique is composed of 10 microservices (plus a load generator) written in 5 different languages that communicate with each other over gRPC.

Architecture of microservices

Find Protocol Buffers Descriptions at the ./pb directory.

Service Language Description
adservice Java Provides text ads based on given context words.
cartservice C# Stores the items in the user's shopping cart in Redis and retrieves it.
checkoutservice Go Retrieves user cart, prepares order and orchestrates the payment, shipping and the email notification.
currencyservice Node.js Converts one money amount to another currency. Uses real values fetched from European Central Bank. It's the highest QPS service.
emailservice Python Sends users an order confirmation email (mock).
frontend Go Exposes an HTTP server to serve the website. Does not require signup/login and generates session IDs for all users automatically.
loadgenerator Python/Locust Continuously sends requests imitating realistic user shopping flows to the frontend.
paymentservice Node.js Charges the given credit card info (mock) with the given amount and returns a transaction ID.
productcatalogservice Go Provides the list of products from a JSON file and ability to search products and get individual products.
recommendationservice Python Recommends other products based on what's given in the cart.
shippingservice Go Gives shipping cost estimates based on the shopping cart. Ships items to the given address (mock)

Features

  • Kubernetes: The app is designed to run on Kubernetes
  • gRPC: Microservices use a high volume of gRPC calls to communicate to each other.
  • OpenTelemetry Tracing: Most services are instrumented using OpenTelemetry trace providers for gRPC/HTTP.
  • Skaffold: Application is deployed to Kubernetes with a single command using Skaffold.
  • Synthetic Load Generation: The application demo comes with a background job that creates realistic usage patterns on the website using Locust load generator.

History

This project originated from the excellent Google Cloud Platform Microservices Demo. It was forked in 2021, before significant changes were performed. All application telemetry which was previously done with OpenCensus and Stackdriver, was moved to use OpenTelemetry for application telemetry, with tracing export intended for an OpenTelemetry Collector. Additional instrumentation is leveraged throughout the application to show some basic and advanced capabilities of OpenTelemetry. This application is used as a demo platform for the Honeycomb team, and many changes were made to the application code so it will break in ways that make for a more compelling demonstration of the Honeycomb platform.

Application demo

This application will exhibit a problem meant to be discovered with ease using the Honeycomb platform.

The checkout service has a memory leak, caused by an internal cache store. This service has tight Kubernetes pod/container memory limits, so the leak will cause out of memory crashes, resulting in a pod restart after approximately 4 hours. Code in the checkout service will introduce additional delays in the form of SQL calls under getDiscounts. The number of SQL calls made will increase as the cache size increases, creating exponentially increasing latency. There is additional code in the frontend service, which will introduce a specific userid (20109) after the cache limit from checkout has reached a specific threshold. This results in a pattern where a single user from a pool of thousands, receiving a bad experience that continues to get worse.

When using Honeycomb BubbleUp, and combined with the Honeycomb SLO feature, understanding the single user from the high cardinality pool of thousands of user ids is easy to do. Honeycomb allows the user to ask novel questions from the data, to quickly understand the memory leak and cache problem in code.

This is not an official Honeycomb or Google project.