So you’re a CTO, a lead architect, or a senior engineer, and you’re looking into API Management (APIM), which led you to service mesh. Or you recently discovered service mesh, which led you to hear about APIM.
Let me guess: You’re (justifiably) confused about the differences between the two. It seems like there’s a massive overlap and sometimes merging of the two in terms of their purposes from your organisation’s perspective. You’re not alone – we reached this wonderful little situation both accidentally and on purpose. More on that below.
First, the primary question to answer is:
Which one does our organisation need?
TL;DR
It’s not an either-or. Service meshes and APIM were designed to address different problems.
A service mesh was designed to fix a networking and observability problem. API management fixes the problem of people: API discovery, consumption, and collaboration.
The more interesting question is why were they confused together? But to answer that, let’s first understand how they are different.
Let’s unpack the primary question a little bit:
- What are the differences between Service Mesh & APIM
- What are the similarities between them
- Which one should we choose?
- When should we use both?
- How does Tyk integrate with a service mesh?
Differences
Service meshes are all about network management and observability; they care about your API services.
- How do we control access between services?
- What is the health of all services?
- How do these services depend on each other?
- How can we deploy and merge new versions of our services?
In a nutshell: A service mesh is essentially an observability and interoperability solution concerned with your services’ connectivity. Service meshes address the needs of SREs and DevOps engineers by enabling holistic deployments and monitoring of services across an organisation and the relationships between them.
API Management is about your APIs. What business value are your APIs providing?
- How do we want to productise our APIs?
- How do we want to secure our APIs?
- How do we publish and monetise our APIs?
- How do we perform data normalisation?
- How do we integrate with other APIs?
- How do we enable the discovery of APIs via an API Catalogue?
- How do we gather analytics about our API consumption?
In a nutshell: APIM is concerned with a much higher level than service mesh. Teams use APIM to mature their API ecosystem from a consumption perspective. They want to enable the scalability of API development by offloading boilerplate logic to an API Gateway. They’re looking to productise their APIs and enable discovery between developers within a team, organisation, or publicly to enable the adoption of their APIs with product-led growth. APIM can be a top-down, organisational, or team-based decision to increase velocity.
Similarities
So we’ve seen where the two platform patterns differ in terms of their design and typical audience. How about their similarities? This is the area that causes the most confusion.
|
APIM Emphasis on API Consumers |
Service Mesh Emphasis on inter-service communication |
|
|
Rate limiting |
API is a product with limited access depending on access “tier” I.e bronze, platinum, admin |
Incoming ingress rate limit, as well as service-to-service limits I.e east-west communication |
|
Authentication / Authorisation |
Who is the end user, and what permissions do they have? Supports many authentication types |
Which services can access which services? |
Before you go down the route of adopting a service mesh, please ask yourself:
- Are we solving Google-scale problems that we don’t have?
- What problems are we proposing that a service mesh will fix? Is there an easier way?
- Do we have dedicated resources who can maintain this complex technical platform?
In summary, we’ve established that a service mesh is a pattern designed to address the needs of SREs and DevOps engineers who want to maintain a holistic view of an organisation’s services. What about APIM?
API Management is used by companies that want to adopt an API-first mentality, especially to enable API design, growth, and organisational scalability. When a company begins building APIs at any scale, the APIM approach encourages best practices and solves basic API necessities like analytics, security, and more.
Companies that don’t need API management are those with straightforward API use cases where a simple reverse proxy is sufficient. A case like that would include a single team solving a specific pain.
There’s room for both
Long story short – there’s certainly room for both APIM and a service mesh depending on the size of the organisation and the resources at their disposal. If you haven’t experienced either of the pains described above, you might be confused as to why the two patterns are being compared, as they’re so drastically different.
A lot of the confusion comes from the fact that some API management platforms have decided to go “all-in on service mesh,” meaning they’re opinionated about having to use both and not just one.
At Tyk, we think this is a mistake. Yes, you can race an 18-wheeler around a racetrack and use a Ferrari to tow cargo – would you want to? Worse yet, how many people will buy a vehicle that claims to do both well?
One-size fits all approaches don’t work at this level, and Tyk focuses on end-to-end full lifecycle API management. If teams want to deploy a service mesh, that’s perfectly fine, and they are empowered to do so. Our opinion has always been to enable users to use the best-in-breed tools across their infrastructure stack.
If you’re interested to see how Tyk integrates with Istio, click here.
You can also access our continuously updated service mesh resource hub for expert insights helping you manage your microservices effectively.
