You’re already familiar with the pros and cons of microservices and monoliths and with APIs and different styles of APIs. Great. But what about service mesh and API management?
Whether you’re about to adopt a service mesh approach, wondering if you still need an API gateway, or are worried about using both together, we will look at some of the most burning questions API-first businesses have about service mesh and API management. If you need a quick recap on the differences and similarities between the two, first, there’s one here.
Our intention isn’t to open the “Should you be using microservices?” debate. There’s no judgement here. What we do want to do is challenge some of the statements that you may have heard about microservices. Claims such as:
- Service mesh and API management are the same thing.
- Your business cannot succeed without an API gateway or service mesh or both.
- You have to choose between API gateway and service mesh – you can’t have both.
- One solution can do it all – deliver everything that service mesh and an API gateway do and manage your API across networks, layers and systems.
We’ll explore the veracity of those statements in just a moment. First, let’s start with some quick definitions.
What is a service mesh and an API gateway?
In simple terms, a service mesh is a dedicated infrastructure layer for making service-to-service communication safe, fast and reliable (William Morgan, Linkerd). An API gateway, meanwhile, is an API management tool that sits between a client and a collection of backend services, acting as a reverse proxy to enable safe, fast and reliable access to your APIs and API products.
Clearly, there is some repetition of terms here. That’s because a service mesh and an API gateway are both looking to do similar things – but with subtle differences in terms of where and at what point they come into existence and their overall objectives. Service mesh is more concerned about services as a whole – which version of a service is running, how healthy services are, which service can communicate with which other, whether they are secured and so on. API gateways and API management, meanwhile, are concerned with the APIs within your services – what the end points are and how healthy they are.
As such, service mesh isn’t really solving any new problems but the context for its use is different. While there are big overlaps between service mesh and API gateways, they were designed for different purposes.
A quick history lesson
Everything was relatively static in the olden days (a couple of years ago). You would deploy your services (monolithic, naturally) and put them behind a load balancer and configure things. Then they would largely stay there. Job done.
Now we’ve moved to the cloud and microservices. We’ve started thinking about elastic compute, and we need to be able to scale things up and down consistently. Service mesh does that consistently across microservices while automatically giving you Mutual TLS (mTLS) between your microservices for instant security.
API gateways, however, were more designed for allowing traffic into and out of your systems – or into and out of your infrastructure. So there’s plenty of overlap and apparent differences in purpose and context.
A general way to look at it is that an API gateway handles north-south traffic (traffic from the outside world into your API ecosystem), while service mesh handles east-west (service-to-service) traffic.
Do I still need an API gateway if I adopt a service mesh approach to applications?
There are plenty of reasons to adopt a service mesh approach to applications. Perhaps you’re a DevOps person charged with watching your API ecosystem to see the health of all the services. Or maybe you’re an infrastructure person who wants to ensure that mTLS has automatically pushed out to all your services.
Either way, a service mesh will tick all the right boxes – but that doesn’t mean you don’t also need an API gateway.
For example, your CTO may want to increase the discoverability of APIs internally, or your CRO might want to open up an extra revenue stream by publishing API products to a developer portal so they can be consumed. Or maybe you want to do some transformations, taking legacy SOAP services and exposing them as GraphQL to offer a better experience for your API consumers.
In those cases, an API gateway and API management solution will pay dividends in addition to a service mesh approach. It comes down to context and the outcomes your business wants to achieve. If you have a service mesh but want to productise and monetise your APIs consistently, you could also benefit from an API gateway and API management.
Should I bother with service mesh if I already have an API gateway?
There are certainly situations when businesses can benefit from service mesh, even if they already have an API gateway in place. Again, it comes down to the goals the business is trying to achieve.
Say your business has an API gateway to secure and expose its APIs. Great. Now let’s say you also have thousands of microservices and need to ensure that your services are online, operational and being deployed in a manner that will suit very high traffic. That’s a clear-cut case for adding service mesh into the mix.
Much of this comes down to scale. If you’re a start-up with APIs, start with an API gateway. Then add in a service mesh when you scale to the size where you need it. If you’ve decided to adopt Kubernetes, you’re probably big enough for service mesh. Assuming it meets your business goals, of course.
Can I use an API gateway and service mesh together?
Absolutely. Neither an API gateway nor a service mesh is a ‘one size fits all’ solution. Most organisations don’t all have greenfield projects – they have brownfield projects, things on the rack, and things that aren’t in Kubernetes… and all those services need to be communicated.
So, service mesh makes sense regarding microservices and Kubernetes communicating with each other, but so does an API gateway and API management connecting all the clusters and going cross-cluster or cross-namespace, depending on your on how you’ve modelled your problem.
Technical maturity is also a factor. Usually, the debate around whether service mesh is needed comes once a business already has something in place – such as Kubernetes or microservices. It’s a good idea to avoid bringing in complexity until you’re at the point where you need it. Don’t put your tech hat on until you know your business goals and the problem(s) you’re trying to solve.
Of course, if you’re opting for a solution that combines a service mesh with an API gateway, be sure you choose products that will play nicely together and deliver a cohesive and flexible solution.
You’ll also need to consider performance costs using a service mesh and an API gateway, depending on how strong performance versus capability is for you. Vendors writing API gateways and service meshes understand that they’re adding at least one other hop, so it’s their job to ensure that they’re writing software optimised for that.
They wouldn’t be in business if they introduced too much latency (which is why they’re written in languages like Golang or Rust). But it’s something to remember if a few milliseconds make a difference to your business.
Next steps
There’s plenty to consider in the whole service mesh versus API management debate. We hope we’ve given you some food for thought. Wondering where to go from here? Why not learn more about how Tyk works with a service mesh? Or if you know all you need to already, simply crack on and sign up to Tyk now!
You can also access our continuously updated service mesh resource hub for expert insights helping you manage your microservices effectively.
