The use of APIs and microservices is increasing – a recent study from F5 estimated that the industry is approaching 200 million total APIs. As organizations expand their use of APIs and microservices, they inevitably require some form of service management architecture. There are basically two design options for doing this: an API management system or a service network.
The main distinction between API management and service network can be framed using the four cardinal directions. The management API is usually supported for REST services facing external developers – referred to as North-South traffic. On the other hand, the service network is more commonly used by the inner wings of the microservices to help control the lateral or east-west communication. There are more nuances between each, as we will cover below, but this is how they are adopted in practice.
However, this duo is becoming blurred as enterprise digital application suites expand and cross-company access to business domains begins to look and feel like it’s consuming third-party SaaS. Furthermore, some suggest that with the right controls, a service network can meet the needs of external users in the same way that API management does. Moreover, the service network and API management are complementary – they can coexist within the same organization and even be deployed in the same projects.
I recently spoke with Mark Cheshire, Product Manager at Red Hat, about the emergence of both API and Service Network management. According to Cheshire, both approaches achieved similar goals but developed quite differently. Below, we’ll revisit, compare and contrast why these two models came to be. In a separate article, we’ll look at when to combine them together.
What is API management?
API management is often associated with north-south traffic. By exposing your API to the outside world, you can enable other developers to connect it to their systems and take advantage of your data and functionality as building blocks.
API management arose in response to the rise of web APIs. API management is a broad concept that includes many functions required to display an API endpoint to the outside world. This can include authentication, authorization, order routing, documentation, rate setting, monitoring, registration, monetization, and lifecycle management. The main goal is to facilitate integration for the developer consumer. Architecturally speaking, API management follows the gateway pattern. Consumers issue requests to the portal which then redirects to basic services.
For APIs, the biggest catalyst was the advent of Web 2.0, Cheshire explained. Many startups are consuming RESTful APIs to connect web properties and partner ecosystems. Companies have also found that REST APIs are a more direct integration approach than SOAP and SOA. They’ve also seen the benefits of ease of use and first certified API designs within their on-premises infrastructure.
As of 2021, more than 70% of APIs were created for internal use. So, do all of these services need API management? It depends. “If you’re communicating externally, you need to manage the API,” Cheshire explained. But he says it’s a gray area for services within an organization, even though traffic between domains can often benefit from API management.
- It can enable north-south traffic
- Protects app limits
- Designed to facilitate the consumption of external developers
- Monetization and subscription plans
- Usually plug and play; Easier to support
- Many solutions on the market
- Developer experience and documentation
- Analytics and Reports
- It may be heavier than the service network
- Fewer open source options; fist sellers in
- Paralysis of analysis in comparing solutions
What is a mesh service?
The service network is often associated with controlling the east-west communication between internal services. Service networks such as Linkerd, Istio, and Kuma make it easy to re-implement similar logic—such as networking, monitoring capability, traffic management, security policies, and routing— across many microservices from a single level of control.
The Service Grid was built to handle slightly different challenges than managing an API. “The transition from microservices to microservices is about East-West traffic,” Cheshire said. Companies have found that creating monolithic applications is slower, and thus break them down into micro-services that communicate via APIs. But all of these small services needed similar operational capabilities, which would be cumbersome to repeat over and over for each service.
“For a single threaded application that has been turned into microservices, you might not even need a service network,” Cheshire said. “However, when you have hundreds or thousands, implementing a service network becomes critical.”
Architecturally, the service network is usually divided into a data plane and a control plane. The service network deploys a side agent that sits alongside each individual service. Istio, for example, uses an Envoy proxy. Other networks like Linkerd use their own proxy.
- It fits the microservice architecture model well
- good for directing traffic; improve flexibility
- Recommended NIST architecture for zero confidence
- Many open source options
- Suitable for large microservice deployments
- It requires a more hands-on approach
- Possibly more maintenance to support
- Not necessary for one service
- Requires additions to the filter chain for North and South capabilities
Comparison of management API and service network
API management is basically consistent with the output of partner APIs. In doing so, maintaining the contract with the consumer is even more important to meet service level agreements. Thus, API management generally provides lifecycle management capabilities, such as versioning. Managing an API is essential even if you are showing a single API, as this service must be adequately documented and secured. However, these tenants can also be suitable for developers who are reusing software inside Organization – There is something to be said for adopting a product mindset when dealing with internal APIs.
On the other hand, the service network is more closely aligned with the control of internal networks. Microservices are rarely deployed on their own; Typically, multiple microservices make up an application. And more may exist throughout the organization for unique purposes. Thus, a service network helps maintain consistency across large networks of separate small services. Service network is also a rapidly growing field, which is experiencing a new explosion in development and production. A Cloud Native Computing Foundation (CNCF) report found that service network usage rose in production by 50% in 2020 alone.
To put the comparison another way, William Morgan, CEO of Buoyant, described how managing an API revolves around business logic, while a service network deals with intra-cluster operations:
“API gateways typically deal with entry concerns, not in-cluster concerns, and often deal with a certain amount of business logic, eg “user X is only allowed to make 30 requests per day.” By contrast, the service network focuses Like Linkerd on operational concerns (eg tooling these calls and reporting their success rate; securing this communication between these capsules) and intentionally avoiding confusion between business and operational logic; and focuses on communication between services in the cluster.”
Although service network and API management achieve slightly different goals, both layers facilitate the reuse of web-based services. It certainly can be used in conjunction. For example, you can create microservices from an API with a service network and simultaneously use API management to expose certain domains. In another article, we’ll look at the time to combine the two techniques.