What is an API Gateway?

An API gateway is a reverse proxy that allows your organization to offer APIs as a product to internal and external clients via a centralized ingress point.

An example of a client might be the frontend of your application in the form of a web page, internal services that need to interact with your application, or third-party client websites. API gateways enable communication between different internal and external business applications and can be used to create an abstraction layer between clients and the underlying APIs.

What is an API?

APIs, or application programming interfaces, are a set of functions and procedures that act as a bridge between disparate applications, providing a blueprint for dictating how application services should interact with each other and their broader ecosystem.

As the building blocks of digital products, APIs are an extension of business logic that help modern organizations innovate faster, become more agile and evangelize new markets. In abstracting away the underlying complexity of a service and presenting it as a well-defined product, APIs provide enterprises with secure access to data, services and key operating systems that drive change and digital innovation for internal partners and third-party consumers.

First-Generation API Gateways

As the proliferation of APIs spurred the emergence of the API economy, many software organizations shifted their attention towards procuring technology purpose-built for optimizing the API lifecycle, from creation through to retirement. As part of this movement, in the spirit of improving development speed and agility, pursuing the extraction of standalone services from their monolithic application counterparts became a popularized strategy.

The first-generation API gateway was born to facilitate this initiative – providing IT teams with cross-cutting, application-level functionality such as rate limiting, authentication and routing via the API gateway itself. This created an abstraction layer between the clients and the underlying APIs, ultimately leading to a reduction in the duplicative functionality required from each standalone service and improving development productivity as a result.

In addition to simplifying API traffic management, the first-generation API gateway became well integrated in with the process of full lifecycle API management (APIM), enabling teams to create, publish, manage, secure and analyze APIs within a static monolithic application, often with the goal of monetizing APIs as an end result.

Lastly, the prevalence of the developer portal within the API gateway emerged, allowing teams to document and share their APIs in a much more structured way. Through this self-service model, clients could now access a dedicated portal for designing and testing APIs, monitoring usage and easily browsing documentation to help broaden the opportunity for richer service development and functionality.

From Static to Dynamic Environments

The widespread adoption of the first-generation API gateway signified a clear desire from organizations to explore the full array of API use cases that were available to them across the enterprise. However, at the peak of this industry-wide paradigm shift when many organizations were becoming more entrenched in their API-first strategies, it’s important to note that the underlying technology to support this movement was still in its relative infancy.

As a byproduct of its environment, the first-generation API gateway had mirrored the architectural model of the monolithic application it was built to support – equipped with a heavyweight Java Virtual Machine (JVM) core runtime that severely limited its ability to operate proficiently within modern service environments.

Cumbersome by nature, the first-generation API gateway presented a centralized bottleneck to organizations looking to perform dynamic configurations within their ephemeral containerized environments. While this initial iteration of the API gateway had been optimized for managing traditional north–south traffic, it was not designed to handle the volume of east–west traffic that microservices now presented, hence prompting the creation of the next-generation API gateway.

Next-Generation API Gateways

First, we saw the proliferation of APIs spur the creation of the original API gateway in 2010 to support emerging methodologies for application innovation, monetization and making APIs consumable for third-party access. As we entered into the cloud native era of the mid-2010s, we witnessed the proliferation of microservices provide an opportunity for a new breed of technology to take shape – API gateways that were purpose-built for the cloud native world and specifically designed to address the unique challenges that the API-first domain presented.

While microservices introduced the ability to conduct continuous iteration and deployment that was independent of other business units, this distributed functionality also brought forth substantial complexity and security concerns as service environments scaled.

This all changed with the 2013 advent of Docker containers – a collection of secure, uniform and portable software units that made managing microservices a far more viable avenue to pursue from a business practicality lens. With the release of Kubernetes following soon after, IT teams were finally equipped with an ecosystem suitable for uniformly orchestrating loosely coupled microservices at scale.

Just as containerization technology helped to prove out the adoption of microservices as an effective strategy for encapsulating architectural freedom within a developer’s workflow, it also shined a spotlight on the capabilities of the first-generation gateway – or perhaps more accurately – capabilities lacking thereof in the realm of dynamic feasibility.

The next-generation API gateway can be deployed in its own instance – separate from the client and the APIs. This separation of concerns between the data plane and control plane helps to mitigate the complexity of configuring services at scale within hybrid and multi-cloud environments.

As microservices and containers become more widely used, there is also the factor of exponential transactions occurring on the network at any one time. The next-generation API gateway was made to support the heavy traffic demands of modern architectural patterns, providing developers with a single platform equipped with sub-millisecond latency to help deliver consistent end-user experiences through internal and external channels.

In summary, we’ve seen that the JVM core runtimes of old are typically no longer able to aptly sustain the modern organizations’ pursuit of elevating its development agility and overall scalability within dynamic IT environments. In supporting single-vendor, multi-vendor and distributed setups across cloud and on-premise environments, the next-generation API gateway is truly platform-agnostic and empowers technology leaders to achieve global visibility and governance over their teams’ distributed workflows.

Organizations can now also regain more control over their computing ecosystems and optimize for cost savings, as cloud vendor lock-in is now a factor that is entirely removed from the equation.

Modern API Lifecycle Management

In this revolutionary age for software, the rapid rate at which new architectural patterns have emerged has significantly impacted the way enterprises are now choosing to build, deploy and consume services. These changes have also welcomed innovative approaches to project workflows, opening the doors for DevOps and engineering teams to automate key areas of their API lifecycles and simplify complexity across the board.

When thinking about the modern API lifecycle, many organizations are now striving to provide reliable, secure and observable connectivity for all services across any infrastructure. As applications become increasingly interconnected across environments, the traditional API gateway has transitioned from a heavyweight ‘point solution’ into a lightweight and extensible Swiss Army knife for multi-purpose connectivity.

The modern API gateway now supports protocols like GraphQL, Kafka and gRCP, as well as an extensive plugin library for rate limiting, authentication, authorization, advanced load balancing, caching, health checks and much more. Finally, the next-generation API gateway has become a one-stop-shop for enacting modern transformations – making it a truly compelling course of action for achieving end-to-end connectivity in any and all environments of your organization’s choosing.


At its core, the API gateway is a very configurable and declareable reverse proxy. As APIs and microservices become increasingly relied upon to operate digital businesses today, the API gateway has been selected by many organizations as the go-to interface for enabling clients to interact with their system and manage requests in a convenient, centralized manner.

Like a smart grid for the cloud, the modern API gateway is extensible by nature and can quickly adapt to the requirements of the environment it is deployed in. Built with efficiency, resiliency and architectural freedom in mind, you can be rest assured that as your system expands and changes in functionality, the next-generation API gateway will meet your present and future infrastructure needs and will continue to deliver value over time as your business scales.

Check out how we compare against our competitors with our Kong API vs Google Apigee tool.