Sometimes everything depends on a powerful gateway. Covering security, control and the power of transformation, James Higginbotham explores the ways in which microservice architectures can benefit from a microservices API gateway.
APIs are transforming the delivery of everything from fintech services to healthtech, through API-centric initiatives to APIs as products in their own right. This is prompting many businesses to explore the benefits of an API gateway in microservices architectures for the first time.
What is an API gateway?
A gateway provides a single, unified API entry point across one or more internal APIs. The gateway typically provides:
- Rate limiting
- Access quota management
- Security
- Caching
- Routing
- API composition, processing and versioning
- API health analytics
An API management layer, such as Tyk, adds additional capabilities: in-depth analytics, monetization, full lifecycle API management and more.
In a microservice-based architecture, whether you have 10, 100 or even more services, a microservices API gateway can help provide a unified entry point for external consumers. It does this independent of the number and composition of internal microservices. By enforcing security policies and supporting scalability, it can unlock significant potential in your architecture.
How an API gateway works in microservices
What is an API gateway in microservices? Well, in a microservice architecture, a gateway can help to solve a range of issues. It sits at the edge of the microservices, managing incoming requests and responses that flow between client applications and your backend service setup.
Without it, you’re left dealing with a direct client-to-microservices pattern. Such implementations can get very messy, very fast. You end up with multiple client calls to multiple microservice endpoints, with client apps and microservices coupled in a way that discourages any kind of evolution of your microservices due to the layers of complexity involved in routing requests. You’re effectively stifling innovation.
With microservice API gateway and access patterns, you’re putting a software application – the gateway – between every single request from a client to your backend service. The client calls then flow through the gateway, which routes them to the various microservices, including breaking calls down into different requests for different services, if required. In addition to request routing, the gateway also handles responses.
This structure delivers a range of benefits, including:
- Prevention of exposing internal concerns to external clients
- An additional layer of security for your microservices
- Support for mixing communication protocols
- Decreases microservices complexity
- Scope for microservice mocking and virtualization
We’ll explore these in more detail below.
Microservices API gateway example
There are countless microservices API gateway examples out there. One of the best-known examples is Netflix. The streaming giant takes a ‘one size fits all’ approach to its architecture, despite the various client applications that are used to call it. Think televisions, tablets, smartphones, set-top boxes and so on.
Netflix has always been keen to embrace the advantages of technology and has successfully used GraphQL federation to scale and cement its global presence.
Of course, you don’t have to be the size of Netflix to enjoy the advantages of a gateway in your microservices architecture. But before you start reaping those rewards, you’ll need to know which microservices API gateway is best. Let’s look at some of the options.
There’s a lot to think about in terms of types of microservices API gateways. For example:
- Should you use an open source gateway for microservices? If flexibility is a priority for you, along with avoiding vendor lock-in while also keeping your costs low, then open source could be the right choice.
- Would an on-premise gateway or a cloud solution meet your needs best? There’s a convenience versus control debate when it comes to whether to opt for an on-premise or a cloud gateway solution. Regulatory requirements may come into play here too.
- Which providers should you consider and why? Identifying the best API gateway for microservices means looking in depth at what the market leaders are offering and considering which solution best fits with your microservices architecture, your team’s skills, your budget, your implementation timeline and more.
The benefits of a microservices API gateway for microservices
The advantages of using a gateway in your microservices architectures are numerous. Let’s look at some of the headline benefits.
Prevents exposing internal concerns to external clients
An API gateway separates external public APIs from internal microservice APIs, allowing for microservices to be added and boundaries changed. The result is the ability to refactor and right-size microservices over time, without negatively impacting externally-bound clients. It also hides service discovery and versioning details from the client by providing a single entry point for all of your microservices.
This gives you the freedom and flexibility to change what you need to ‘behind the scenes’, from small service tweaks to fundamental changes – all without impacting the client side of things.
Adds an additional layer of security to your microservices
API gateways help to prevent malicious attacks by providing an additional layer of protection from attack vectors such as SQL Injection, XML Parser exploits and denial-of-service (DoS) attacks.
Given the ever-increasing sophistication of such attacks, no business can afford to ignore them. From disruption of services to reputational damage, there is a huge amount at stake; adding in an extra layer of security makes sense.
Enables support for mixing communication protocols with a microservices API gateway
While external-facing APIs commonly offer an HTTP or REST-based API, internal microservices may benefit from using different communication protocols. Protocols may include ProtoBuf, AMQP or perhaps system integration with SOAP, JSON-RPC or XML-RPC. A microservices gateway can provide an external, unified REST-based API across these various protocols, allowing teams to choose what best fits the internal architecture.
And then there’s GraphQL. As adoption levels increase, it’s important to build in capacity. Do you want to build and manage GraphQL microservices next week, next month, next year…? At some point, it’s likely to happen, and the right gateway will help you adapt.
Decreased microservice complexity
Microservices have common concerns, such as: authorization using API tokens, access control enforcement and rate limiting. Each of these concerns can add more time to the development of microservices by requiring that each service implement them. A gateway will remove these concerns from your code, allowing your microservices to focus on the task at hand.
Authorization and authentication in particular become much easier to manage when they are controlled via your microservices gateway. This setup also means you have clear oversight of who has been accessing what and when – something that can come in handy in all manner of scenarios.
Microservice mocking and virtualization
By separating microservice APIs from the external API, you can mock or virtualize your services to validate design requirements or assist in integration testing. This provides plenty of scope for innovation. You can test and tinker to your heart’s content, without impacting the experience of those accessing your microservices.
The drawbacks of a microservice API gateway
While there are many benefits to using an API microservice gateway, there are some downsides:
- Your deployment architecture will require more orchestration and management with the addition of a gateway
- Configuration of the routing logic must be managed during deployment, to ensure proper routing from the external API to the proper microservice
- Unless properly architected for high availability and scale, a microservices gateway can become a limiting factor and even a single point of failure
How to create an API gateway for microservices
If you want to choose the best API gateway for microservices, look for one that’s easy to implement and that delivers the flexibility, security and features you need right out of the box. Creating your microservices API gateway shouldn’t be hard – and with Tyk, it’s not.
For our self-managed (on-premise) gateway, you can complete the installation process using Docker in just minutes. For our cloud gateway, you can sign up online and again it takes only minutes to get the gateway up and running.
Connecting and managing your microservices through a gateway should be just as painless, taking just a few minutes.
Which API gateway is best for microservices?
Ok, so we’re a bit biased when it comes to which gateway is best for microservices. Clearly, we think that Tyk has plenty to offer. You can check out our candid comparison with Kong for full details or review how Tyk is faster and more performant than Gravitee.
Tyk’s strengths lie in the flexibility and freedom that our gateway provides, along with how easy it is to use. Its powerful performance and minimal overhead are also pretty impressive.
When you’re already dealing with multiple microservices, the last thing you need is a gateway that’s complicated to understand or use. So, when you’re deciding which microservices API gateway is best, be sure to factor usability into your thinking too.
We’ll let Tyk CEO Martin Buhr sum it up:
“Tyk was built to work with microservices – to be able to handle millions of transactions across multiple endpoints. This was before Kubernetes came along… We work very, very well in those ecosystems – Tyk is a really good piece of kit to put into your microservice first Kubernetes ecosystem and run your API management, all using Kubernetes operators and our Kubernetes operator and CRDs.”
How to implement an API gateway for microservices
Implementation is easy. You choose your provider, set up the gateway and start connecting your microservices. Simple! Or so it seems…
Actually, you need to think carefully about the gateway pattern you want to implement. Do you want a single instance that effectively couples all your microservices or are you looking for multiple gateways, so that you can tailor each for a different client app (one for web and one for mobile, for example)?
This ‘backend for frontend’ approach may initially sound like more hassle to set up, but it’s well worth considering when you’re mapping out your microservices strategy.
Why an API gateway is required in microservices
A microservices API gateway is necessary for a range of reasons. The additional layer of security that it provides is one, as is the fact that implementing a gateway can reduce the complexity of your microservices architecture and management.
Increasingly for many businesses, the support that a gateway provides for mixing and transforming communication protocols is also essential. This delivers far more flexibility than you could hope for in a direct client-to-microservices setup.
To underpin innovation, the fact that you can mock up and virtualize new services behind the gateway, all without impacting the client side, is also important. Plus, you can prevent exposing internal concerns to external clients. Very helpful.
What is the use of an API gateway in microservices?
A gateway sits between external consumers and your microservices, providing a unified entry point. You can use it not just for routing but for rate limiting, access quota management, caching, security and more.
You can also use it for composing, processing and versioning APIs, as well as for monitoring their health based on response times and a wide range of other factors. Different types of microservices gateway will deliver different levels of analytics, but all should provide sufficient data to flag up any API health concerns. This is important if you want to be as proactive as possible in identifying any pain points or issues within your architecture and your business.
Ultimately, you can use an API gateway for microservices to decrease complexity while enhancing security and manageability.
Why do we need an API gateway in microservices?
In simple terms, a gateway can deliver smoother, easier management of your microservices architecture and user experience while saving you time and headaches.
Authentication and authorization is a good example of this. By centralising microservices authentication and authorization, you can manage access to multiple services at once. No more fiddling around with individual services – you can shift control to the gateway and save time and effort in the process.
The fact that a gateway can route multiple API calls to different services simultaneously is also helpful in terms of increasing efficiency. This centralized control lays a strong foundation for rapid scaling, so implementing a gateway in your microservices architecture can also unlock your business’ potential for growth.
Microservices API gateway vs service mesh
There’s some major overlap between using a microservices API gateway and opting for a service mesh, yet the two were designed for different purposes. Using a gateway and API management is all about facilitating API discovery, consumption and collaboration. The gateway handles boilerplate logic to support scalability, enabling teams to productize their APIs.
A service mesh, on the other hand, is all about observability and interoperability, focusing on service connectivity. It’s a less high-level solution, focusing on the relationships between services and enabling and monitoring holistic deployments.
This means that it isn’t always a simple question of microservices API gateway vs service mesh – it all depends on which problems you’re trying to solve and why. It’s also not an either/or situation – there’s room for both, depending on the size, resources and needs of your business.
Using Tyk for your microservice gateway
We’re not going to sing Tyk’s praises as the best API gateway for microservices here. Dave Koston, VP Engineering at Help.com, can do that instead:
“We use Tyk as a gateway in front of around 15 services (of varying sizes). We’re also using Tyk Identity Broker to proxy logins to our existing authentication service. Tyk gives us some really great features out of the box like rate limiting, sessions, token policies and visibility into API traffic.
“We also have web socket communication that requires authentication and it was easy to simply add some metadata to Tyk sessions and use the Tyk session store (Redis in our case) to authenticate those web socket connections with the same access token that we use for HTTP.”
To learn more about Tyk, take a look at our microservices solutions or book a personalised demo.
