Avec la prolifération des applications en SaaS et réparties chez plusieurs fournisseurs de Cloud public, il devient difficile de savoir où sont les données. Et si les API permettent d’accéder aux données métier, elles ne répondent pas pour autant à cette question de localisation et ne font que masquer la complexité d’une architecture… et parfois ses coûts. Article paru dans L'Informaticien n°197 (juin 2021).
Avant toute chose, puisqu’il est question ici de multicloud, quelques éléments de définition s’imposent : le terme multicloud désigne une architecture combinant au moins deux fournisseurs de Cloud public, AWS et Azure par exemple. A contrario, une architecture hybride désigne la combinaison d’un environnement privé, par exemple un centre de données on premise, et d’un environnement de Cloud public. Mais attention, une configuration multicloud peut aussi comprendre des environnements informatiques privés. En résumé, les architectures informatiques sont de plus en plus complexes et diverses. Quand bien même le Cloud est supposé apporter de la flexibilité et de la simplicité dans l’IT. D’autant que les entreprises réalisent qu’elles ont souvent besoin de plusieurs fournisseurs de Cloud, pour des raisons allant de l’optimisation des performances et des coûts à la demande des clients en passant par des questions de souveraineté des données.
Cette tendance est largement permise par les microservices et les conteneurs. Les applications monolithiques étaient, à mesure qu’elles grandissaient, difficiles à déplacer, à faire évoluer, à déployer… Les Docker et autres Kubernetes ont changé la façon de concevoir les applications, en les décomposant, facilitant les déploiements et l’innovation. Ce faisant, le multicloud est arrivé avec une multitude de promesses : ne pas être attaché à un seul fournisseur cloud – ce fameux vendor locking –, toujours avoir la meilleure brique – que ce soit pour le stockage, une technologie donnée, la latence, le transport des données, etc. – et ce au meilleur coût, limiter le Shadow IT en récupérant cette informatique parallèle au sein d’un ensemble que la DSI gère, faire de la gestion de très haute disponibilité sans coût dispendieux ou encore être conforme à la règlementation, sur la localisation des données par exemple.
Multiplication des services
Mais avec des services fragmentés, divisés entre plusieurs Clouds, comment faire en sorte que les données soient toujours disponibles au moment où les équipes métier en ont besoin. Rien qu’avec le modèle SaaS, on peut se retrouver avec un CRM chez Salesforce, un ERP chez Sage, une messagerie chez Google, une BI chez Microsoft ! Comment faire pour que ces services communiquent, sans avoir à déplacer manuellement les données d’une application à l’autre ou à développer de nouvelles fonctionnalités pour vos applications métier ? Eh bien, les API pardi ! C’est fou ce que quelques petits morceaux de code peuvent simplifier la vie des développeurs afin d’accélérer le développement d’applications métier.
Mais le font-ils vraiment ? Pour Marc Fanget, directeur technique chez Umanis, il faut tempérer son enthousiasme. Il ne remet pas en cause l’APIsation, il y croit même fortement. Non, c’est plutôt sur l’utilisation du multicloud qu’il est «plus circonspect». « La question qui se pose est comment fédérer mes données », explique-t-il. Les API vont venir masquer la gestion de ces données : il n’est dès lors plus utile de savoir où elles sont, ce sont là les merveilles de l’automatisation. Cependant, dans un contexte multicloud, les instances d’API sont dispersées entre plusieurs fournisseurs. Or les API doivent être surveillées et gérées, aussi bien pour des questions de coût que de dépendance des applications à des services tiers. Et il est bien plus difficile de synchroniser des règles de routage API, autorisations et quotas de limitation de débit entre de multiples fournisseurs, d’autant que l’on parle là de surveillance et de production de rapports sur l’état de l’API entre et au sein de chaque fournisseur et région.
Risque de flambée des coûts
La prolifération des applications en entreprises provoque un silotage qui, pourtant, devait être évité avec le Cloud. Ce faisant, l’opacité qui en résulte va compliquer la gestion et la visibilité des API pour les équipes informatiques et les développeurs. Quant aux coûts, Marc Fanget rappelle que « lorsque les données entre sur un Cloud, c’est gratuit. C’est lorsqu’elles en sortent qu’il faut passer à la caisse ». Le problème étant que, avec les API, les données sont amenées à se déplacer d’un Cloud à l’autre et que, en dissimulant la complexité de ce qui est réalisé techniquement, on cache également le transport des données… du moins jusqu’à ce qu’arrive la facture du fournisseur de Cloud. Il devient alors nécessaire de pouvoir gérer toutes les API dans un seul et même emplacement centralisé par le biais duquel peuvent être déployées les règles d’authentification, d’autorisation, de limitation et de transformation, surveiller facilement l’utilisation des API associées à vos applications.
Les cloud providers fournissent ce genre de plate-forme d’API management. Toutefois, certaines de ces solutions ne sont pas agnostiques et vont contrôler les accès et les règles seulement chez le fournisseur en question. Surtout que, généralement, ces outils placent sur le même plan le Control Plane et le Data Plane. En conséquence, les limitations de ressources peuvent être mal appliquées ou encore les autorisations risquent de se désynchroniser et permettre un accès inapproprié aux données. En outre, ce genre de services n’est pas gratuit et implique donc des coûts supplémentaires. La gestion d’API oblige à prendre « un autre tiers pour la fédération entre les différents Clouds et la répartition de la charge », indique Marc Fanget. Des API gateway à l’instar de Tyk ou encore de Kong. « Mais il s’agit de services à payer en plus.»
Un point de contrôle unique
Pour améliorer la visibilité et faciliter la gestion des données, le directeur technique chez Umanis note qu’une entreprise pourrait choisir « de développer, d’implémenter elle-même ses propres API, en dockerisant ses services, en les déployant avec Kubernetes, etc., mais on part là sur une usine à gaz puisqu’il faudra encore synchroniser les données, se demander où est la donnée la plus récente…» Pas de solution miracle donc. Marc Fanget résume pour nous le problème : « Quand je vais appeler mon API d’exposition, pour appeler mes données métier, je ne sais pas d’où viennent ces dernières et donc si je vais avoir un coût à la consommation.» Ce qui oblige donc à paramétrer une gateway… encore faut-il savoir faire et y penser. « En outre, les données sont sur différentes régions géographiques, ce qui pose un problème pour les DPO qui ne savent ni où ni comment les traitements se font », ajoute Marc Fanget. Il ne s’agit pourtant pas de fuir le multicloud et les API. Il serait néanmoins préférable d’appliquer la méthode KISS, pour « Keep it simple stupid » : moins j’ai de composants, mieux je me porte. « Le multicloud, j’y vais sur la pointe des pieds en tant que directeur technique. Multiplier les briques, même en masquant la complexité par le biais d’API, cela revient à perdre l’avantage que je souhaitais obtenir au départ », précise le directeur technique d’Umanis. « L’API, ce n’est qu’un moyen de masquer la complexité d’implémentation, mais elle masque peut-être un peu trop de choses. Donc il faut bien prévoir sa stratégie multicloud, bien préparer la répartition de ses pans applicatifs métier pour limiter les échanges entre les fournisseurs cloud, mais dans ce cas, les promesses du multicloud ne sont pas tenues.» Certains nous feront remarquer qu’il existe des platesformes spécialisées dans ces enjeux, à savoir la part consommation et position de services multicloud. Il est vrai que l’on a connu de nombreuses tentatives dans l’iPaaS… mais la plupart, à l’instar du Français Moskitos, dont les solutions qui étaient prometteuses sur le papier, se sont cassés les dents sur les problématiques du marché.