Services et microservices : appels et réponses - Partie 3
TRQL Radio est rempli de services. C’est parce que les APIs sont devenues le moyen commun d’exposer des fonctions Business, tant au monde externe qui voudrait venir se servir qu’au monde interne (les applications qui ont besoin de données provenant de l’intérieur ou de l’extérieur de l’organisation : c’est le cas quand vous mettez en place une architecture de Business Intelligence).
L’exposition de services au monde extérieur comporte des risques d’exploitation non-souhaitable. S’en prémunir demande de gérer la sécurité des accès aux services.
L’accès aux services de TRQL Radio est entièrement libre (en tout cas au moment où j’écris ces lignes). Nous n’avons donc pas besoin, à ce stade, de sécuriser les accès. Nos services sont d’autant plus simples à concevoir.
Nos services sont gratuits, cela nous dédouane d’en établir la comptabilité (nombre d’accès par unité de temps, nombre d’accès gratuits, nombre d’accès payants, etc.) et la … facturation.
Cela reste donc fort simple, à la fois dans la pure construction mais, également, dans les tests à effectuer. Ce n’est pas le moindre des avantages de notre situation actuelle.
Je couvrirai ultérieurement ces aspects plus complexes dans un article à venir.
J’avais prévu, dans la partie 2 de cette petite série, de parler d’API Gateway et de console. Je remise également à plus tard ces éléments pour, aujourd’hui, me concentrer sur quelques services capables de retourner des données économiques que nous extrayons de l’Internet, soit sous forme d’appels à des APIs externes, soit sous forme de scraping de différents sites, soit encore par accès à des données ouvertes. En somme, nos services retournent des données à l’appelant de nos services, données que nous-mêmes allons chercher ailleurs avec un cas général où … nos services font appel à des services. Ce qui est vrai avec des données est vrai avec des traitements (ex : des services de traduction automatique). Il va sans dire que les appels de nos services se font sur un modèle que nous contrôlons et que les retours se font aussi de manière standardisée afin que l'appelant ne se retrouve pas à gérer quantité de conventions différentes (un peu de polymorphisme ne fait pas de tort).
Scraping
Afin de pouvoir offrir une forme de continuité de nos propres services, nous devons constamment contrôler l’accès aux sources d’informations que nous utilisons. Dans le cas d’accès à des pages officielles publiques, la veille est relativement aisée (ex. StatBel, INSEE, EuroStat, …). En revanche, la présentation des infos change régulièrement : ce qui était disponible sous forme de liste est maintenant disponible sous forme de table, ce qui était à gauche est maintenant à droite, les id soint modifiés, les classes CSS également, etc. toutes conditions qui rendent notre scraping inopérant. Cela demande une veille constante pour s’assurer que les infos sont toujours disponibles sous la forme utilisée pour les extraire lorsque le service a été construit. La seule façon de s’en tirer est d’avoir une batterie de robots qui se chargent d’extraire l’info et de comparer les résultats engrangés avec des résultats attendus. C’est lourd, c’est souvent inefficace mais … nous l’utilisons fréquemment (les deux services présentés plus bas, font usage de scraping).
Cas des Open Data
Les Open Data vont souvent de pair avec une forme d’inscription/souscription (mais pas toujours). Les services sont généralement bien stables et établis sur le long terme (pourvu qu’ils aient été bien pensés). C’est souvent gratuit et bien documenté. C’est un cas facile même s’il reste indispensable de gérer votre inscription / souscription, qu’il faut aussi surveiller les changements intervenus dans les données et les conditions d’accès. Cela demande une administration rigoureuse qui dépasse le simple cadre technique de l’écriture de services. Le cas d’indisponibilité d’un service nécessite que cela se répercute dans votre API ce qui rendra inévitable l’utilisation de codes de statut, codes d’erreur. Nous avons choisi d’utiliser les codes http pour ce faire (ex : 404 … NOT FOUND ; 500 Server Error, etc.) puisque 95% de nos services sont des services REST.
Cas des APIs
Le cas de l’utilisation d’APIs externes est semblable à l’utilisation des Open Data (pas toujours, cependant). Ici, vous allez aussi devoir gérer de manière minutieuse que votre inscription aux services dont vous vous servez soit toujours à jour et que – cela nous est arrivé au moins à 4 reprises – l’entreprise qui offre ces services soit toujours en activité. Cela demande une forme d’examen minutieux du risque qu’on prend à choisir tel ou tel fournisseur ce que je note systématiquement dans le risk log (le risque est accepté par défaut et je note la vraisemblance que le ou les services deviennent inaccessibles en combinaison avec l’impact potentiel).
Souvent, l’appel aux APIs est, au moins partiellement, gratuit … pourvu que vous respectiez les volumes qui vous sont octroyés gratuitement. Une estimation de vos propres volumes devient alors un élément qu’il faut surveiller régulièrement. Si votre propre service est ouvert à d’autres, internes ou externes, il devient vite indispensable de monitorer vos volumes afin d’éviter toute surprise désagréable. Hmmm ... nous déléguons ce travail à un API Gatewxay.
Le coût des appels, lié à la problématique des volumes, est aussi un facteur de risque : le système d’information de l’entreprise peut se trouver déstabilisé par une augmentation des prix et/ou des volumes. De toutes les manières, la combinaison des deux impacte le coût du run ultérieur (années futures). Là encore, on sera bien inspiré de tout référencer clairement dans un risk log dûment tenu à jour, non seulement durant la période de construction des services mais également durant la période de leur mise en exploitation/opérations. Une collaboration DevOps peut s'avérer un avantage certain dans ce cas de figure.
Se pose aussi ici la question de la sensibilité des informations que vous envoyez au service. Ainsi, dans l’exemple du service de traduction automatique (ex. deepL), il y a lieu de vérifier avec un expert sécurité que ce que vous pourrez envoyer audit service se fait sans risquer de dévoiler le moindre élément sensible (ex. traduire un contrat, traduire une lettre pour son bureau d’avocats, …).
Recommandé par LinkedIn
Deux exmples faciles
Deux exemples simples : (1) les dépenses fiscales d’un État et (2) les revenus de gouvernements (liste de pays). Facilement accessibles, méthode de scraping, peu de risques si indisponibilité, informations peu sensibles …
https://www.trql.fm/vaesoli!/?r=trql.fm&government-revenues et https://www.trql.fm/vaesoli!/?r=trql.fm&fiscal-expenditure
Petits extraits du retour :
{"payload":{"entries":[{"country":"Albania","last":231640,"previous":163782,"date":"Apr\/24","unit":"ALL 1000000","currency":"ALL"},{"country":"Angola","last":13462,"previous":13371,"date":"Dec\/23","unit":"AOA 1000000000","currency":"AOA"},{"country":"Argentina","last":7010884,"previous":6317842,"date":"Mar\/24","unit":"ARS 1000000","currency":"ARS"},{"country":"Armenia","last":688244,"previous":568053,"date":"Dec\/23","unit":"AMD 1000000","currency":"AMD"},{"country":"Australia","last":52155,"previous":68533,"date":"Mar\/24","unit":"AUD 1000000","currency":"AUD"},{"country":"Austria","last":15349,"previous":4894,"date":"Feb\/24","unit":"EUR 1000000","currency":"EUR"},{"country":"Azerbaijan","last":6555,"previous":3466,"date":"Feb\/24","unit":"AZN 1000000","currency":"AZN"},{"country":"Bahrain","last":2457,"previous":2406,"date":"Dec\/22","unit":"BHD 1000000","currency":"BHD"},{"country":"Bangladesh","last":433000,"previous"...
Et…
{"payload":{"entries":[{"country":"Albania","last":185800,"previous":13042,"date":"Apr\/24","unit":"ALL 1000000","currency":"ALL"},{"country":"Angola","last":12902,"previous":11899,"date":"Dec\/23","unit":"AOA 1000000000","currency":"AOA"},{"country":"Armenia","last":949810,"previous":639628,"date":"Dec\/23","unit":"AMD 1000000","currency":"AMD"},{"country":"Australia","last":54531,"previous":51457,"date":"Mar\/24","unit":"AUD 1000000","currency":"AUD"},{"country":"Austria","last":18248,"previous":8494,"date":"Feb\/24","unit":"EUR 1000000","currency":"EUR"},{"country":"Azerbaijan","last":5253,"previous":1724,"date":"Feb\/24","unit":"AZN 1000000","currency":"AZN"},{"country":"Bahrain","last":3569,"previous":3614,"date":"Dec\/22","unit":"BHD 1000000","currency":"BHD"},{"country":"Bangladesh","last":660507,"previous":538983,"date":"Dec\/22","unit":"BDT 1000000000","currency":"BDT"},{"country":"Belarus","last":6383845,"previous":4318218,"date":"Dec\/22","unit":"BYN 1000","currency":"BYN"},{"country":"Belgium","last":76048,"previous":80382,"date":"Sep\/23","unit":"EUR 1000000","currency":"EUR"},{"country":"Belize","last":1036,"previous":934,"date":"Dec\/22","unit":"USD 1000000","currency":"USD"}...
Jouez-en avec parcimonie et dites-moi ce que vous en pensez. Nous, dans le cadre de TRQL Radio, cela constitue la base de quelques informations que nous diffusons régulièrement.
Voici par exemple un tweet qui a été établi de manière automatique en extrayant des données de la Banque Nationale et les passant à un service de "reformulation":
Un autre tweet construit à partir de données économiques liées au prix de l'électricité:
À plus tard, et pas de complication.