Distributed Gateway Actors: Evolving API Management
Table of Contents
F5 Avis du Bureau du CTO
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.
Abstract
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.
Résumé
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 Gateway Sprawl – Managing Distributed Monoliths
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.
Legacy API Gateway Architectures
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.
- API gateway vendor sprawl: Dealing with API gateway vendor sprawl is a human challenge, as it can be difficult to convince all teams to adopt a single API gateway vendor, and migrating to a new vendor can be a cumbersome task. As a result, organizations end up spending time and resources managing multiple gateway vendors. Although this problem can be addressed, it may not be entirely feasible in reality.
- Application scaling: Scaling applications is a problem when the application needs to support more users within a single location or needs to be deployed at multiple locations. This requires the application to scale horizontally or vertically. However, as the application scales, the API gateways need to scale as well, and in some cases, they need to be deployed at multiple locations to support the scaling based on current architecture patterns. This can make managing the API gateways operationally complex.
Solution: A Distributed Gateway Actor Pattern
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:
- Routing: Routes requests to the appropriate backend service based on the path or content of the request.
- Authentification et autorisation : Authentifie et autorise les demandes en tant que point d'entrée unique, garantissant que seuls les clients autorisés peuvent accéder aux services back-end.
- Rate limiting: Limits the rate at which clients can make requests to the underlying APIs, preventing overuse and protecting the backend services from overload.
- Caching: Caches responses from the underlying APIs, reducing the number of requests needed to be made to the backend services and improving performance.
- Protocol translation: Translates between different protocols, such as HTTP and WebSockets, allowing clients to access the underlying APIs using different protocols.
- Load balancing: Distributes requests to multiple backend services, improving scalability and reliability.
- Security: Handles security tasks, such as encryption and decryption, to ensure data is transmitted securely.
- Analyse et surveillance : Suivi et rapport des mesures d'utilisation et des informations sur les erreurs, offrant une visibilité sur la manière dont le système est utilisé et aidant à identifier les goulots d'étranglement et les erreurs de performances.
- Versionnage : Gère le versionnage des API sous-jacentes, permettant aux clients d'accéder à différentes versions de l'API en fonction de leurs besoins.
- Service discovery: Discovers available backend services and dynamically route requests to them, allowing for more dynamic and flexible service discovery.
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:
- Gestion de la configuration : Les passerelles API disposent souvent d'une large gamme d'options de configuration et de paramètres qui doivent être gérés et maintenus, tels que les règles de routage, la limitation de débit et les paramètres de sécurité. La gestion de ces paramètres peut être complexe et prendre du temps, en particulier lorsque le nombre d’API et de clients sous-jacents augmente.
- Intégration avec d’autres systèmes : Les passerelles doivent s’intégrer à un large éventail d’autres systèmes, tels que les systèmes d’authentification et d’autorisation, les équilibreurs de charge et les bases de données. Cela peut être complexe, en particulier lorsque les systèmes sous-jacents ne sont pas bien intégrés ou lorsque la passerelle API doit gérer plusieurs protocoles ou formats de données. Cela devient plus problématique lorsqu’une entreprise dispose de plusieurs déploiements de passerelles API provenant de plusieurs fournisseurs.
- Évolutivité et disponibilité : Les passerelles API doivent être capables de gérer un grand nombre de requêtes et de garantir une haute disponibilité, ce qui peut être complexe à gérer, en particulier lorsqu'il s'agit d'un grand nombre de services et de clients back-end.
- Sécurité : En tant que composant de sécurité API critique, les passerelles API de sécurité doivent être configurées et gérées pour garantir la protection des données sensibles et le contrôle de l'accès. Cela peut être complexe et nécessite une surveillance et une gestion continues.
- Versionnage : À mesure que le nombre d'API et de clients sous-jacents augmente, il peut devenir de plus en plus difficile de gérer différentes versions de l'API et de garantir que les clients accèdent à la bonne version.
- Monitoring and troubleshooting: API gateways can collect and generate large amounts of data. In a large enterprise the gateways can be distributed across many locations, making it hard to correlate events affecting the overall health of the application and troubleshoot issues.
Prolifération des passerelles API
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:
- Gestion de la passerelle API de mise à l'échelle : Le fait de disposer de plusieurs passerelles API indépendantes peut rendre difficile la gestion et la maintenance des passerelles, en particulier lorsque le nombre d'API et de clients sous-jacents augmente.
- Inefficiencies in east-west traffic: Multiple gateways can result in requests needing to pass through said multiple gateways, adding latency and reducing performance.
- Uniformity of security policies: Managing multiple gateways can be difficult and may lead to inconsistent security policies, making it harder to ensure sensitive data is protected and that access is controlled.
- Gouvernance standardisée : Avec plusieurs passerelles, il peut être difficile de garantir que toutes les API sont correctement régies et conformes aux normes et aux meilleures pratiques.
- Coût accru : Avoir plusieurs passerelles peut entraîner des coûts plus élevés en termes d’infrastructure, de ressources de développement et de maintenance.
- Amplified integration challenges: Having multiple gateways makes it harder to integrate with other systems and technologies, such as other databases, data warehouses, and data analytics tools.
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.
Les défis de la normalisation des passerelles API dans une entreprise
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:
- Technologie : Différentes équipes ou unités commerciales disposent de piles technologiques différentes ou préfèrent différentes solutions de passerelle API, ce qui rend difficile la standardisation sur un seul type de passerelle.
- Systèmes hérités : Certaines équipes disposent de systèmes existants qui ont été créés à l’aide d’un type différent de passerelle API, et il serait difficile de remplacer ces systèmes par une nouvelle passerelle, surtout s’ils sont toujours utilisés.
- Personnalisation : Certaines équipes personnaliseront leurs passerelles API existantes pour répondre à des exigences spécifiques et auront du mal à reproduire ces personnalisations sur une nouvelle passerelle.
- Coût de remplacement : Le remplacement des passerelles API existantes par une nouvelle passerelle standardisée peut être coûteux, tant en termes de développement que de maintenance.
- Training developers: Teams vary in their levels of expertise and may need to become familiar with, or undergo training on, a new gateway technology from a different vendor—a process that can be both time-consuming and expensive.
- Limited resources: Organizations have limited resources in terms of developers, budget, and time to make the change, making it difficult to implement a new gateway.
- Application dependencies: Different teams or business units have different dependencies on their existing gateways, like being integrated with specific systems, or other custom integrations, making it difficult to switch to a new one.
- Third-party solutions: Teams using third-party solutions that integrate with the gateway will find it difficult to migrate to a new solution that doesn't support these third-party solutions.
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.
Considérations relatives à la conception
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 :
- Coexist with current deployments: As organizations strive to keep up with the ever-changing technological landscape, it is common for enterprises to have a diverse range of API gateway deployments. It is not feasible to forklift the existing API infrastructure, as this can disrupt critical business operations. Thus, any new deployment must be designed in a way that can coexist with the currently deployed architecture.
- Standardize API gateway functions: The primary goal of an enterprise's API strategy should be to standardize their API gateway functionality, which can be a challenging task due to the diverse range of APIs and the varying needs of different business units. Nevertheless, this standardization is crucial for creating a stable and secure infrastructure that can support the organization's digital transformation.
- Leverage edge deployments: The edge infrastructure not only has the potential to exponentially increase the number of APIs, but also provides an opportunity for enterprises to move their gateway actors closer to the edge. This is possible as the same infrastructure used to create APIs can also be utilized to create distributed gateway actors. Therefore, the solution must fully leverage the proximity to the edge infrastructure to the clients that initiate the API request.
- Transport agnostique : Une considération importante pour la mise en œuvre de l’architecture des acteurs de passerelle distribuée est qu’elle ne doit pas dépendre d’un mécanisme de transport spécifique. Qu'une entreprise souhaite utiliser des réseaux IP traditionnels, des réseaux superposés, des VPN ou une infrastructure de messagerie à faible latence, la solution doit être indépendante du mécanisme de transport. Cela permet une plus grande flexibilité et permet aux entreprises de choisir le mécanisme de transport qui correspond le mieux à leurs besoins et exigences spécifiques.
- GraphQL support: GraphQL is becoming an increasingly popular choice for API development due to its many advantages over traditional REST APIs. One key advantage is its ability to provide fine-grained access to data, allowing clients to specify exactly what data they need in a single request. Additionally, GraphQL can simplify the process of aggregating data from multiple services, making it the right architecture to do service composability and orchestration. This can reduce network overhead and improve performance, especially in a distributed system where multiple API services are used to fulfill a single request. Finally, with its strongly typed schema and query language, GraphQL can improve API discoverability and enable easier client development.
- La sécurité est un enjeu majeur : L’objectif primordial de la conception est qu’elle s’ajoute à la posture de sécurité des API de l’entreprise. La solution pourrait intégrer certaines fonctionnalités, comme la possibilité d’authentifier et d’autoriser les requêtes API, de mettre en œuvre des contrôles d’accès et de se protéger contre les menaces de sécurité courantes telles que les attaques de script intersite (XSS) et d’injection SQL. En aucun cas, la nouvelle solution ne doit compromettre le modèle de menace existant ou le modifier de manière si importante que la surface d’attaque change. En donnant la priorité à la sécurité comme objectif de conception, l’architecture doit fournir un environnement plus sécurisé pour la communication API, réduisant ainsi le risque de violations de données et d’autres incidents de sécurité.
Specific requirements can be derived based on these design considerations, which we’ve incorporated into our distributed gateway actors (DGA) solution.
Acteurs de la passerelle distribuée
Now having fully explored API gateways, we can explain the distributed gateway actor solution.
Conception des acteurs de la passerelle distribuée
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.
Assumptions
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.
API Gateway Functions
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.
Centralized Functions
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.
Core API Gateway 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.
Conflated
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.
Gateway Actor – Fonctionnalités en ligne
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:
- Reduced load on API gateway: Help to reduce the load on the centralized API gateway and improve the performance and scalability of the system.
- Enable faster response times: Enable faster response times and reduced latency by deploying these functions closer to the clients. By leveraging caching of the data and the function, the edge hosted API gateways can rapidly respond to incoming requests.
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.
Gateway Actors – GraphQL Candidates
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.
Other Features and Functions
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.
Component’s Features and Behavior
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.
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.
Passerelle API simplifiée
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.
Acteurs de la passerelle distribuée
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.
Gateway Actor Placement
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.
Conclusion
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.