L’architecture headless est en plein essor
L’utilisation explosive et expansive des API contribue à l’essor de l’architecture headless et donne à GraphQL une place de choix dans cette architecture application néomoderne.
Depuis plus de deux décennies, des changements de paradigme importants dans les architectures d’applications ont eu un impact direct sur l’évolution de la diffusion d’applications. Historiquement, les architectures application destinées à dominer et à influencer notre marché émergent et commencent à façonner le marché tous les cinq ans et deviennent dominantes environ cinq ans plus tard, ce qui entraîne à son tour des changements sur le marché de la diffusion d’applications.
Les microservices (cloud natifs) ont gagné des parts de marché en 2015, mais ce n'est qu'en 2020 que le maillage de services et le contrôle d'entrée ont augmenté, orientant l'orientation du paysage de diffusion d'applications. Nous voyons maintenant les premiers signes d’une nouvelle architecture – headless – qui remplacera les microservices comme force motrice dans la distribution d’applications.
Sur la base des tendances historiques, l'architecture headless atteindra une part de marché importante d'ici 2025 et commencera à conduire le changement sur le marché de la diffusion d'applications. La fiabilité de ce cycle, combinée à l’activité et à l’intérêt croissants du marché liés aux API et à la technologie graphique, laisse entrevoir un impact significatif sur la livraison des applications d’ici 2030.
Tendances à l’origine de l’architecture headless
Plusieurs forces externes poussent deux tendances technologiques à converger, ce qui entraînera le prochain grand changement dans la distribution des applications : Conception API-first et démocratisation des données .
- Transformation numérique
- « Les API sont fortement exploitées, avec une moyenne de 15 564 API utilisées parmi les organisations ayant répondu à l'enquête, et un taux de croissance de 201 % jusqu'en 2021 » ( Noname Security ).
- 18 % de l'activité du marché que j'ai suivie au cours de l'exercice 22 était liée d'une manière ou d'une autre aux API. Les investissements dans les API augmenteront ou resteront les mêmes dans les organisations au cours des 12 prochains mois, selon 89 % des répondants au rapport 2022 State of the API de Postman , qui a interrogé plus de 37 000 professionnels des API.
- Décentralisation
- Low-Code/No-Code
La volonté de numériser les entreprises se manifeste par des « services numériques » fournis par une « entreprise numérique ». Les services numériques sont des constructions commerciales éphémères composées d'applications, de distribution d'applications, de sécurité d'applications et de données, intégrées, orchestrées et exploitées via l'utilisation d'API. Aujourd’hui, 82 % des organisations fournissent des services numériques aux consommateurs internes et externes (SOAS 2022 ).
Simultanément, l’adoption de microservices, qui communiquent principalement via des API, a continué de croître. Selon nos propres recherches , nous estimons que « le nombre d’API publiques et privées approche aujourd’hui les 200 millions, et d’ici 2031, ce nombre pourrait atteindre les milliards ».
S'orienter: Le résultat est un glissement vers les API d’une ampleur qui entraînera une perturbation du marché de la distribution d’applications matures, de la même manière que les services mobiles et les microservices ont perturbé le marché de la distribution d’applications entre 2010 et 2020.
La décentralisation est le résultat d’une activité numérique distribuée résultant du travail à distance, de l’adoption massive de l’IoT et des préoccupations concernant la confidentialité des données. La décentralisation est souvent liée aux technologies Web3 telles que la blockchain ainsi que edge computing, en particulier lorsqu’elle est appliquée à l’IoT industriel. Mais c’est en réalité le résultat de la décentralisation qui est à l’origine des perturbations. Les données et les applications se « décentralisent », ce qui introduit les défis en termes de performances et de sécurité attendus de tout système distribué. Cela inclut les 77 % d'organisations qui cherchent à déployer des charges de travail de traitement de données et de front-end numérique à la périphérie ( SOAS 2022 ).
S'orienter: La décentralisation a des conséquences au-delà des applications distribuées car elle intègre également la capacité de distribuer des données. Les approches traditionnelles relèguent les données à un niveau protégé, derrière les applications. La décentralisation impose une nouvelle approche dans laquelle les données sont exposées directement via des API, sans nécessiter d’intermédiaire (application). Ce changement élimine l’approche par niveaux de l’architecture des application et fournit un itinéraire direct vers les données pour les partenaires externes, les développeurs tiers et les consommateurs. Le début de cette démocratisation des charges de travail au sein de l’architecture application peut être observé dans les architectures de microservices. Nous voyons également la valeur commerciale existante de la démocratisation des données dans les modèles commerciaux qui reposent sur l’inversion, c’est-à-dire la libération des données via des API pour créer de la valeur pour les partenaires et les développeurs tiers.
Nous voyons également la valeur commerciale existante de la démocratisation des données dans les modèles commerciaux qui reposent sur l’inversion, c’est-à-dire la libération des données via des API pour créer de la valeur pour les partenaires et les développeurs tiers.
La numérisation entraîne une demande accrue de talents en ingénierie par rapport à ce qui existe déjà sur le marché. Cela empêche les organisations d’exploiter les vastes réserves de données générées par une entreprise numérique. Les talents existants sont surchargés et souvent incapables de se développer aussi rapidement que l’exige l’entreprise.
Cet écart entre l’offre et la demande entraîne une augmentation des solutions low-code/no-code pour permettre à un ensemble plus large d’utilisateurs de développer des solutions et des services. Les recherches indiquent que 75 % des entreprises adopteront un « mélange d’innovation low-code/no-code et conventionnelle ».
S'orienter: Les solutions low-code/no-code s’appuient sur l’accès à la logique métier et aux données, tous deux largement disponibles grâce à la démocratisation des données et à la conception axée sur les API. Le besoin de ces solutions agit comme un accélérateur de la maturation des tendances en matière de données et d’API.
Le langage utilisé sur le marché lié aux API (routeurs, passerelles, middleware) est similaire au langage utilisé avant les changements antérieurs du marché induits par les microservices, la mobilité et les changements architecturaux. L’activité, la terminologie et le rythme de création d’API indiquent que ce changement aura un impact significatif sur les marchés de la livraison et de la sécurité des applications.
Nous assistons déjà au début d’une disruption basée sur les API dans l’industrie sous la forme de produits et de services spécifiquement axés sur l’observabilité des API, la sécurité, la veille sur les menaces et la fédération.
Ces changements ne se produisent pas dans le vide. En effet, le changement dans la distribution d’applications causé par les microservices était en grande partie dû à l’adoption généralisée de Kubernetes et à sa décision architecturale d’intégrer directement les capacités traditionnellement offertes par les technologies de distribution d’applications telles que les contrôleurs d’entrée (routage L7).
Le changement d’API n’est pas différent, et les tendances actuelles indiquent que ce changement entraînera l’essor de GraphQL, une approche de conception d’API qui interagit plus directement avec les données et répond aux problèmes de performances avec les solutions basées sur REST et, plus important encore, intégrera les capacités de livraison d’applications dans son ensemble de fonctionnalités de base.
Architecture sans tête
La domination des API est à l’origine de ce que les analystes appellent « l’architecture headless », c’est-à-dire des capacités et des fonctions commerciales exposées sous forme d’API sans la couche de présentation traditionnelle. Cette architecture est souvent évoquée dans le contexte des « applications composables », une autre tendance technologique en plein essor sur le marché.
Les architectures sans tête sont idéales pour répondre au besoin de solutions low-code/no-code, car les API sont un moyen pratique de fournir une logique composable facilement personnalisable sans effort considérable. L'architecture sans tête répond également au besoin de composer des services numériques à partir d'une variété d' applications, de services et de systèmes, et constitue un moyen éminemment pratique d'intégrer des charges de travail distribuées, comme le montre déjà le marché de l'IoT principalement axé sur les API.
Il semble donc logique de dire que la prochaine évolution des technologies de diffusion et de sécurité des applications sera portée par les API, qui propulseront les architectures headless vers le grand public.
L’impact le plus significatif concernera les services de fourniture et de sécurité des API. Le marché a longtemps considéré les API comme un simple cas d’utilisation spécialisé de la diffusion et de la sécurité des applications Web. Ce changement mettra en évidence la réalité selon laquelle les API constituent une classe distincte d’entités ayant des besoins spécifiques en matière de livraison et de sécurité qui ne peuvent être satisfaits par des moyens traditionnels. Cela est particulièrement vrai lorsque l’on explore l’impact des services de données directement exposés via les API. Pendant la majeure partie de l’histoire, les données ont été exposées uniquement via des applications . L’exposition directe via une API constitue en soi un changement important, mais fournit l’exemple parfait de la raison pour laquelle les API ne sont plus un sous-ensemble d’applications Web mais un composant architectural discret à part entière.
Le rôle de GraphQL dans l'architecture headless
Ce changement dans les architectures d’applications se produit également à un moment où les approches des API évoluent également historiquement, généralement en réponse à la manière dont les API sont utilisées. Toutes les API sont finalement utilisées pour échanger des données, mais au fil du temps, le type et le format de ces données changent pour refléter les contraintes et les capacités de l'architecture de application . Par exemple, REST et JSON sont devenus populaires parallèlement à l’évolution vers le mobile et les microservices en réponse au besoin d’échanges de données plus fréquents et à la puissance de calcul réduite des plateformes mobiles. SOAP et XML nécessitaient une analyse approfondie et consommaient une bande passante excessive. REST et JSON ont réduit la charge en exploitant les constructions HTTP existantes pour décrire les points de terminaison et en passant à un format de données plus simple dans JSON.
Cependant, SOAP/XML et REST/JSON requièrent tous deux des compétences de développeur traditionnelles, et la tendance est au low-code/no-code, ce qui suppose peu ou pas de compétences de développeur. GraphQL est un langage de requête simple, destiné aux non-développeurs et très proche des outils simples qui le rendent accessible à un ensemble plus large d'utilisateurs. Cela rend les API accessibles et composables dans des services numériques de toutes sortes. Cela en fait un remplacement parfait pour REST/JSON à mesure que les architectures évoluent vers une architecture API uniquement (sans tête).
GraphQL est la solution actuelle préférée au problème de la prolifération des API et aux mêmes problèmes de performances qui ont contribué au passage de l'architecture SOA (orientation services) à REST. GraphQL bénéficie également d'une spécification , qui contribue à stimuler le développement de solutions low-code/no-code qui offrent un soulagement au défi posé par la pénurie de talents.
Enfin, étant donné que GraphQL interroge les API et que la grande majorité des magasins de données actuels sont compatibles avec les API, les solutions basées sur GraphQL peuvent éliminer efficacement « l’intermédiaire » de l’ application et accéder directement à la source de données elle-même. Cela est particulièrement utile pour les applications distribuées qui nécessitent un accès rapide et direct aux données dans des emplacements distants.
Cela place GraphQL dans une excellente position pour agir comme une « passerelle » vers une architecture sans tête, de la même manière que les contrôleurs d’entrée sont devenus la « passerelle » vers l’architecture des microservices.
Conclusion
On dit que la seule constante est le changement, et cela est vrai pour la technologie. Nous restons rarement immobiles plus de quelques années avant que quelqu’un ne change les règles du jeu. Dans le monde de la diffusion et de la sécurité des applications, ces règles sont partiellement définies par les architectures application . Ainsi, aucun changement significatif dans les architectures application ne se produit sans agir comme une fonction de forçage sur la livraison et la sécurité des applications pour évoluer également.
Ce changement prendra encore quelques années, mais vous pouvez déjà constater l’impact profond que des technologies comme GraphQL et les API ont déjà sur tout, de l’infrastructure à la périphérie en passant par la distribution d’applications.
L’architecture sans tête est en plein essor et GraphQL jouera un rôle important.