A microservice-based system can consist of dozens or even hundreds of individual services communicating with each other via APIs. While its possible for a client be that a web browser, application or IoT device to make requests to the relevant microservice directly, this approach has a number of disadvantages.
Direct client-to-microservice communication means exposing the APIs for each microservice. Developers wanting to interface with the system need to understand the network of services in order to identify the microservices they require. While this may be manageable for very simple applications, in many cases this will involve multiple requests to different microservices, some of which may not use web-friendly protocols. When changes are made to the system, such as combining or splitting services, consumers will be required to update their client-side requests. In addition, functionality such as API authentication, rate limiting and monitoring must be applied to each microservice, which will often require the logic to be implemented in multiple languages.
The alternative to direct client-to-microservice communication is to use an API gateway. A gateway acts as an abstraction layer for your microservices and provides a single point of entry for consumers of your application.
A key benefit of an API gateway is the abstraction of the backend microservices. An API gateway acts as a proxy for your application's microservices, exposing the public-facing API endpoints, routing incoming client requests to the relevant services, transforming them as required and aggregating the response data before sending the response to the client. An API gateway provides a clean interface for clients to interact with, making your system easier to use and therefore more attractive in a competitive marketplace.
Using a gateway also avoids overly chatty requests from clients. This is particularly relevant for remote client apps, where multiple roundtrips for requests can introduce high levels of latency and result in poorer performance. Being able to make a single request to an API gateway, which then routes the calls and collates the responses, is far more efficient.
Decoupling your system's public-facing API endpoints from the microservice architecture underneath allows you to make changes to the individual microservices without impacting the consumers of the public API. This consistency for consumers is not just important for existing microservice-based systems but also for organizations moving from a monolithic architecture to microservices. In the latter case, implementing an API gateway at the start of the migration process provides a consistent interface for clients to interact with while the architecture is broken down and re-built behind it.
As the single point of entry to your system, API gateways restrict access to your microservices from the outside world, reducing the potential attack surface compared to a direct client-to-microservice design. API gateways can be used to manage IP whitelists and blacklists and implement authentication and authorization. Not only does this ensure that only valid requests are allowed through, but it is also more efficient than implementing the logic in each microservice, which may mean replicating it for multiple languages and frameworks.
One of the many advantages of a microservice architecture is the ability to scale services independently according to load. An API gateway can provide load balancing to ensure even or weighted distribution of incoming requests across the available instances of a service.
Where high availability is required, load balancing can be combined with rate limiting and throttling to protect the system from unexpected spikes in traffic, including denial of service attacks. Implementing these features at the API gateway provides a central platform for managing this functionality. Again, this avoids the duplicate effort that would be involved in applying the functionality to individual microservices in multiple languages.
As the interface that consumers of your system will interact with, an API gateway should be designed to meet their needs. If your system serves multiple types of clients, it may be appropriate to provide multiple API gateways based on those types. This design, known as backends for frontends, allows different endpoints to be exposed as well as different security and traffic management policies to be applied.
Being the single point of entry for your system does not mean an API gateway should become a bottleneck or a single point of failure. For applications requiring high availability, setting up a cluster of API gateways with requests load balanced across them ensures a more resilient system.
In order to protect your organization's assets, API gateways should be designed and configured with security in mind. This includes being mindful of what data is made available via public-facing endpoints and response headers, using secure communication channels, and implementing authentication, rate limiting and throttling.
API gateways provide a central platform for managing these cross-cutting concerns efficiently, ensuring a microservice architecture doesn't result in duplicated effort. With Kong Gateway, configuring your public-facing endpoints is simple. Kong Gateway includes support for high-availability clusters and includes an extensive range of plugins to address cross-cutting concerns, including authentication, security, rate limiting, throttling, transformations, analytics and monitoring.
Ever feel like you're fighting an uphill battle with your API strategy? You're building APIs faster than ever, but somehow everything feels harder. Wasn’t API-first supposed to make all this easier? Well, you're not alone. And now industry analys
Ever wonder how Netflix streams to millions of users without crashing? Or how Amazon powers billions of transactions daily? The secret sauce behind these scalable, resilient behemoths is microservices architecture. If you're a developer or architect
Kafka delivers massive value for real-time businesses — but that value comes at a cost. As usage grows, so does complexity: more clusters, more topics, more partitions, more ACLs, more custom tooling. But it doesn’t have to be that way. If your tea
Kong customers include some of the most forward-thinking, tech-savvy organizations in the world. And while we’re proud to help them innovate through traditional APIs, the reality is that their ambitions don’t stop there. Increasingly, our customers a
In the SaaS world, providers must offer tenant isolations for their customers and their data. This is a key requirement when offering services at scale. At Kong, we've invested a lot of time to provide a scalable and seamless approach for developers
Open source software has become an indispensable component of modern software development. With its easy accessibility, it offers numerous benefits such as cost savings, flexibility, and collaborative innovation. Since the use of open source componen
Managing Kafka as an island on its own got you this far. But scaling it securely and efficiently across your organization? That's another matter entirely. Apache Kafka is the number-one event streaming platform used by developers and data engineers
