In this exploration, we dive into the evolution of the API Gateway. Our focus will be on its origins, its current state, and its potential future.

We propose that API Gateways are navigating through a phase of feature unbundling, which will soon usher in a wave of feature rebundling.

This transition promises to drive the industry toward a more sophisticated and versatile application of APIs. Read on to learn more about our predictions and schedule your demo to see how we’ve modernized API security.

First Generation: Designed for the Data Center

Back in the early 2000s API adoption was starting to gain momentum in the enterprise. This, of course, was before the cloud and most enterprises were still deploying racks of servers in data centers. As with any new technology, problems began to arise and API Gateways were developed to provide:

1. Centralized Management: As the number and complexity of APIs grew, managing them individually became an overwhelming and error-prone task. Centralized management through API Gateways drastically simplified this process, reducing complexity, and minimizing potential errors. It ensures uniformity in dealing with different APIs and made it easier to enforce global policies and procedures, thereby improving overall application performance and efficiency.
2. Load Balancing: With the number of services and users increasing, efficiently managing traffic became paramount to ensure optimal application performance. API Gateways managed load balancing across multiple APIs, efficiently distributing network traffic to prevent bottlenecks and ensure smooth operation. This prevented certain services from becoming overloaded, leading to latency issues and even system failures.
3. Security:  APIs, being points of interaction between different services (often over public networks), can be vulnerable to numerous types of cyberattacks. API Gateways provided necessary security measures like authentication, encryption, and rate limiting, and protected against attacks such as SQL injection or DDoS.

Examples of the first API Gateways founded in the early 2000s:

• Apigee: Founded in 2004 as Sonoa Systems before being renamed in 2010, Apigee developed one of the industry’s first API management platforms. Google later acquired it in 2016.
• Mashery: Established in 2006, Mashery offered an early API management solution providing a combination of proxy and packaging functionality. Intel acquired Mashery in 2013, and it later became part of Tibco Software.
• 3scale: Founded in 2007, 3scale delivered a comprehensive API management platform allowing users to manage, distribute, control, and monetize their APIs. Red Hat acquired it in 2016.
• Layer7 Technologies: Founded in 2003, Layer7 Technologies (initially known as Reactivity) was an early leader in API security and management. CA Technologies acquired it in 2013, and it’s now part of Broadcom.
• Kong was founded in 2007 as Mashape by Augusto Marietti and Marco Palladino. Initially, Mashape was a marketplace for APIs, which later evolved to provide the open-source API Gateway known as Kong. In 2017, Mashape’s API Gateway component was rebranded as Kong Inc, while the API marketplace was spun off into a separate company.
• MuleSoft was founded in 2006 by Ross Mason. The company was named after the “mule” software program, which was designed to handle the heavy lifting of connecting different platforms. MuleSoft’s Anypoint Platform, which includes an API Gateway among other capabilities, is well known for enabling businesses to design, deploy, and manage APIs.
• Axway

Note: Even though some of these API Gateways were initially released in the early 2000s before the rise of the cloud, they have since evolved to add limited support for the cloud.

The Second Generation: From API Gateway to Service Mesh

The second generation of API Gateways was developed in the 2010s. Designed in the cloud era, these modern API Gateways solved similar problems around management, load balancing, and security, but were optimized for the cloud.

Because cloud-native architectures are built using many microservices, this next generation of API Gateway needed to work seamlessly with the orchestration layers of various virtualization technologies (like Kubernetes or Docker) to handle the rapid changes in underlying infrastructure.

Examples of second generation API Gateways founded in the 2010s:

• Tyk is a leading open-source API Gateway and API Management Platform that was founded in 2014 by Martin Buhr. It offers an array of services such as API management, API analytics, developer portal, and API lifecycle management.
• Envoy: Envoy is an open-source edge and service proxy, designed for cloud-native applications. It was originally built by Lyft and is now a graduated project within the Cloud Native Computing Foundation (CNCF). Released in 2016, Envoy is not an API Gateway itself but often serves as a foundational component in other API Gateways or service meshes due to its capabilities around service discovery, load balancing, TLS termination, HTTP/2 and gRPC proxies, circuit-breakers, health checks, staged rollouts, fault injection, and rich metrics. I actually had the opportunity to work with the Envoy team during my time at Signal Sciences as one of the first companies to support it.
• Linkerd: Linkerd is an ultralight, performance-optimized service mesh for Kubernetes. It was created by Buoyant and was one of the first projects to be incubated by the CNCF. Like Envoy, Linkerd is not technically an API Gateway, but a service mesh — a dedicated infrastructure layer for handling service-to-service communication in microservices architectures. Released in 2016, Linkerd provides features such as load balancing, service discovery, failure handling, instrumentation, and routing, among others.
• APISIX: APISIX is an open-source, cloud-native microservices API Gateway, delivering high-performance and dynamic routing to any service. It’s developed by Apache and was first released in 2019. APISIX provides dynamic load balancing, authentication, rate limiting, and other features provided by traditional API Gateways. It’s also designed to handle service-to-service communication and can be used in lieu of a service mesh in certain cases. It’s built on top of the Nginx server and uses etcd as its underlying distributed configuration storage.

Importantly, many of the second generation API Gateways are open source and part of the CNCF, which means that the pace of innovation is tied to the blazing-fast evolution of the cloud. The second generation of API Gateways has been able to meet, and in some cases, exceed the capabilities in the first generation of API Gateways in just a few years without having the same feature bloat of first-generation solutions.

The Future of API Gateways

The rapid innovation in the cloud and within free, open-source software  is ushering in a new era where API Gateways are gradually becoming commoditized, with basic functionalities becoming a standard across various free offerings.

This commoditization doesn’t signify the end of innovation in this space. Instead, it marks the beginning of a new phase of specialization and refinement.

We anticipate the emergence of new, specialized API Gateways. These solutions will not necessarily reinvent the wheel. We believe they will focus on solving the same problems that existing API Gateways address, however, they will differentiate themselves by tackling these problems in superior ways.

As an API Security company, we have some ideas about what those might be, and we will share that in a later blog post!

Follow us on LinkedIn to stay tuned for that post, and if you’d like to learn more about Impart’s integrated API security solution, schedule your live demo.