Skip to main content
Redhat Developers  Logo
  • Products

    Featured

    • Red Hat Enterprise Linux
      Red Hat Enterprise Linux Icon
    • Red Hat OpenShift AI
      Red Hat OpenShift AI
    • Red Hat Enterprise Linux AI
      Linux icon inside of a brain
    • Image mode for Red Hat Enterprise Linux
      RHEL image mode
    • Red Hat OpenShift
      Openshift icon
    • Red Hat Ansible Automation Platform
      Ansible icon
    • Red Hat Developer Hub
      Developer Hub
    • View All Red Hat Products
    • Linux

      • Red Hat Enterprise Linux
      • Image mode for Red Hat Enterprise Linux
      • Red Hat Universal Base Images (UBI)
    • Java runtimes & frameworks

      • JBoss Enterprise Application Platform
      • Red Hat build of OpenJDK
    • Kubernetes

      • Red Hat OpenShift
      • Microsoft Azure Red Hat OpenShift
      • Red Hat OpenShift Virtualization
      • Red Hat OpenShift Lightspeed
    • Integration & App Connectivity

      • Red Hat Build of Apache Camel
      • Red Hat Service Interconnect
      • Red Hat Connectivity Link
    • AI/ML

      • Red Hat OpenShift AI
      • Red Hat Enterprise Linux AI
    • Automation

      • Red Hat Ansible Automation Platform
      • Red Hat Ansible Lightspeed
    • Developer tools

      • Red Hat Trusted Software Supply Chain
      • Podman Desktop
      • Red Hat OpenShift Dev Spaces
    • Developer Sandbox

      Developer Sandbox
      Try Red Hat products and technologies without setup or configuration fees for 30 days with this shared Openshift and Kubernetes cluster.
    • Try at no cost
  • Technologies

    Featured

    • AI/ML
      AI/ML Icon
    • Linux
      Linux Icon
    • Kubernetes
      Cloud icon
    • Automation
      Automation Icon showing arrows moving in a circle around a gear
    • View All Technologies
    • Programming Languages & Frameworks

      • Java
      • Python
      • JavaScript
    • System Design & Architecture

      • Red Hat architecture and design patterns
      • Microservices
      • Event-Driven Architecture
      • Databases
    • Developer Productivity

      • Developer productivity
      • Developer Tools
      • GitOps
    • Secure Development & Architectures

      • Security
      • Secure coding
    • Platform Engineering

      • DevOps
      • DevSecOps
      • Ansible automation for applications and services
    • Automated Data Processing

      • AI/ML
      • Data Science
      • Apache Kafka on Kubernetes
      • View All Technologies
    • Start exploring in the Developer Sandbox for free

      sandbox graphic
      Try Red Hat's products and technologies without setup or configuration.
    • Try at no cost
  • Learn

    Featured

    • Kubernetes & Cloud Native
      Openshift icon
    • Linux
      Rhel icon
    • Automation
      Ansible cloud icon
    • Java
      Java icon
    • AI/ML
      AI/ML Icon
    • View All Learning Resources

    E-Books

    • GitOps Cookbook
    • Podman in Action
    • Kubernetes Operators
    • The Path to GitOps
    • View All E-books

    Cheat Sheets

    • Linux Commands
    • Bash Commands
    • Git
    • systemd Commands
    • View All Cheat Sheets

    Documentation

    • API Catalog
    • Product Documentation
    • Legacy Documentation
    • Red Hat Learning

      Learning image
      Boost your technical skills to expert-level with the help of interactive lessons offered by various Red Hat Learning programs.
    • Explore Red Hat Learning
  • Developer Sandbox

    Developer Sandbox

    • Access Red Hat’s products and technologies without setup or configuration, and start developing quicker than ever before with our new, no-cost sandbox environments.
    • Explore Developer Sandbox

    Featured Developer Sandbox activities

    • Get started with your Developer Sandbox
    • OpenShift virtualization and application modernization using the Developer Sandbox
    • Explore all Developer Sandbox activities

    Ready to start developing apps?

    • Try at no cost
  • Blog
  • Events
  • Videos

Why service mesh and API management are better together

Unleash the full potential of microservices and APIs

May 1, 2023
Vamsi Ravula
Related topics:
APIsMicroservicesService Mesh
Related products:
Red Hat OpenShift API ManagementRed Hat OpenShift Service Mesh

Share:

    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.

    A diagram of access via portals versus agency.
    Figure 1: Travel agency microservices are managed and monitored using Red Hat OpenShift Service Mesh.

    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.

    Diagram showing the company manages partner access to their APIs using 3scale.
    Figure 2: The company can now securely manage partner access to their APIs using Red Hat 3scale API Management platform.

    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.

    Diagram showing enterprise boundaries for a group of applications.
    Figure 3: Using domain boundaries within your organization.

    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.

    Diagram of interdomain traffic versus intradomain traffic patterns.
    Figure 4: 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.

    Diagram of 3scale and service mesh integration to secure internal traffic.
    Figure 5: Simplified integration between 3scale and OpenShift Service Mesh to secure internal traffic. 

    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.

    Last updated: August 14, 2023

    Recent Posts

    • More Essential AI tutorials for Node.js Developers

    • How to run a fraud detection AI model on RHEL CVMs

    • How we use software provenance at Red Hat

    • Alternatives to creating bootc images from scratch

    • How to update OpenStack Services on OpenShift

    Red Hat Developers logo LinkedIn YouTube Twitter Facebook

    Products

    • Red Hat Enterprise Linux
    • Red Hat OpenShift
    • Red Hat Ansible Automation Platform

    Build

    • Developer Sandbox
    • Developer Tools
    • Interactive Tutorials
    • API Catalog

    Quicklinks

    • Learning Resources
    • E-books
    • Cheat Sheets
    • Blog
    • Events
    • Newsletter

    Communicate

    • About us
    • Contact sales
    • Find a partner
    • Report a website issue
    • Site Status Dashboard
    • Report a security problem

    RED HAT DEVELOPER

    Build here. Go anywhere.

    We serve the builders. The problem solvers who create careers with code.

    Join us if you’re a developer, software engineer, web designer, front-end designer, UX designer, computer scientist, architect, tester, product manager, project manager or team lead.

    Sign me up

    Red Hat legal and privacy links

    • About Red Hat
    • Jobs
    • Events
    • Locations
    • Contact Red Hat
    • Red Hat Blog
    • Inclusion at Red Hat
    • Cool Stuff Store
    • Red Hat Summit

    Red Hat legal and privacy links

    • Privacy statement
    • Terms of use
    • All policies and guidelines
    • Digital accessibility

    Report a website issue