The Office of the CTO team at F5 has been exploring the technology field related to APIs for over a year now. This latest white paper is a continuation of our efforts to understand the ever-evolving API ecosystem.
Les défis que nous avons détaillés dans la gestion de la prolifération des API entraîneront des défis liés à la prolifération des passerelles API, et les approches traditionnelles pour relever ces défis ne seront pas suffisantes. Bien que les technologies graphiques telles que GraphQL soient très prometteuses pour maîtriser la complexité associée aux API, elles ne constituent qu’une partie de la solution, car les défis vont au-delà de la connectivité, de la sécurité et du routage. La bonne approche, basée sur près de trente ans d’expertise en matière de mise à l’échelle de systèmes et d’applications, repose sur une architecture distribuée, et non fédérée, qui utilise GraphQL mais ne s’appuie pas uniquement sur lui.
This paper explores a distributed architectural approach to addressing the challenges of API gateway sprawl.
The digital economy will be powered through APIs, giving us an API-driven economy. Following the API Sprawl white paper, our pursuit was to understand how to eliminate or alleviate the impact of API sprawl. While GraphQL seemed promising to reduce the ramifications of API sprawl, it tends to put the onus on developers to rewrite a large part of their API codebase. However, an emerging viewpoint around GraphQL is its ability to be used as an effective gateway actor. The gateway actor is a function or process created near the client that initiates an API request. This gateway actor acts as the initial API gateway terminating the API request. It can also be ephemeral, such that it can be destroyed after servicing the request.
In addition to developers and operations teams prioritizing API management over API gateways, we also discovered the issue of API gateway sprawl because of API sprawl. From a developer's perspective, the main concern is ensuring the API functions correctly and in a timely manner. On the other hand, the operations team is more focused on aspects such as discovery, security, usability, and access controls. Since API gateways today are a critical component of API infrastructure, it became evident that the proliferation of APIs increases the deployment of API gateways—leading to API gateway sprawl.
The future of the API architecture needs to evolve to accept API sprawl while simplifying deployment and operations. The architecture proposed is the next evolution of where API gateway design patterns need to be. While GraphQL is not central to the architecture, or a necessity, it has an ability to enhance the gateway actor pattern.
The API management ecosystem must move away from managing API gateway monoliths towards a more contemporary system design approach. This will result in a more agile and effective API management ecosystem.
API sprawl, already a challenge within the API economy, also results in API gateway sprawl, a situation where managing APIs has become uncontrollable due to diverse API gateway vendor technologies and opinionated teams managing the API gateways. We are at an inflection point in API architectures as the legacy API gateway (API-GWs)—a dedicated software layer that acts as the entry point for API calls—is no longer sufficient to manage the scale and complexity of the emerging API ecosystem.
La figure 1 illustre comment nous sommes passés de la gestion de la prolifération des API à la gestion de la prolifération des passerelles API.
The design pattern above alludes to a centralized control plane, with the API gateways forming the distributed data plane as shown in Figure 2.
Les passerelles API sont un composant essentiel des architectures logicielles modernes, fournissant un point central de contrôle et de sécurité pour les API. Cependant, à mesure que le nombre de fonctionnalités offertes par les passerelles API a augmenté, elles sont devenues de plus en plus complexes et difficiles à gérer. Dans de nombreux cas, ces passerelles ont évolué vers des systèmes monolithiques, avec une large gamme de fonctionnalités regroupées dans un seul package.
While managing multiple gateways may appear to be a distributed design, the reality is that it falls short of true distribution. This is because the gateways are still tightly coupled, sharing resources and configurations that are difficult to separate. As a result, many enterprises end up managing distributed monoliths and all the challenges that creates.
Figure 3 shows the architecture of existing API gateways. API requests originating from the client are first transmitted via a shared or dedicated network, passing through a firewall before reaching the API gateway. The API gateway, which acts as a reverse proxy, then forwards the traffic to the API workload.
L'API-GW héritée devient un point d'étranglement de gestion des API lorsque les passerelles API sont déployées dans toute l'entreprise ou lorsque les charges de travail des API se déplacent de manière opérationnelle entre des régions, des zones, plusieurs clouds ou vers la périphérie tout en luttant contre la prolifération des API. Plusieurs API-GW sont créées par différentes équipes sans point unique de gestion et de contrôle d'entreprise. Si un individu ou un groupe de services API se déplace vers une infrastructure différente (cloud ou autre), l'équipe d'exploitation doit disposer d'une méthode pour migrer tous les aspects de la gestion des API : enregistrement, découverte, authentification, mise en réseau, sécurité et politiques de gouvernance, de risque et de conformité (GRC).
The architecture depicted in Figure 3 is thus not scalable or practical long term, as over time it leads to managing distributed monoliths (Figure 2).
There are two problems creating the API gateway choke point: (1) API gateway vendor sprawl, and (2) scale as you go when an enterprise has more applications running in more places.
Figure 4 depicts a distributed gateway actors’ pattern to address API gateway sprawl. While the distributed pattern itself is not new, this paper formalizes it within the context of API gateways. The clients initiate the API request. The distributed gateway actors are ephemeral and instantiated on-demand as close to the client as possible. It becomes the responsibility of the API transport layer to send the API request from the gateway actor to the simplified API gateway, which then routes the request to the appropriate API workload. While the use of GraphQL support in the distributed actors is more of a detail than a requirement for this pattern to work, it does enable supporting features like service orchestration. So instead of creating a new service orchestration layer, GraphQL could provide that support.
To clarify, the traffic pattern is from right to left. That is, the clients are on the right and the API requests are initiated by the client as shown in Figure 5.
There is an emerging deployment pattern using gateway actors to replace or reduce over dependency on API gateways for managing APIs within and across an enterprise. While GraphQL is not necessary for the architecture, the introduction of it is timely as the gateway actor is the right vehicle to support GraphQL.
Pour acquérir une compréhension plus approfondie de l’acteur passerelle en tant que solution potentielle, il est nécessaire d’examiner de près l’état actuel des infrastructures API, en particulier des passerelles API. Cela est dû au fait que nous avons identifié l’étalement des passerelles comme un facteur important contribuant aux défis liés à l’exploitation et à la mise à l’échelle des infrastructures API.
To gain a better understanding of API gateways, it is important to first examine the various components of the modern API management infrastructure.
Figure 6 offers a comprehensive visual representation of the various features and components that are integral to API management. In addition to API gateways, which are required for routing and managing traffic to backend services, there are several other important infrastructure components. These may include solutions for authentication, rate limiting, caching, and service mesh, among others. By incorporating these features, organizations can achieve control over their APIs, enhance security, and optimize performance.
Let us examine the commonly recognized and familiar features of API gateways:
After analyzing API management infrastructure features, we identified the need to better understand the role of API gateways and explore alternatives to the current monolithic API gateway design.
With the growth in the number of APIs already leading to API sprawl and API gateway sprawl, an increasing number of clients are becoming mobile or highly distributed, and compute infrastructure has become available everywhere, including at the edge. We thus need an approach which can improve the agility, flexibility, scalability, performance, and security of the API ecosystem.
This new approach requires a streamlined design capable of fully leveraging the benefits of a truly distributed architecture.
We further analyze the functionality and scope of an API gateway to tease out its nuances and limitations.
An API gateway is a critical component of today’s API management infrastructure. At its core, the API gateway is a reverse proxy; it acts as a middleman between clients and backend services while performing a variety of tasks on the incoming request. For example, the gateway can authenticate, rate limit, request route, apply security policies, monitor, and apply versioning before forwarding the request to an appropriate backend service. Once the backend service has processed the request and returned a response, the API gateway can perform tasks such as caching, protocol translation, and response handling before forwarding the response back to the client.
As the number of APIs have grown, API gateways have evolved to include a variety of new functionalities beyond basic routing, effectively becoming monolithic systems. These gateways now manage tasks like authentication and rate limiting to improve performance and reduce the burden on backend services. However, even with this enhanced functionality, API gateways remain a single access point to the backend service, which can present challenges in highly distributed environments.
In particular, the rise of cloud, hybrid multi-cloud, and edge infrastructures has made it more difficult to maintain agility, security, and manageability with an API gateway approach. With clients, devices, and application workloads potentially spread out across a wide range of locations, an API gateway may not be well suited to provide the necessary level of edge-friendly architecture.
Since they handle a wide range of tasks and need to integrate with multiple systems, API gateways are typically hard to deploy and manage. While managing API gateways can be complex, it is nevertheless a critical task for ensuring the availability, security, and scalability of an API. Enterprises tend to use specialized tools, such as API management platforms, to help manage and monitor their API gateways more effectively.
The list below is not comprehensive, but some of the elements contributing to API gateway complexity include:
API gateway sprawl refers to the proliferation of multiple, independent API gateways within an organization. Different teams or business units often create their own APIs, which can lead to the creation of multiple, independent API gateways to handle these different APIs. Different teams may also use API gateways from different vendors or solutions to handle different types of APIs.
Cela conduit au déploiement de plusieurs passerelles API, toutes dotées de différents ensembles de capacités.
API gateway sprawl creates several additional challenges:
Enterprises should strive to centralize their API management and governance and use a single type of API gateway. While this will alleviate the above challenges of API gateway sprawl, a homogenized strategy for API gateways is anything but simple.
As enterprises grow organically or through acquisitions, internal teams aligned to specific business units (BUs) will be at odds with each other while selecting an API gateway technology or vendor. Some reasons for this include the following:
Ainsi, si une application existante dispose d’une équipe bien établie et avisée, l’équipe ne voudra pas pivoter vers un modèle de déploiement différent afin de ne pas perturber son service.
Nous pouvons donc conclure qu’il est nécessaire d’adopter une nouvelle approche qui prenne en compte les multiples limitations de l’infrastructure API existante tout en soulignant la prolifération des passerelles API comme l’une des considérations les plus importantes.
La liste suivante n’est pas exhaustive, mais résume certaines des considérations de conception de haut niveau qui, selon nous, devraient être intégrées lors de la création de la solution :
Specific requirements can be derived based on these design considerations, which we’ve incorporated into our distributed gateway actors (DGA) solution.
Now having fully explored API gateways, we can explain the distributed gateway actor solution.
Le modèle de conception des acteurs de passerelle distribuée (DGA) s'inspire de l'informatique de pointe et de l'informatique disponible à proximité d'un client. L’essentiel de l’idée réside dans l’hyper-distribution de chaque acteur de passerelle aussi près que possible du client et dans le fait que l’acteur de passerelle n’existe que pendant la durée de la transaction avant qu’elle ne soit compensée à la fin.
Voici quelques-unes des hypothèses sous-jacentes à cette solution.
Edge compute has become more pervasive, and we can now find some type of compute that is geographically available closer to the client. The gateway actors can be instantiated on these edge compute nodes. The intent is to have an implementation where the DGA is very lightweight and ephemeral so it can be instantiated on any edge compute.
API transport is a crucial component of the infrastructure since it involves establishing a network between the gateway actors and the API gateway. The type of infrastructure required is dependent upon the vendor or enterprise and can vary. For example, a large public cloud may use their own backbone to run the API transport. Another implementation could be a low-latency messaging bus layered on top of an existing high-bandwidth and low-latency network within an enterprise data center.
Pour réitérer, la passerelle API est essentiellement un proxy inverse dont la fonction principale est d’acheminer le trafic HTTP vers les charges de travail API appropriées. Cette approche est logique lorsque toutes les API sont regroupées, comme au sein d’un réseau local sur site ou au sein d’un cloud privé virtuel (VPC) à l’intérieur d’une zone de disponibilité. Mais à mesure que le nombre d'API augmente, se déplace sur une infrastructure hybride ou devient simplement mobile, cette approche de conception de passerelle API devient inefficace, complexe à exploiter et coûteuse.
Bien qu’il puisse y avoir des points de vue différents sur la manière de classer toutes les fonctionnalités décrites dans la figure 6, nous pouvons convenir que l’infrastructure de gestion des API est devenue un déploiement complexe de nombreux composants qui doivent être soigneusement orchestrés.
La figure 7 illustre les différentes fonctionnalités et fonctions de la gestion des API de la figure 6 à l’architecture des acteurs de la passerelle distribuée. Cette cartographie illustre visuellement comment chaque fonctionnalité et fonction est alignée sur l'approche DGA, mettant en évidence l'intégration transparente des composants de gestion des API au sein de l'architecture.
Most of the features listed above have some management component which can be logically centralized. Our goal is not to rearchitect the management plane but, if possible, remove certain functions.
These are data plane functions and thus best implemented in the API and collocated with application workloads. API gateways are a crucial component of modern microservices architecture that serves as the entry point for all external traffic. We categorized its core functions to include routing, load balancing, dynamic routing, health checking, retries, and fallbacks.
An API gateway directs incoming requests to the appropriate microservice, distributes traffic across multiple instances, supports dynamic routing, monitors the health of microservices and their instances, retries failed requests, and provides fallback responses when a microservice is unavailable or has failed. Other functions such as authentication, authorization, rate limiting, caching, and logging can be distributed to the edge or centralized functions depending on the specific requirements of the system.
Cette approche modulaire permet une architecture plus flexible et optimisée et est au cœur de notre recommandation pour simplifier, moderniser et faire évoluer l’infrastructure API de l’entreprise.
API gateway and API management are often mistakenly conflated by vendors as part of the API gateway function, but they are actually two distinct functions that should be treated separately. An API gateway is responsible for routing requests from clients to backend services, while API management encompasses a broader set of features such as access control, rate limiting, analytics, and developer portal management.
Bien que certains fournisseurs puissent proposer à la fois des fonctions de passerelle API et de gestion des API dans le cadre d'un seul produit, il est important de comprendre les différences entre ces fonctions et de les évaluer séparément en fonction de leurs besoins spécifiques. La combinaison de ces fonctions peut entraîner une confusion et potentiellement limiter la flexibilité et l'évolutivité de l'infrastructure API d'une organisation. Ceci est également essentiel pour comprendre notre position sur la distribution de la fonctionnalité de passerelle API.
The features listed here are core functions which need to be inline to the data path. In a distributed gateway pattern, some of the inline functions of the API gateway also become distributed. These functions include access control, rate limiting, request validation, API analytics, usage reporting, error rate monitoring, alerting and eventing, auth integration, third-party integration, monitoring and logging integration, edge caching, and compression.
Moving these functions to the distributed gateway pattern has the following benefits:
Par exemple, le contrôle d’accès, la limitation du débit et la validation des demandes peuvent être gérés par un acteur de passerelle de périphérie, qui est déployé plus près des clients. Cela peut aider à réduire le nombre de requêtes devant être traitées par la passerelle API centralisée, améliorant ainsi ses performances et son évolutivité. De même, les analyses d’API, les rapports d’utilisation, la surveillance du taux d’erreur, les alertes et les événements, ainsi que l’intégration de la surveillance et de la journalisation peuvent être gérés par des passerelles périphériques, qui peuvent collecter et agréger des données à partir de plusieurs microservices.
Aujourd’hui, une capacité importante prise en charge par les passerelles API est la composition et l’orchestration des services. Bien que cela puisse devenir assez complexe, cela deviendrait un problème si cette fonctionnalité n’était pas prise en charge par la passerelle API simplifiée. Nous pensons que GraphQL peut être une approche intéressante pour la composition de services, agissant comme une sorte de middleware pour les API existantes.
Due to its visibility of all the APIs, the API gateway becomes a logical place to perform service composition, enabling developers to combine the APIs behind the gateway to enhance the business logic without needing to write new services which can be more easily combined in a service composition layer.
Service composition in GraphQL is made possible through its use of a strongly typed schema, which defines the shape of the data available to clients. Clients can use this schema to construct queries that specify the exact data they need, regardless of which services or sources provide it. Resolvers, which are functions that map queries to data sources, are used to retrieve data from the appropriate service or source. However, while GraphQL promises better security, it is only as good as the developer who writes the code.
There are still some remaining features not highlighted from Figure 6: API management and infrastructure features. These remaining features and functions are candidates that can be moved to individual management and operations or data-plane functions.
We deliberately choose to use the term “actor” to avoid suggesting a specific implementation or vendor technology. The gateway actor’s implementation could be based on methods, functions, workers, threads, and processes, implemented using infrastructures based on VMs, containers, serverless, or other approaches specific to a vendor.
The approach taken with the distributed gateway actors (DGA) architecture simplifies the API gateway functions and moves other inline features either to the edge, or to the control plane.
Outre les fonctionnalités de la passerelle API, l’architecture DGA recommande également d’identifier les fonctions qui pourraient être mieux servies dans le plan de contrôle en tant que composant logiquement centralisé plutôt qu’implémentées dans une passerelle API monolithique. La gestion et le contrôle de l’infrastructure API déjà existante peuvent être étendus et développés pour inclure cette fonctionnalité supplémentaire.
The simplification of the API gateway thus becomes an exercise to derive a standard set of core functions that all API gateway vendors can manage through a common set of config parameters.
An enterprise wanting to make this transformation could roll out the DGA architecture one application at a time, without disturbing the existing deployments and without the need for a forklift operation.
An important aspect of the DGA is that each gateway actor is ephemeral, being instantiated only for the duration of an API session (i.e., one client making one API call).
Un acteur de passerelle distribué peut être plus flexible, évolutif et rentable que la passerelle API traditionnelle. Plutôt que de s'appuyer sur plusieurs passerelles API monolithiques de différents fournisseurs pour agréger et gérer le trafic API, l'acteur de passerelle permet aux développeurs de spécifier et de déployer des instances de passerelle individuelles pour chaque API plus proche de la périphérie du réseau. Les API elles-mêmes pourraient offrir un meilleur contrôle et une meilleure personnalisation pour répondre à leurs besoins spécifiques.
This new approach also allows for greater scalability, as developers can easily spin up the gateway actor instances as needed to handle increased traffic without worrying about the overhead of managing a large, centralized gateway.
In addition to its technical benefits, the gateway actor also offers cost savings over the traditional API gateway, by allowing enterprises to only pay for the ephemeral gateway actor instances they use. This deployment model can open opportunities for additional revenue models.
By leveraging an API transport layer, the DGAs essentially decouple the API ingress location from the API gateway. The DGAs can be moved to the edge, i.e., closer to the client making the API call. The APIs can terminate in the DGAs and then be transported by any means. This is different from Figure 3: Legacy API gateway architectures where the client traffic ingresses topologically adjacent to the API gateways.
Notre intention a donc été de proposer une approche indépendante du fournisseur et du déploiement, car différents fournisseurs peuvent avoir leur propre propriété intellectuelle pour créer ces composants afin d'atteindre des objectifs similaires à ceux décrits.
Dans cet article, nous avons résumé nos apprentissages issus de plusieurs études sur la prolifération des API , les architectures Edge 2.0 , l’ économie des API et les enquêtes sur GraphQL. Bien que le jury n’ait pas encore rendu son verdict concernant l’infrastructure API existante, nous pensons qu’une nouvelle approche est nécessaire.
Just the promise of unlocking value within every individual device or entity globally provides a strong enough reason to explore a new approach. We need to move away from the legacy API infrastructure today, because even though it looks distributed, it is monolithic under the hood.
We propose the distributed GraphQL based gateway actor approach as a vendor agnostic way to unlock the full potential of the emerging API economy.