Building an Istio service mesh for a microservices application deployed on Kubernetes


This code pattern focuses on deploying a travel booking microservices application to Kubernetes and creating a service mesh with Istio. Kubernetes allows for containerization of the application and Istio provides a means to connect, control, and monitor the microservice interactions across containers.


Bee Travels is a conceptual travel booking web application designed to demonstrate a microservices architecture. With microservices, you can break up an application into smaller, independent services that can be developed, deployed, and maintained individually. This separation provides many advantages including targeted scalability, improved fault isolation, and use of a customizable technology stack. However, microservices can be difficult to manage without a service mesh.

Istio is an open source, service mesh platform that provides a way to connect, control, and monitor microservice interactions. The service mesh takes care of traffic management after the rules are configured and provides mesh observability through the telemetry it collects.

This code pattern focuses on the following five microservices of the Bee Travels application:

  • UI
  • Destination
  • Hotel
  • Car rental
  • Currency exchange

Currently, there are three versions of the application. Version 1 stores destination, hotel, and car rental data locally in JSON files. Version 2 stores data in an in-cluster MongoDB deployment. Version 3 connects to the IBM Cloud Databases for MongoDB service. In this code pattern, you route and shift traffic to specific versions of the services, and observe the traces and metrics to analyze latency.


Bee Travels Istio service mesh architecture flow diagram

  • (1) User accesses front-end UI service through an Istio Ingress Gateway (an instance of the Envoy proxy).
  • (2 – 4) The UI service routes calls to the hotel, car rental, and destination services. Istio rules the mediate traffic and directs it to version 1, version 2, or version 3 of the services depending on the Istio routing weights. Version 1 services store data in memory.
  • (5) The UI service calls the currency conversion service (only one version).
  • (6) Version 2 of each service uses an in-cluster instance of MongoDB.
  • (7) Version 3 of each service uses a MongoDB instance on IBM Cloud.


The detailed steps for this pattern are available in the README file. The steps show you how to:

  1. Complete the prerequisite IBM Cloud set-up.
  2. Clone the repository.
  3. Deploy the application to Kubernetes.
  4. Configure the Istio service mesh.