lundi 7 novembre 2011

En quoi les fournisseurs cloud et api peuvent-ils changer la chaine logistique Internet ?

La mise en oeuvre d'une application web nécessite l'utilisation d'une chaîne logistique faisant intervenir plusieurs fournisseurs.

Quelles sont les composantes de cette chaine  ?

1) Infrastructure

La prestation d'hébergement met à disposition les ressources matérielles permettant l'accès des utilisateurs à l'application.

Elle fournit, au minimum, alimentation électrique, connectivité et éventuellement ressources de calcul (ram, cpu, stockage, ...).
Le coût de l'hébergement est en général basé sur un forfait mensuel ou annuel.

Un coût d'installation forfaitaire est très souvent présent au démarrage de la plate forme. Cette installation génère un délai dans la mise à disposition des machines.

La mise en place manuelle de cette infrastructure nécessite des actions (manutention, câblage, initialisation, formatage, ...) dont l'efficacité est limitée par le monde physique.
    Les avantages sur ce premier maillon du mode cloud, proposant des ressources virtualisées, sont :
    • des délais de mises en oeuvre raccourcis (provisionning) du fait du self service sans intermédiaire
    • l'ajustement de l'infrastructure aux besoins réels (modification du  dimensionnement sans délai)
    • la diminution des coûts en relation avec la prise en compte de la consommation effective
    2) Briques techniques

    Les ressources matérielles mises à disposition précédemment reçoivent des briques logicielles techniques liées au rôle de chaque serveur dans l'architecture : base de données, serveur d'application, moteur de recherche, etc.

    En fonction du type de logiciel utilisé, il faut prendre en compte  des coûts d'installation, de configuration et éventuellement de licence.

    Certains fournisseurs de cloud offrent des "briques techniques" clés en main comprenant à la fois les éléments d'infrastructure et les briques techniques associées. Ainsi vous ne louez plus un serveur avec 12Go de RAM et 6 coeurs sur lequel vous installerez votre moteur de base de données, mais un package "Base de données taille moyenne". Dans un monde idéal vous pourriez, le moment venu,  faire simplement évoluer votre package vers "Base de données grande taille et fort trafic" sans reconfiguration manuelle de votre part.

    La capacité de pouvoir ajuster plus ou moins automatiquement le dimensionnement de l'ensemble des couches techniques (infrastructure + logiciel technique) est un point important qui permet de gagner en coût, en flexibilité et en qualité.

    3) Briques métiers

    Au dessus des éléments techniques on peut trouver des briques applicatives métier (logiciel e-commerce, gestion de contenu, CRM, logiciel métier spécifique Saas, ...). De la même manière que pour les couches précédentes, des configurations complètes sont disponibles en self service chez certains fournisseurs.

    Les clients peuvent aussi court-circuiter les deux étapes précédentes (infrastructure et brique technique) pour louer directement l'accès à la solution métier (mode SaaS).

    Quoiqu'il en soit, la notion de self-service permet de disposer de certaines fonctionnalités :
    • très rapidement,
    • à des coûts très raisonnables,
    • sans compétence technique très pointue
    Une fois les applications opérationelles, certaines questions commencent à se poser :
    • quid de l'interaction entre les différents fournisseurs / plate formes / logiciels ?
    • est-il possible de compléter facilement une application Saas (clé en main) par un développement spécifique ?
    • la récupération des données, le changement de prestataire est-il possible à moindre frais ?

    4) La place des API

    L'une des tendances qui se dégage aujourd'hui est la mise à disposition, par tous les intermédiaires de la chaîne,  d'API permettant d'interagir avec les solutions.
    • les hébergeurs cloud proposent des api permettant de contrôle et modifier les configurations des ressources utilisées sur la plate forme. Cette fonctionnalité autorise les clients à mettre en oeuvre leurs propres règles de fonctionnement et de gestion de ressources.
    • c'est la même chose pour les briques techniques, il est possible via quelques api judicieusement mises à disposition de pouvoir prendre le contrôle du dimensionnement (et donc de la consommation) de la globalité de la plate forme. Par exemple, la détection d'un temps de réponse supérieur à un seuil donné déclenchera la modification d'un paramètre décrivant la taille d'un cache. Ces règles sont très délicates à mettre en oeuvre et ne doivent pas être manipulées inconsidérément  et sans préparation. Néanmoins, avoir la capacité d'ajuster facilement son infrastructure à ses besoins est un point très important. Cela est particulièrement efficace si les logiciels techniques et l'infrastructure peuvent être ajustées de manière coordonnée (et automatique ?)
    • les applicatifs métiers, enfin, donnent accès aux fonctionnalités et aux données via des api ad hoc et permettent ainsi un certain degré d'interopérabilité entre différentes solutions.
    Ces deux points essentiels (self service et utilisation d'api) permettent un gain considérable de temps et d'argent.

    Il y a un retournement important dans la manière de piloter l'ensemble des éléments de la chaîne. Avec l'approche traditionnelle, le client (ou un prestataire unique) pilotait l'ensemble des activités effectuées par tous les fournisseurs. Avec l'automatisation de la gestion des ressources, il n'y a plus de multiples prestataires à suivre mais un seul, responsable de l'assemblage des différentes ressources mises à disposition sans interlocuteur intermédiaire.

    Cette nouvelle organisation impacte la valeur ajoutée perçue des grosses entreprises qui intègrent l'ensemble des compétences de la chaîne. Ce qui était précédemment un avantage déterminant en terme de gestion de projet (meilleure communication entre les différents intervenants, méthodologie commune, ...) est maintenant à la portée d'intégrateurs de plus petite taille manipulant des ressources virtuelles. Le nombre d'intermédiaires est réduit, les délais sont raccourcis, l'organisation est simplifiée.

    Plusieurs points doivent être néanmoins examinés avec attention pour s'assurer que cette vision idéale ne soit pas dégradée :
    • importance des opérateurs télécoms : la communication entre les différents fournisseurs de ressources est un élément critique. Une mauvaise interconnection avec les fournisseurs et c'est toute la chaîne qui en pâtit.
    • responsabilité : l'avantage du fournisseur intégré est encore la prise de responsabilité unique, le dos qui prendra la bâton en cas de problème.
    En copiant les mécanismes de résilience d'Internet (si un problème survient à
    un endroit du réseau, les données pourront transiter par un autre chemin), on
    peut agréger différents fournisseurs de la même prestation et activer tel ou
    tel prestataire en fonction de la charge, des tarifs, ...

    A la crainte de dilution de responsabilité à travers une myriade de fournisseurs, on peut opposer :
    • l'intérêt de chacun des prestataires à la qualité de sa source principale de revenu
    • le bénéfice de la mutualisation des efforts des vendeurs d'API pour tous leurs clients

    La mise à disposition de web-services offrant des fonctionnalités prêtes à
    l'emploi commence à démocratiser l'approche du développement basée sur
    l'assemblage.

    Cette tendance possède de nombreuses vertus mais nécessite un changement d'état
    d'esprit pour en tirer tous les bénéfices : passer du "je contrôle toute la
    chaîne technique" à "je m'appuie sur des forces extérieures à mon entreprise"
    pour aller plus vite, faire baisser mes coûts, augmenter la qualité.
    En un mot comme en cent, passer de l'IT traditionnel au mode Internet.

    Aucun commentaire:

    Enregistrer un commentaire