vendredi 8 octobre 2010

Cloud computing et SOA comme outils de mutualisation

Les nouvelles capacités du "Cloud Computing" nous amènent à imaginer de nouveaux modes de consommation des systèmes d'information. Examinons ensemble comment faciliter le partage et la réutilisation fonctionnelle sur une plate forme Cloud.

Le cloud a entraîné l'émergence de toute une série d'acronymes plus ou moins biscornus, j'ai tenté de lier des définitions de çi de là pour éclairer le lecteur avide de connaissances.

Les offres de "Cloud Computing" de type IaaS (Infrastructure as a Service) permettent l'utilisation d'éléments techniques (CPU, RAM, stockage) à travers divers mécanismes de virtualisation. Ces derniers mutualisent, de manière transparente, l'infrastructure pour les utilisateurs.

Le fournisseur achète du matériel dont il permet l'usage partagé par ses différents clients. Ces clients peuvent être facturés proportionnellement à l'usage réel qu'ils font de la plate forme et non plus de manière forfaitaire basée sur la location d'un matériel utilisé, en général, à moins de 30% de sa capacité.

Les clients voient donc leurs factures s'alléger du fait de la mutualisation. Les fournisseurs rentabilisent mieux leur infrastructure puisque, pour prendre une analogie avec les transports, plus il y a de passagers dans le train, meilleure est la rentabilité.

Une architecture SOA offre une approche similaire d'un point de vue logiciel. Un point d'accès (URL) permet à différentes applications de consommer une même fonctionnalité mutualisée. Pour cela, les web-services concernés doivent implémenter une approche multitenant afin que les données puissent être compartimentées en fonction de l'utilisateur du service.
Ici aussi, on peut envisager de faire payer l'utilisation d'un service en relation avec l'usage effectif de ce dernier, par exemple proportionnellement au nombre d'appels effectués.

Si l'on superpose les deux techniques, on obtient une plate forme qui va pouvoir adapter sa configuration matérielle en fonction du volume d'utilisation des fonctionnalités métiers qu'elle supporte.

Ainsi, le nombre d'instances d'un service accessible à travers une URL variera en fonction du nombre d'appels à traiter dans un laps de temps donné. Si la consommation d'un service connait des pics, de nouvelles instances seront démarrées automatiquement pour faire face à l'afflux de requêtes. Ces instances supplémentaires pourront être arrêtées et les ressources matérielles associées libérées une fois la consommation retombée. Ce mécanisme permet d'ajuster finement les coûts d'utilisation de l'infrastructure.
Pour poursuivre notre comparaison avec le monde ferroviaire, plus la demande est importante, plus on ajoute de wagons dans le train.

La possibilité de construire des applications par agrégation de services (de type mashup) sur ces plate-formes offre de multiples avantages :
  • gain de temps
    • pas d'installation, ni de configuration (fonctionnalité distante),
    • intégration simplifiée par simple appel d'URL, particulièrement utile dans le cadre d'évolution d'applications existantes
  • économie : coût de maintenance partagé entre tous les clients, facturation à l'usage

L'aspect maintenance est particulièrement intéressant. Dans les approches de développement classiques, la mutualisation d'une fonctionnalité s'effectue, paradoxalement, par la duplication physique du code partagé dans chaque application. Cette duplication entraine des efforts de maintenance supplémentaires. En partageant une même fonctionnalité distante, on fait disparaitre la duplication et on simplifie, par conséquence, les actions de maintenance.

Les fournisseurs d'applications et éditeurs qui adoptent ce modèle sont en mesure de proposer des tarifs particulièrement intéressants grâce à la réutilisation de leur développement à un niveau de granularité plus fin que celui des applications packagées. En effet, une fonctionnalité, si elle est suffisamment indépendante de son cas d'usage, peut souvent être réutilisée dans des domaines non prévus initialement.

Une fonctionnalité de prise de rendez vous proposée sous forme de service ou de widget peut être vendue pour des usages plus larges que si elle est intégrée directement dans un logiciel métier. Par exemple, une application pour un cabinet dentaire et pour un garage automobile pourront toutes deux utiliser le service "Prise de rendez vous" quelque soit les outils utilisés pour le développement. L'effort effectué pour construire ce service peut donc être rentabilisé plus largement puisqu'il intéresse potentiellement toutes les applications qui nécessitent cette fonctionnalité.

Les premiers utilisateurs de cette approche sont plutôt les entreprises construisant des applications en mode agile, particulièrement dans le secteur Internet et mobile. Elles recherchent de la vitesse dans la réalisation des développements et des coûts optimisés en terme d'hébergement dans un secteur où l'évolution est permanente.

L'approche consistant à offrir de multiples services fonctionnels indépendants les uns des autres trouve sa place entre IaaS (Infrastructure as a Service) au niveau de l'infrastructure, PaaS (Platform as a Service) pour faciliter le développement d'applications et SaaS (Software as a Service) permettant l'utilisation d'applications en ligne.

Pour rentrer dans la grande famille XaaS et participer au grand concours mondial d'invention d'acronymes, renommons SOA en Faas pour Feature as a Service.

Et ne me dites pas que Saas ne sert à rien ...

http://www.faascape.com

Aucun commentaire:

Enregistrer un commentaire