When to Use API Management and Service Mesh Together

Although sometimes described as competing architectures, API and Service Network management have slightly different use cases and can work well together. While the management API provides business logic for external traffic, the service network excels at handling interconnection between microservices. Any organization can certainly adopt both simultaneously across its projects. So, when does it make sense to use both the Manage API And service network?

I recently spoke with Mark Cheshire, Product Manager, Red Hat, to discuss the nuances between managing an API and a service network. According to Cheshire, API management and service network can work well in tandem in certain use cases. For example, a large organization using a service network can take advantage of an API management application that encapsulates microservices into a usable contract for internal departments. Or, API management can help the company expose specific APIs from the network to external partners.

When is API management combined with service network

Let’s say you already have a service network—do you need to manage the API as well? Cheshire offered four questions to consider that may influence your decision.

1. Consider the number of connections and the number of consumers: is it multi-to-one or one-to-many?

Within the mono app, communication is more central – there is more of a one-to-one relationship. However, when you break down services into microservices and reuse them across an organization, the service may now have multiple consumers. This is a good indication that you need an API management approach to the interface.

“As the environments get bigger and bigger, you can’t manage that as a flat web,” Cheshire explained. “You need some kind of organizational grouping by the type of work or jobs you might have.”

API management can create more formal interfaces between internal groups in a large organization that are likely to have little contact with each other. For example, perhaps a customer data team needs a formal way to communicate with the sales organization. Or perhaps the security team that supports a microservice needs to log in to access the financial details from the accounting department.

2. What kind of access control and restrictions does the system require?

Consider access control necessary to secure your environment and avoid service outages. The service network will typically use a no-trust approach, with mutual TLS applied to each entry for each microservice. API management can also bring in authentication controls and more advanced authorization and traffic mechanisms.

The management API can provide a simplified way to implement precise traffic controls between domains that follow business logic. This helps assign access to specific resources for various requesting parties, such as read-only access for basic users or update access for administrators. Amidst the increasing API attacks, setting accurate policies and permissions around your endpoints is becoming increasingly important to avoid data overexposure. This necessity increases as the dichotomy between external and internal traffic fades with more use of the public cloud, remote work, and outside contractors.

API portals also place more emphasis on communication rules and patterns. Cheshire explained that setting a price, for example, is very important to avoid the collapse of entire networks. In addition to setting pricing, filtering, pagination, and content negotiation are also standard API management capabilities that improve client-server exchange.

3. Do you need documentation for services?

In a monolithic setup, you’ll likely have all developers share the same repository, Cheshire explained. This may still be true within an internal network of distributed microservices where each microservice is independent, yet developers can still access each other’s repositories. When you connect services within a domain, it is often the code itself (and possibly some comments included) that represents the contract between the services.

However, north-south traffic requires more formalization, he said. Formal contracts are often necessary when one domain relates to another within the same company. In this scenario, there is less tribal knowledge about how things work. Managing an API is useful, in this case, to produce a developer portal with human-readable documentation that explains methods, request types, URL structures, and sample calls. This makes it much easier for someone without prior knowledge of the system to integrate with it.

Often this formal contract is built from a specific file, such as the OpenAPI specification, which appeared as industry-standard metadata to describe REST APIs. Groups can use OpenAPI to automatically generate documentation and even direct development first to specifications. Overall, standardizing the way you document APIs and microservices can greatly improve knowledge sharing about how services communicate.

4. What is the nature of the interactions?

Another feature to keep in mind, Cheshire said, is the nature of interactions between services. He divided systems into two large types: the first is the graph model, where any service can connect to any service. The second is a hierarchical model where north-south traffic allows a single service to have multiple consumers. The hierarchical model is essential for productivity and SaaS because it creates a single point of interception for core resources. Maintaining the hierarchy here is vital to keeping it simple, as you don’t want the consumer to be able to access all of the private microservices in a connected graph (unless that’s the intent!).

Thus, API management allows sharing of APIs on the network. “While they both use connection agents, and while there are similarities in functionality, differences in domain separate them, most companies will see significant benefits from using them together,” Dino Chiesa and Greg Kuelgen wrote on the Google Cloud blog.

Better together

In short, API management and service network go well together. “The two are complementary and can work together,” added William Morgan, Buoyant CEO. Joachim Moreno wrote: “They are not mutually exclusive; we must think of them as different layers in your infrastructure.”

Specifically, a combination of the two is beneficial when:

  • Detection and production of web APIs
  • Formalizing connections between services in large corporate networks
  • precise access control application; Determining the rate of API-based microservices
  • Consolidation of services with more official documents
  • Interaction is a more hierarchical communication model
  • Provide access to partners
  • When you need to transform data into plug-ins or external integrations

“The worlds of APIs and service networks are more interconnected than ever before,” Cheshire said. And API management won’t stop at REST – as developers embrace new integration patterns like Kafka, GraphQL, and asynchronous formats, solutions will evolve. “It’s basically a governance layer for all of your integration points.”

Large companies looking to standardize traffic between domains within organizations are likely to benefit from API management. But API management also provides the possibility to produce the internal infrastructure. Another benefit is that the API management portal may monitor and log requests, which helps to identify actors in the periphery and maintain a useful log of incidents.

Of course, adopting both API management and service network may be overkill in some scenarios. And it’s good to remember that introducing additional layers naturally increases overall latency. It is up to developers and architects to weigh the options and decide what is right for their unique environment. To enable this, a healthy culture of open communication is important to ensure teams are on a similar page across departments, to avoid mismatched adoptions that only increase art debt.

Leave a Comment