Solution Pattern: Comprehensive Service Architecture with API Management and Service Mesh

API-centric and microservices-based IT architectures improve speed, agility, and efficiency. Consistent and effective management of these interfaces and services is critical for successful deployment and use. Most organizations look for either an API management or a service mesh solution to accomplish this. Determining which approaches and tools to use within your organization can be confusing. However these two technologies are actually complementary and can be used together to deliver a complete service management architecture.

This solution pattern helps you understand how to use these solutions together to setup a comprehensive service management architecture.

1. Use cases

App modernization resulting in cloud-native technologies need a way to manage their services. Service mesh provides well defined management of service-service communication.

Organizations are implementing strategies to manage their APIs so they can respond to rapid changes in customer demands. An API management solution allows secure access to their services and APIs, so that the internal teams and external partners and clients can access these APIs in structured way.

As you can see, organizations have a need for both of these technologies.

Red Hat OpenShift Service Mesh and Red Hat 3scale API Management make it easy for these solutions to work with each other to help organizations build a comprehensive services archiecture

Some of the benefits are

  • increased observability and tracing across the services, standardize the security across services so that dev teams can manage microservices more easily

  • formalizing inter-service communication in large corporate networks with api contracts

  • provide access to external partners, clients and developers who want to build value added services on top of existing offering. Build a self sign up workflow o obtain credentials, add usage limits to the API based on the business contract and monitor the usage by the external clients.

  • enable secure access to apps outside the service mesh

  • intelligent traffic routing to the services and APIs based on the application accessing them

Table 1. A quick refresher
API Management Service Mesh

(a) manages relationship between service (API) providers and service consumers

(a) delivers advanced traffic control, security, resilience and observability for cloud-native apps

(b) securely exposes services to external clients or other Business Unit within the same enterprise (also called North-South or Inter Domain)

(b) enables the standardization across the service interactions (also called East-West or Intra domain)

(c) ideal for teams that want to deliver services beyond their domain to other internal groups or external users.

(c) ideal for development teams that need to access services through network interfaces and protocols.

2. The story behind this solution pattern

Travelz is a fictitious travel booking company. The team has built their application using microservices architecture and and the portal runs on Red Hat OpenShift.

The Travelz application has two business units responsible for different aspects of the travel booking system.

  • The travel-portal business unit is responsible for several travel shops, where users can search for and book flights, hotels, cars or insurance.

  • The travel-agency business unit host a set of services created to provide quotes for travel.

With the growing number of microservices, the team needed a way to manage, secure and control how the services talk to each other. Service Mesh is identified as great fit for this purpose

As the company grew, they plan to share their APIs with other internal LOBs and external partners. The internal and external clients' applications would need to access data and booking related information from Travelz microservices in the form of APIs. The Engineering teams now needed to ensure that they give secure access to their APIs externally and also manage and monitor the usage of these APIs to make sure everything is in line with the business agreements put in place.

Travelz would like to allow for travel aggregators to be able to display flights, hotels, insurance cars details. They would like to track any calls from these external clients and partners so as to identify the traffic generated by those teams. This would allow Travelz to be able to reward the partners based on the traffic. They would also these external partners to be able to sign up for services by themselves

2.1. Introducing new requirements

Below are the set of key requirements for the development teams to tackle:

  • Leverage Service Mesh for Intra Domain or East-West communication

  • Ensure a secure and standardized communication across microservices

  • Share APIs securely with other orgs or external partners and monitor them - Inter Domain or North-South

  • Launch a new version of a service and move it to deployment in Canary style

3. Technical Overview

To connect, manage and observe the microservices, and control traffic between service-to-service, Travelz decided to adopt Istio based service mesh.
With Red Hat OpenShift Service Mesh, the team was able to provides the necessary service-to-service capabilities — traffic monitoring, access control, discovery, security, resiliency, metrics, and more — without requiring changes to the code of any of the app’s microservices.

With the introduction of external clients, there is a need to allow access of these services by other partners, clients and even other BUs. Red Hat® 3scale API Management makes it easy to manage, share, publish, secure and monetize these services as APIs.

The Red Hat 3scale Istio plugin can connect with Red Hat 3scale API management to authorize API requests and report use. This integration allows you to efficiently set up an API with a service mesh backend.