fbpx
ActualitésAstucesHigh TechUtilitairesWeb

Faire évoluer le développement piloté par l’API peut être difficile

Les développeurs pensent aujourd’hui aux interfaces de programmation d’applications ou API. L’examen des API vous aide d’abord à vous concentrer sur le problème que vous cherchez à résoudre dans une application ou dans le cadre d’un service plus large. La communication entre les composants d’une application s’effectuant via des API, cette approche facilite l’adoption de conceptions de microservices et l’utilisation du multi-cloud.

Cependant, le développement piloté par l’API (ADD – API-driven development) n’est pas aussi simple qu’il y paraît dans le temps. Se concentrer d’abord sur les API peut faciliter la création et la maintenance d’une application, mais il n’est pas possible d’ignorer complètement le côté infrastructure. Si vous souhaitez étendre votre service au fil du temps, il sera essentiel de penser à des domaines tels que les données.

Alors, comment pouvez-vous tirer le meilleur parti d’ADD et envisager l’infrastructure ensemble? Et y penser d’un point de vue non fonctionnel est-il l’approche la plus utile?

Ajouter votre approche

La meilleure approche autour d’ADD est de regarder votre approche des API et de l’infrastructure au début. Bien que se concentrer d’abord sur les API puisse aider à rendre la mise à jour de votre application plus facile et plus rapide au fil du temps, cela ne résout pas les problèmes qui peuvent exister autour de l’infrastructure.

Au lieu de cela, il vaut la peine de consacrer un certain temps à réfléchir à la manière dont vos API interagiront avec les API de services d’infrastructure back-end, et comment ces services répondront aux exigences de niveaux de service. Bien qu’une API devant une base de données ou un service de stockage puisse vous aider à simplifier le processus de création d’un service, vous devez penser à la façon dont ce back-end fonctionnera à l’avenir.

En règle générale, de nombreux composants d’application gèrent une forme de demande de données. Il peut s’agir de créer une commande, de traiter une modification ou de fournir des données en retour sur la base d’une demande; toutes ces actions reposent soit sur la prise de données existantes dans une base de données, soit sur la création de nouvelles données qui sont ensuite insérées dans une base de données existante. En simplifiant le traitement dans le cadre d’un appel API, il est facile d’augmenter le nombre de demandes pouvant être traitées.

Cependant, cette infrastructure n’est pas aussi interchangeable que cela puisse paraître. Toutes les bases de données ne sont pas créées égales, et il en va de même pour les offres de services de cloud public. Il vaut donc la peine de passer du temps à comprendre comment vos options fonctionnent en fonction de problèmes tels que l’échelle ou la disponibilité. Alors que l’API pour gérer les données peut être la même quelle que soit la base de données que vous choisissez, différentes bases de données fonctionnent différemment et gèrent les données de différentes manières.

Bien qu’une API puisse masquer la complexité de la gestion d’une base de données pour vous, cela ne signifie pas que la base de données disparaîtra. Au lieu de cela, cela vaut la peine de passer du temps sur la façon dont vous pouvez tirer le meilleur parti de cela via vos API.

De nouvelles conceptions d’applications nécessitent de nouvelles approches des données

Le passage à ADD et aux microservices permet de penser plus facilement à l’échelle d’une application. Besoin de plus de puissance pour répondre à plus de demandes des clients? L’ajout de nœuds de conteneur pour gérer un volume croissant d’appels d’API, afin que cela puisse prendre en charge plus de demande. Cependant, ce n’est pas le seul goulot d’étranglement potentiel pour les performances.

Pour les applications qui sont distribuées – car elles sont composées de plusieurs composants différents, chacun pouvant être constitué de grappes de nœuds exécutant des tâches – de nouvelles approches sont en cours de développement qui peuvent faciliter la gestion au fil du temps. Par exemple, l’outil d’orchestration de conteneurs Kubernetes facilite beaucoup l’automatisation du processus de création de conteneurs supplémentaires et leur fermeture lorsqu’ils ne sont plus nécessaires. Cependant, ces approches ne traitent pas du problème des données.

L’exécution d’un environnement de base de données distribuée implique de comprendre comment les données sont réparties sur plusieurs emplacements et les exigences de tolérance, de cohérence et de disponibilité de partition qui entrent dans cette configuration. L’utilisation d’une base de données distribuée avec une application entièrement distribuée vous permet de garder vos données à proximité de votre application, garantissant ainsi que la latence n’affecte pas les performances. Des services comme Apache Cassandra sont spécialement conçus pour gérer les données distribuées, ce qui facilite leur évolutivité.

De même, l’utilisation d’une API pour accéder à cet environnement de base de données peut masquer certaines des complexités liées à l’exécution de cet environnement distribué. Néanmoins, la mise à l’échelle d’environnements de bases de données distribuées afin qu’elle puisse répondre aux besoins de votre application est un défi. Le comprendre et le planifier à l’avance peut faciliter la mise à l’échelle globale de votre service.

Si vous constatez que votre infrastructure de base de données existante devient un goulot d’étranglement pour les performances globales, vous pouvez voir comment gérer une migration derrière l’API. Le passage d’une base de données relationnelle à une base non relationnelle ou le passage d’une base de données NoSQL à une autre peut nécessiter du temps et des ressources supplémentaires. Cependant, l’API peut être rapidement pointée d’un service à un autre, ce qui limite l’impact sur le reste de l’équipe.

ADD et données ensemble

Regarder votre infrastructure peut sembler contraire à ADD. Après tout, entrer dans les détails sur les services cloud ou les bases de données à l’avance peut sembler moins important que de voir comment créer et exécuter les API qui composent une application. Cependant, les problèmes causés par une évolutivité ou une disponibilité inadéquates peuvent rapidement affecter les applications et ce ne sont pas des problèmes simples à résoudre avec les API seules.

L’examen initial de vos exigences à long terme et de vos décisions d’architecture peut donc vous aider à résoudre rapidement certains problèmes. En réfléchissant à l’endroit où vos approches de l’infrastructure et des API se chevauchent, vous pouvez tirer le meilleur parti des deux.

Afficher plus

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Bouton retour en haut de la page