Link distributed services across OpenShift clusters using Red Hat Service Interconnect

In this activity, you will connect services distributed across multiple OpenShift clusters using Red Hat Service Interconnect to establish a Virtual Applications Network, also known as a service network. This involves using straightforward Kubernetes annotations to manage which services are securely exposed over the network. This method enables you to seamlessly leverage your existing GitOps workflow for service management.

Overview: Link distributed services across OpenShift clusters using Red Hat Service Interconnect

Introduction

This learning path introduces you to Red Hat Service Interconnect, which is based on the open source Skupper project. Using Service Interconnect, you can create a virtual applications network, known as a service networks, as well as connections across multiple clouds. Service Interconnect enables application and service connectivity across different environments through Layer-7 addressing and routing.

Using a simple command-line interface (CLI), you can able to create interconnections in a matter of minutes, which helps you avoid extensive networking, planning, and overhead. In addition, all of the interconnections you create between environments employ mutual TLS (mTLS) to keep your organizational infrastructure and data protected.

What you need before you start

In order to get the full benefits of taking this lesson, you need to have:

  • An active Red Hat Developer Sandbox account. Use these instructions to set up your sandbox if you haven't already. We will use this as our public cluster to deploy the front end.
  • Access to another already provisioned OpenShift environment from the Red Hat OpenShift Playground lab as your second cluster, or you can deploy the other OpenShift cluster using any environment of your choice (AWS, Azure, local). We will use this as our private cluster to deploy the database and payment processor.

What you'll be doing

  • In this learning path, you will discover how to build a service network to connect disparate services across different environments using Red Hat Service Interconnect.

How long will this activity take?

  • About 45 minutes.

Overview

During this learning path, you are going to learn how to build a simple, database-backed, patient portal web application using Red Hat Service Interconnect that contains three services:

  • Public Cluster - A web front-end service running on the Developer Sandbox for Red Hat OpenShift in the public cloud. The service uses the PostgreSQL database and a payment processor deployed in a private cluster to display the names of doctors and patients and process the payments.

  • Private Cluster - A PostgreSQL database and a payment processor running on a private Openshift cluster. 

Your challenge

The challenge for you will be to enable a patient portal application to connect to a database and a payment processor. For obvious reasons, you do not want to expose the database and payment processor over the public internet. That means you need to set up a private, secure link between the Red Hat OpenShift instance on the public cloud and the private cloud, which you can accomplish with a Virtual Private Network (VPN) between the public cloud and the data center.

However, a VPN is sometimes hard to set up and often requires deep networking expertise, a request to the network administrators, and a time-taking approval process for the VPNs to be set up.

With Service Interconnect, on the other hand, you can create a dedicated, Layer-7 service network, and it's a lot easier to set up. The Layer-7 service network allows you as an application developer to establish secure interconnection with other services and applications in different environments without relying on network specialists.

As shown in Figure 1, Service Interconnect helps you create secure virtual application networks without the cumbersome overhead, complexity and delays of traditional connectivity solutions.

A diagram of the connection between Public and Private Clusters.
Figure 1: A diagram of the connection between Public and Private Clusters.