Why service mesh and API management are better together

When it comes to managing microservices, the possibilities are truly endless with service mesh and API management. You might think service mesh and API management are competing technologies—however, they are actually complementary and can help revolutionize the way you manage and secure your microservices and APIs.

In this article, we will explore the benefits of using service mesh and API management together, using a fictitious travel company as an example. 

Service mesh versus API management

Service mesh is a dedicated infrastructure layer that gives you the power to manage and control communication between microservices, with features like traffic management, service discovery, load balancing, and security.

API management refers to the process for creating, publishing, and managing APIs that connect applications and data across the enterprise and across clouds. This approach lets you control access to your APIs with authentication, authorization, rate limiting, and monitoring.

Together, service mesh and API management can improve the reliability, scalability, security, and performance of your microservices and APIs, as we'll see in the following scenarios.

Example scenario

We will use a fictitious travel company, Travelz, to demonstrate the implementation of both service mesh and API management in different scenarios. The subsequent sections will highlight the company's challenges and goals and demonstrate how we can combine these technologies to achieve those goals.

About the Travelz application

The travel booking system has two business units that are responsible for different aspects of the travel experience. First is the travel portal business unit that offers multiple travel shops where you can easily search and book your travel.

The second business unit is the travel agency that hosts a set of services such as flights, cars, hotels, etc., designed to provide the travel quotes. The travel portal business unit makes calls to the travel agency services and APIs to provide the quotes.

Observability, traffic monitoring, and security

With the growing number of microservices, the team needed a way to manage, secure, and control how the services talk to each other. To connect, manage, and observe the microservices, and to control traffic between services, Travelz decided to adopt Istio-based Red Hat OpenShift Service Mesh.

With OpenShift Service Mesh, the team was able to provide 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. The architecture is shown in Figure 1.

Traffic routing and securing the APIs for external consumption

Travelz tourism becomes super popular, and now other travel portals want to partner with Travelz. The team aims to enforce these principles in their technology:

• Allow secure access to internal services to external partners and clients as APIs.
• APIs should be easy to find, understand, integrate with and adopt.

Travelz builds a new version of their travels service (v2), so their travel partners will access v2 while the internal platforms access v1.

Service mesh's intelligent traffic routing capabilities make it extremely easy to divert the traffic based on who is making the call (internal or external). Travelz IT leveraged service mesh's virtual service capability to achieve this. A virtual service defines a set of traffic routing rules and each routing rule defines matching criteria for the traffic. If the traffic is matched, then it is sent to a named destination service (or subset/version of it). Travelz IT built two different dedicated virtual services: one for external partners and the other for internal portals.

Managing external access

To manage access by the external partners, Travelz introduces the Red Hat 3scale API Management platform. They adopt a contract-first approach by creating OpenAPI specifications for their existing and new services before onboarding external clients. With the help of the Red Hat 3scale API Management platform, Travelz IT now manages partner access to their APIs in such a way that the partners can only access APIs that are protected by a user_key (see Figure 2). 3scale provides a developer portal out of the box for partner developers to discover, learn, test, and sign up for those APIs.

Before we jump into the next scenario, let’s talk about the concept of domain boundaries. This will help you understand and appreciate the next scenario better.

Domain boundaries

As we saw in the earlier two scenarios, traffic direction provides a straightforward guide for when to choose API management or service mesh solutions. It is almost tempting to say you should always choose API management for north-south (external) traffic and service mesh for east-west (internal) traffic.

However, most organizations are not so simple. Typical organizations contain multiple groups that create and manage their own services and interact with other teams and external parties. Domain boundaries can help you divide your organization into smaller, more manageable areas. Much as your enterprise boundary denotes the perimeter of your overall organization, domain boundaries designate the perimeters of groups within your organization. See Figure 3.

The same north-south and east-west traffic patterns that occur in relation to your enterprise boundary also apply to domain boundaries within your organization. As a result, you should generally choose API management for interdomain traffic and service meshes for intradomain traffic.

Figure 4 will help you better understand the nuances of interdomain versus intradomain traffic patterns.

Interdomain traffic crosses domain or enterprise boundaries to connect services with consumers beyond your group or team. Interdomain traffic follows north-south traffic patterns.

• Hierarchical 1:N connection structures
• Separate service providers and service consumers
• Requires authorization and authentication
• Formal use contracts needed
• Guided service discovery, accessible developer portal, and formal documentation

Intradomain traffic stays within domain and enterprise boundaries to link individual microservices. Intradomain traffic typically follows east-west traffic patterns.

• Non-hierarchical 1:1 connection structures
• Service providers and consumers within the same team
• Authentication required
• Implicit or informal contracts, if any
• Internal documentation within code

This is a great e-book if you are interested in more detailed information on this topic: Service mesh or API management? 

Standardizing API access for internal consumption and collaboration

With the above context, let’s see how that applies in our example. Travelz IT wants to standardize access of their core agency services for the internal platforms (think interdomain traffic), similar to how they did for external partners. Because all the services are already a part of Red Hat OpenShift Service Mesh, they leverage the seamless integration between OpenShift Service Mesh and Red Hat 3scale API management for this use case.

The WebAssembly extension that enables this is deployed as a sidecar to the microservices, and it communicates directly with the 3scale API manager. It eases the integration of OpenShift Service Mesh and 3scale, and authorizes HTTP requests made to 3scale. It provides a standard way to inject 3scale API Management configurations into OpenShift Service Mesh for execution in a single data plane. In this scenario, service mesh serves as the data plane and 3scale serves as the control plane, eliminating the need for an additional gateway and reducing latency due to the reduced number of hops. See Figure 5.

Try this architecture on your own

Red Hat solution patterns provide a solid starting point for those seeking a specific reference architecture to replicate or use as inspiration for technical decision making. These patterns offer guidance on designing, developing, integrating, automating, and delivering cloud-native applications.

The Travelz example is one such pattern that specifically examines the relationship between service mesh and API management to help you understand how to use these solutions together to establish a comprehensive service management architecture.

Interested in trying this on your own? Red Hat Developer's solutions patterns topic page provides necessary scripts and detailed steps to see the architecture in action.

Conclusion

Service mesh and API management are both powerful tools that can bring significant benefits to your microservices architecture. When used together, they can provide a comprehensive solution for managing and securing your microservices and APIs, improving security, performance, observability, and developer experience. By using both, your organization can have a more holistic view of its microservices and API usage, which can help you make better decisions for future scaling and security.