Microservices with the OpenShift Service Mesh

Summary

This code pattern shows how to deploy a service mesh for a simulated, interactive mobile phone application by using Red Hat® OpenShift® Service Mesh. The examples are shown in Red Hat OpenShift on IBM Cloud™.

Description

Building secure applications that ensure data privacy and security when deployed to a cloud environment is crucial for businesses that collect customer data, particularly for regulated industries like finance, retail, and banking. With the move toward microservice architectures and containerization, technology such as service mesh may be useful in the context of a data privacy service.

The OpenShift Service Mesh is a layer built on top of Istio, based on the Maistra Istio Operator. This code pattern shows how to modify deployment scripts, Dockerfiles, and network policies to allow the microservice-based mobile bank app to work with an Istio service mesh. Although the primary goal is to have security provided by mTLS between services and via the Istio Ingress Gateway, after Istio is configured, you gain the flexibility of its traffic management and security policies. In this example, you install OpenShift Service Mesh and configure the Example Bank project to use mutual TLS between services. Once inside the Istio mesh, you can also take advantage of its traffic management, telemetry, and observability features.

Flow

The following diagram shows the architecture flow of the service mesh for the Example Bank mobile application, which includes several microservices for handling user authentication and transaction mechanics.

Service mesh architecture flow diagram

  1. The user connects to the OpenShift router via HTTPS, which forwards the request to the Istio Ingress Gateway, an Envoy instance.
  2. Envoy forwards the request, using gateway and virtual service rules, to the Node.js service, which validates user accounts with App ID.
  3. Traffic rules inside the service mesh are set up such that all traffic is intercepted by the Istio Proxy, which enforces security between services. Communication flows between the Node.js service, the Java Transaction service and the Java User management service via mTLS connections proxied by Envoy.
  4. The user, transaction, and cleanup services all communicate with the PostgreSQL database inside the cluster. The database itself is also running inside a pod with a proxy container, allowing security and filter rules to be used for database access.
  5. The Java erasure service runs once every 24 hours, removing users from App ID. In the Istio environment, jobs like this need to have a delay to wait until the Envoy proxy starts up and is receiving traffic. Learn more about how this is accomplished.

Instructions

To try out this code pattern, see the detailed technical steps in the GitHub repository.

  1. Deploy services using the Example Bank code pattern.
  2. Install the OpenShift Service Mesh Operator.
  3. Create the Control Plane and Member Roll instances.
  4. Check out the service mesh-enabled branch.
  5. Review and apply the changes.

Next steps

Use the open source code and instructions in the following content to understand the steps we followed to build the Example Bank application with OpenShift 4.3: