Increased security and enhanced visibility through new plugins in Kong Enterprise 3.1 Learn more

What is an API Gateway?

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. The solution? API Gateways.

What is an API Gateway?

An API gateway is an intermediary that sits between your backend services and your clients. 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. They enable communication between different internal and external business applications, such as: request routing, API composition, and other cross-cutting concerns. 

API Gateway vs Microserivces

API gateways are a common pattern in microservices architectures. By providing a single point of entry for all of your backend services, they make it easier to build, deploy, and manage your overall system. They can also help address some of the challenges that come with microservices, such as managing cross-cutting concerns and dealing with service discovery. 

In a microservices architecture, each backend service is typically a stand-alone application. This can make it difficult to route requests from clients to the correct service, as well as to compose multiple services into a single response. An API gateway helps to solve these problems by acting as a single point of entry for all backend services. 

What are the benefits of using API Gateways?

API gateways can be a helpful addition to a microservices architecture. By providing a single point of entry for all backend services, they can make it easier to build and manage your system. This helps provide a number of benefits, including:

Reduced complexity

By routing requests through a single entry point, they can help to reduce the overall complexity of your system. This is especially helpful when you have many different backend services. This is done by simplifying the interface to your application and combining multiple requests into a single one, or by transforming requests so that they’re more easily processed by your backend systems. This can make your application much easier to use for both developers and end users.

Improved performance

API gateways can cache commonly used and requested data and distribute load across multiple servers. This which means that your application doesn’t have to go to the trouble of fetching it each time it receives a request. This can lead to significant performance improvements. 

Security

API gateways can provide an additional layer of security by authenticating and authorizing requests before they reach your backend services. By sitting in front of your application, they can act as a barrier between it and the outside world, filtering traffic and only allowing through requests that meet your security criteria.

Transformation of API Lifecycle Management

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, REST 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.

First-Generation

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 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 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

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 – 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.

Conclusion

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 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.