Evolution of API Gateways — A Glimpse
Digital transformation of an enterprise invariably includes adoption of API Gateways as a key product in the architectural landscape. The driving factor of it’s wide adoption is mainly around its capabilities in addressing the product wide cross cutting concerns & its rich ecosystem offering which the enterprises are hugely benefited from!
It’s really worth to look back in history and understand what had led to the evolution of these API Gateways in a state where it is right now. In the book, Mastering API Architecture, the authors James Gough, Daniel Bryant & Matthew Auburn, have extensively covered these details!
“ History is philosophy teaching by examples.” — Thucydides
Late 1990s Landscape
Rise of Hardware Load Balancers
The Web 1.0 experience consisted of users visiting web sites, making HTTP requests using their browser, and the entire HTML document for each target page being returned in the response.
Increasing number of users accessing each website, resulted in straining the underlying web servers. This added the requirement to design systems that supported spreading the increased load and also provide fault tolerance.
Hardware load balancers were deployed at the edge of the data center, with the goal of allowing infrastructure engineers, networking specialists, & sysadmins to spread user requests over a number of web server instances.
These early load balancer implementations typically supported basic health checks, and if a web server failed or began responding with increased latency then user requests could be routed elsewhere accordingly.
Early 2000s Landscape
Rise of Software Load Balancers
The increasing requirements for high availability & scalability of web sites and the expense & inflexibility of early hardware load balancers was beginning to become a constraining factor.
This led to the birth of Software load balancers, with HAProxy being launched in 2001 and NGINX in 2002.
The target users were still operations teams, but the skills required meant that sysadmins comfortable with configuring software-based web servers were increasingly happy to take responsibility for what used to be a hardware concern.
This time frame also saw the rise of other edge technologies that still required specialised hardware implementation.
- Content Delivery Networks (CDNs), primarily driven by the Telco organisations, began to be increasingly adopted in order to offload requests from origin web servers.
- Web Application Firewalls (WAFs) also began to see increasing adoption, first implemented using specialised hardware, and later via software. The open source ModSecurity project, and the integration of this with the Apache Web Server, drove mass adoption of WAFs.
Mid 2000s Landscape
Rise of Application Delivery Controllers (ADCs)
In mid 2000s, emergence of Internet-capable phones accelerated the pervasiveness of the web in everyday life, with BlackBerry initially leading the field, and everything kicking into a higher gear with the launch of the first iPhone in 2007.
All of these changes placed new demands on web servers and load balancers, for yet again handling — more load, more secure traffic, large data payloads & different priority requests.
This led to the emergence of a new technology named Application Delivery Controllers (ADCs). As these were initially implemented using specialised hardware this led to the existing networking players like F5 Networks, Citrix, Cisco dominating the market. ADCs provided support for compression, caching, connection multiplexing, traffic shaping, and SSL offload, combined with load balancing.
The target users were once again infrastructure engineers, networking specialists, and sysadmins.
Early 2010s Landscape
Birth of First Generation API Gateways
Early 2010s saw the emergence of the API economy & associated technologies.
Organisations like Twilio were disrupting telecommunications, with their founder, Jeff Lawson, pitching that “We have taken the entire messy and complex world of telephony and reduced it to five API calls.” The Google Maps API was enabling innovative user experiences, and Stripe was enabling organisations to easily charge for access to services.
Founded in late 2007, Mashape was one of the early pioneers in attempting to create an API marketplace for developers. Although this exact vision didn’t pan out, a byproduct of the Mashape business model was the creation of the Kong API Gateway, built upon OpenResty and the open source NGINX implementation.
Other implementations included WSO2 with Cloud Services Gateway, Sonoa Systems with Apigee, and Red Hat with 3Scale Connect.
These were the first edge technologies that were targeted at developers in addition to platform teams and sysadmins.
A big focus was on managing the software development lifecycle (SDLC) of an API and providing system integration functionality, such as endpoints and protocol connectors, and translation modules. Due to the range of functionality offered, the vast majority of first generation API gateways were implemented in software.
Developer portals sprang up in many products, which allowed engineers to document and share their APIs in a structured way. These portals also provided access controls and user/developer account management, and publishing controls and analytics. The theory was that this would enable the easy monetisation of APIs, and the management of “APIs as a product”.
During this evolution of developer interaction at the edge there was increasing focus on the application layer (layer 7) of the OSI Networking model. The previous generations of edge technologies often focused on IP addresses and ports, which primarily operate at the transport layer (layer 4) of the OSI model. Allowing developers to make routing decisions in an API gateway based on HTTP metadata such as path-based routing or header-based routing provided the opportunity for richer functionality.
With the first generation of API gateways it was often the case that both functional and cross-functional concerns, such as routing, security, and resilience, were performed both at the edge and also within the applications and services.
2015 Landscape
Rise of Second Generation API Gateways
The mid 2010s saw the rise of the next generation of modular and service-oriented architectures, with the concept of “micro-services” firmly entering the zeitgeist by 2015.
Docker was released in March of 2013, and Kubernetes followed with a v1.0 release in July of 2015. This shift in architectural style and changing runtimes drove new requirements at the edge.
Netflix released their JVM-based API gateway, Zuul, in mid 2013. Zuul supported service discovery for dynamic back end services and also allowed Groovy scripts to be injected at runtime in order to dynamically modify behaviour. This gateway also consolidated many cross cutting concerns into a single edge component, such as authentication, testing (canary releases), rate limiting and load shedding, and observability.
Zuul was a revolutionary API gateway in the micro-services space, and it has since involved into a second version, and Spring Cloud Gateway has been built on top of this.
With the increasing adoption of Kubernetes and the open source release of the Envoy Proxy in 2016 by the Lyft team, many API gateways were created around this technology, including Ambassador, Contour, and Gloo.
This drove further innovation across the API gateway space, with Kong mirroring functionality offered by the next generation of gateways, and other gateways being launched, such as Traefik & Tyk.
Increasingly, many of the Kubernetes Ingress Controllers called themselves “API gateways”, regardless of the functionality they offered, and this led to some confusion for end users in this space.
The target users for the second generation of API gateways was largely the same as for the first generation, but with a clearer separation of concerns and a stronger focus on developer self-service.
The move from first to second generation of API gateways saw increased consolidation of both functional and cross-functional requirements being implemented in the gateway.
2017 post Landscape
Service Mesh and/or API Gateway
In early 2017 there was increasing buzz about the use of “service meshes”, a new communication framework for micro-service based systems.
The early service meshes exclusively targeted the east-west, service-to-service communication requirements. Service meshes evolved from early in-process micro-service communication and resilience libraries, such as Netflix’s Ribbon, Eureka, and Hystrix.
Buoyant’s Linkerd was the first service mesh to be hosted by the CNCF, but Google’s Istio captured the attention of many engineers.
Although there is a lot of functional overlap between service meshes and API gateways, and much of underlying proxy (data plane) technology is identical, the use cases and control plane implementations are at the moment quite different.
Several service meshes offer ingress and gateway-like functionality, for example, Istio Gateway and Consul Ingress Gateways. However, this functionality is typically not as feature-rich or as mature as that currently offered by existing API gateways. This is why the majority of modern API gateways integrate effectively with at least one service mesh.
