Le multicloud ou la difficulté de gérer les API
En favorisant la communication et le dialogue entre les applications et les services, les API jouent un rôle essentiel dans le cloud. Avec le multicloud, leur gestion se complique.
Les applications Cloud dépendent presque toujours de plusieurs services issus de différents fournisseurs de premier plan, tels qu’AWS, Microsoft Azure et Google Cloud Platform. Pour accéder et déployer efficacement ces services cloud, les entreprises s’appuient donc sur les interfaces de programmation (API) de chaque fournisseur.
Mais au fur et à mesure, leurs stratégies d’hybridation, liées ou non au multicloud, la gestion et l'intégration de ces interfaces de programmation d'applications - qui varient d'un fournisseur à l'autre – peuvent en effet poser de vrais problèmes.
Les API dans un environnement multicloud : quels sont les problèmes ?
Premier constat primordial : chaque API est différente, et chacune d’entre elles incluent des combinaisons de sous-programmes, de protocoles et d'outils. Résultats, l’interconnexion de ses différentes API constitue une importante difficulté, si une entreprise souhaite créer une application qui fonctionne sur plus d'une plateforme cloud. Les fournisseurs offrent en effet des instances de calcul et de stockage, des services réseau et des outils de surveillance variés – mais peu interopérables. Il est probable que certaines workloads entre des fournisseurs de services soient incompatibles. Même si les services sont similaires, la façon dont les utilisateurs invoquent un service ou une action avec l'API d'un fournisseur peut être radicalement différente chez un autre.
D’où la nécessité pour les administrateurs de connaître les différences entre chaque API et leurs spécificités lorsqu'ils passent au multicloud. Le nombre d'appels API pour accomplir les mêmes tâches entre les différents fournisseurs de cloud peut aussi varier.
Il peut également exister des différences de performance, telles que la latence et la limitation du nombre d'appels API pendant une période donnée. A cela s’ajoute une dimension architecturale : l’infrastructure de chaque fournisseur et la façon dont celle-ci est configurée ou optimisée peuvent aussi affecter les performances et la disponibilité de l'API. Cela peut donc compliquer la conception de l'application.
En outre, ces mêmes fournisseurs utilisent souvent différentes techniques de sécurité et de méthode d’autorisation de l'API. La gestion des messages d'erreur de l'API peut aussi varier. Et cela ne fait que s’aggraver lors des mises à jour ou des modifications des API.
Au regard des problèmes que posent l'intégration d'une seule API à une application, le recours à plusieurs fournisseurs de cloud - et la création d'un système de gestion d'API pour soutenir ce modèle – a de quoi refroidir les ardeurs de la DSI.
Broker de services et gestion d'API multicloud
Une des façons de résoudre ces problèmes de compatibilité multicloud est l'abstraction de l'API. Avec ce principe, on insère une autre couche entre l'application et les multiples services cloud auxquels les API accèdent. Cette couche présente aux entreprises une API unique et unifiée qui utilise une authentification unique pour fournir un ensemble de commandes – elles aussi communes - pour réaliser certaines opérations clé, comme la création et la gestion des instances de calcul et de stockage. La couche d'abstraction traduit ensuite ces commandes en API pour chaque fournisseur de cloud respectif.
De telles API ont commencé à émerger pour gérer le multicloud. C’est ce que propose par exemple RightScale, reconverti dans la gestion des cloud, qui fournit une API commune pour la gestion d'un large éventail de services cloud, tant publics que privés, comme AWS, Microsoft Azure, Google Cloud Platform, Rackspace, IBM Cloud, Apache CloudStack, OpenStack et VMware vSphere. Cette API commune permet aux utilisateurs de créer des configurations cohérentes entre fournisseurs, tout en proposant des outils de surveillance, d’évaluation des coûts et de création de rapports uniques pour tous les cloud pris en charge.
Pourtant, avec un système de broker de services cloud ou un système de gestion d'API, il reste une difficulté majeure : l'ajout d'une autre plateforme SaaS s’avère compliqué et coûteux. Les utilisateurs s'attendent également à ce que les modifications effectuées sur un service par un des fournisseurs soient visibles à la fois rapidement et de façon fiable dans le broker. Si les coûts des chez AWS changent ou si Azure ajoute un service, le broker doit être capable de répercuter ces changements. Les utilisateurs doivent également être rassurés quant à la disponibilité et la fiabilité du système. Si le service est indisponible, cela peut nuire à l’utilisation de chacun des services référencés dans le broker.
L'évolution vers des API standards
Idéalement, il suffirait que les fournisseurs de cloud adoptent une API commune comme standard pour faciliter la gestion des applications et des ressources dans le multicloud. Bien que cela semble être un objectif louable, les éditeurs sont lents à faire évoluer leur modèle, même si cela freine les utilisateurs. Toutefois, l’intérêt est bien présent, et la création d’API commune devrait voir le jour au fur et à mesure que les services se propagent dans les entreprises.
L'interface Open Cloud Computing Interface (OCCI) dirigée par un groupe de travail de l'Open Grid Forum en est un exemple.OCCI constitue en fait un front end qui s'interface avec les systèmes de gestion d'un fournisseur de services. A l'origine, il était destiné à la gestion à distance des fournisseurs d’IaaS. OCCI permettait le développement d'outils communs à partir d’une API pour déployer, mettre à l'échelle et monitorer les services. Depuis, OCCI a évolué pour devenir une API extensible : elle peut également servir pour le PaaS et le SaaS. Aujourd'hui, OCCI est implémenté dans de nombreuses solutions Cloud.
