A lire sur: http://cloud-experience.fr/exercice-de-dissection-d%E2%80%99une-architecture-de-reference-cloud.html
le 21 juin 2013
le 21 juin 2013 |
Au risque de vous paraître obsédé, je vais encore revenir sur un thème qui m’est cher. Celui du cadre de référence indispensable pour débattre d’une architecture Cloud. Les rendez-vous, les discussions, les débats (épiques parfois) s’enchainent à un rythme sans précédent tandis que la communauté du cumulus n’arrive toujours pas à se mettre d’accord pour fournir l’architecture de référence fonctionnelle qui servira de grille de lecture et de cadre commun pour discuter du cloud. |
Est-ce trivial ? Non. Est-ce possible ? Certainement. Comment faire ?
Je vous propose trois exercices simples. Cerise sur le nuage, cela
vous obligera à réfléchir aux divers aspects qui constituent le cloud :
1- Jetez sur papier un objectif simple (le fameux KISS : par exemple, je veux être en capacité de fournir tous les types de services prêts à l’emploi au travers d’un portail en visant la meilleure équation prix/valeur/délai)
2- Etudiez attentivement les architectures Cloud qui existent déjà : IHM, exposition du catalogue de service, options proposées, mode de delivery des services, fonctionnalités, …
3- Croisez les deux. Cela devrait vous amener à des conclusions relativement similaires aux miennes.
C’est fait ? Vous pouvez lire la suite et comparer.
Le concept d’une « Cloud Management Platform »
A mon sens, la première décision à prendre est de s’affranchir d’une vision très hiérarchique avec un service IaaS (Infrastructure as a Service) à la base, un service PaaS (Platform as a Service) au milieu et un service SaaS (Software as a Service) en haut. Cela donne l’impression que pour assurer la livraison de services SaaS, il est également nécessaire d’offrir des services PaaS et à minima IaaS. Vous et moi savons que ce n’est pas forcément le cas. De nombreuses entreprises se contentent de fournir des services SaaS sans IaaS. De la même façon, nous pouvons faire du PaaS sans IaaS. Cette vision hiérarchique d’une architecture cloud introduit des rigidités conceptuelles inutiles et perturbantes.
Après cet exercice de destruction créative – qui nous simplifie la vie – la seule question qui reste consiste à se demander ce que doivent être les fonctionnalités requises pour assurer la livraison de tous les types de services tel qu’énoncés ci-dessus.
Afin de bien nous comprendre, revenons un instant sur le concept de service tant en largeur qu’en profondeur.
La nature du service dans un Cloud
Nous parlons tous des « services cloud », alors que ce terme est souvent utilisé pour désigner des réalités parfois très diverses. Quelques-uns d’entre nous sautent allègrement d’un service cloud composite à l’approvisionnement d’une banale machine virtuelle, sans transition. C’est un raccourci un peu rapide.
En tant qu’utilisateur final, je souhaite accéder à des services adaptés à mes besoins, et pas seulement « une VM petite, moyenne ou grosse ».
Pour illustrer, prenons un exemple. Imaginons que je sois responsable d’un projet XYZ de R&D et chargé de développer un des produits nouvelle génération pour mon entreprise. Pour la phase de développement, mon entreprise a tissé des liens avec trois universités réparties aux quatre coins du globe. Pour toutes ces raisons, je vais avoir besoin d’outils de collaboration. Bien sûr je manque de temps et il faut que je puisse disposer de cet environnement en moins d’une journée.
Par conséquent, je rêverais de pouvoir accéder à un catalogue de services (en fait un bouquet de services) et simplement cliquer sur « service de collaboration de projet » qui puisse se mettre en œuvre ce service en un seul clic. Dans cette hypothèse, le service que je recherche comprendra sûrement un certain nombre de services élémentaires combinés qui me fourniront la fonctionnalité requise.
Par exemple, je peux imaginer que le service de collaboration de projet comprenne les éléments suivants :
• une adresse électronique attribuée à mon projet, les mails étant automatiquement transférés vers mon adresse mail ;
• un environnement SharePoint dans lequel tout notre savoir-faire sera déposé pendant toute la durée de vie du projet ;
• un site Wiki pour développer la documentation ;
• un forum permettant aux membres des différentes équipes de communiquer entre eux ;
• une plate-forme d’échange d’idées permettant de fournir des suggestions et de choisir les plus appropriées ;
• un environnement de salle virtuelle (tel que MyRoom) permettant la collaboration en temps réelle et le partage de documents.
Bien sûr chacun des éléments du service pourrait être proposé de manière individuelle dans le catalogue. Mais du point de vue de l’utilisateur, il ne s’agit que d’éléments constitutifs du service « environnement du projet XYZ ». Chaque élément constitutif va consommer un ensemble de ressources afin d’assurer sa fonctionnalité. Et pour compliquer encore davantage les choses, le serveur de messagerie de mon projet pourrait fort bien tourner sur des serveurs dédiés, l’environnement SharePoint résider sur d’autres serveurs derrière un pare-feu, le site Wiki être hébergé sur un cloud géré, le forum sur un cloud public et enfin la plate-forme d’échange d’idées et la salle virtuelle être agrégée en tant que services SaaS.
En tant qu’utilisateur final, je ne souhaite pas avoir à me soucier des subtilités de tous ces environnements spécifiques utilisés lors de mon projet. Je veux simplement utiliser des services proposés dans un catalogue de services adapté à mes besoins.
Bon, nous y sommes je crois. Alors de quoi ai-je donc besoin pour fabriquer le « bon service » et tous ceux qui seront nécessaires pour couvrir les besoins de l’entreprise ?
Cloud Management Platform : quatre couches de fonctionnalités
Pour fournir ce service de manière globale, nous avons besoin de trois couches, chacune étant dédiée à une fonctionnalité spécifique.
• La couche d’interface ou de « gestion de la demande » : c’est elle qui interagit directement avec l’utilisateur, lui indique les services disponibles ainsi que ceux déjà approvisionnés, lui permet de choisir un service et gère le cycle d’approbation associé à cette demande. La couche de demande est axée sur les services publiés.
• La couche d’orchestration ou « d’assemblage/livraison » : elle va décomposer le service requis en plusieurs éléments constitutifs, garantir que les ressources sont disponibles pour chaque sous-élément, et par conséquent pour assurer le service final. Ensuite, cette couche déclenche et gère les processus d’approvisionnement.
• Il est important de noter qu’une couche de design est requise afin de pouvoir définir les services: ici vous allez modéliser les offres qui seront exposées dans le portail. Le designer doit être intuitif, graphique, facile d’utilisation. Le modèle construit doit être lisible, évolutif, maintenable, rapide à fabriquer. C’est la couche d’orchestration qui va interpréter le modèle de service.
• La couche de fourniture des ressources ou « d’accès universel » fonctionne de façon étroite avec la couche d’orchestration pour lui fournir toutes les ressources requises par chaque élément de service. Cela comprend des serveurs, du stockage, des réseaux, mais également des clés de licence, des adresses IP, des éléments de réseau, etc.
A ce stade nous sommes bien entrés en plein dans le sujet du cadre de référence et comme vous le voyez, nous sommes bien loin d’une vision IaaS/PaaS/SaaS. Je m’arrête là pour aujourd’hui. Mais « I’ll be back ». Prochain post : nous rentrons dans le détail de la couche « Demande ».
Auteur : Jean-Marc Defaut
1- Jetez sur papier un objectif simple (le fameux KISS : par exemple, je veux être en capacité de fournir tous les types de services prêts à l’emploi au travers d’un portail en visant la meilleure équation prix/valeur/délai)
2- Etudiez attentivement les architectures Cloud qui existent déjà : IHM, exposition du catalogue de service, options proposées, mode de delivery des services, fonctionnalités, …
3- Croisez les deux. Cela devrait vous amener à des conclusions relativement similaires aux miennes.
C’est fait ? Vous pouvez lire la suite et comparer.
Le concept d’une « Cloud Management Platform »
A mon sens, la première décision à prendre est de s’affranchir d’une vision très hiérarchique avec un service IaaS (Infrastructure as a Service) à la base, un service PaaS (Platform as a Service) au milieu et un service SaaS (Software as a Service) en haut. Cela donne l’impression que pour assurer la livraison de services SaaS, il est également nécessaire d’offrir des services PaaS et à minima IaaS. Vous et moi savons que ce n’est pas forcément le cas. De nombreuses entreprises se contentent de fournir des services SaaS sans IaaS. De la même façon, nous pouvons faire du PaaS sans IaaS. Cette vision hiérarchique d’une architecture cloud introduit des rigidités conceptuelles inutiles et perturbantes.
Après cet exercice de destruction créative – qui nous simplifie la vie – la seule question qui reste consiste à se demander ce que doivent être les fonctionnalités requises pour assurer la livraison de tous les types de services tel qu’énoncés ci-dessus.
Afin de bien nous comprendre, revenons un instant sur le concept de service tant en largeur qu’en profondeur.
La nature du service dans un Cloud
Nous parlons tous des « services cloud », alors que ce terme est souvent utilisé pour désigner des réalités parfois très diverses. Quelques-uns d’entre nous sautent allègrement d’un service cloud composite à l’approvisionnement d’une banale machine virtuelle, sans transition. C’est un raccourci un peu rapide.
En tant qu’utilisateur final, je souhaite accéder à des services adaptés à mes besoins, et pas seulement « une VM petite, moyenne ou grosse ».
Pour illustrer, prenons un exemple. Imaginons que je sois responsable d’un projet XYZ de R&D et chargé de développer un des produits nouvelle génération pour mon entreprise. Pour la phase de développement, mon entreprise a tissé des liens avec trois universités réparties aux quatre coins du globe. Pour toutes ces raisons, je vais avoir besoin d’outils de collaboration. Bien sûr je manque de temps et il faut que je puisse disposer de cet environnement en moins d’une journée.
Par conséquent, je rêverais de pouvoir accéder à un catalogue de services (en fait un bouquet de services) et simplement cliquer sur « service de collaboration de projet » qui puisse se mettre en œuvre ce service en un seul clic. Dans cette hypothèse, le service que je recherche comprendra sûrement un certain nombre de services élémentaires combinés qui me fourniront la fonctionnalité requise.
Par exemple, je peux imaginer que le service de collaboration de projet comprenne les éléments suivants :
• une adresse électronique attribuée à mon projet, les mails étant automatiquement transférés vers mon adresse mail ;
• un environnement SharePoint dans lequel tout notre savoir-faire sera déposé pendant toute la durée de vie du projet ;
• un site Wiki pour développer la documentation ;
• un forum permettant aux membres des différentes équipes de communiquer entre eux ;
• une plate-forme d’échange d’idées permettant de fournir des suggestions et de choisir les plus appropriées ;
• un environnement de salle virtuelle (tel que MyRoom) permettant la collaboration en temps réelle et le partage de documents.
Bien sûr chacun des éléments du service pourrait être proposé de manière individuelle dans le catalogue. Mais du point de vue de l’utilisateur, il ne s’agit que d’éléments constitutifs du service « environnement du projet XYZ ». Chaque élément constitutif va consommer un ensemble de ressources afin d’assurer sa fonctionnalité. Et pour compliquer encore davantage les choses, le serveur de messagerie de mon projet pourrait fort bien tourner sur des serveurs dédiés, l’environnement SharePoint résider sur d’autres serveurs derrière un pare-feu, le site Wiki être hébergé sur un cloud géré, le forum sur un cloud public et enfin la plate-forme d’échange d’idées et la salle virtuelle être agrégée en tant que services SaaS.
En tant qu’utilisateur final, je ne souhaite pas avoir à me soucier des subtilités de tous ces environnements spécifiques utilisés lors de mon projet. Je veux simplement utiliser des services proposés dans un catalogue de services adapté à mes besoins.
Bon, nous y sommes je crois. Alors de quoi ai-je donc besoin pour fabriquer le « bon service » et tous ceux qui seront nécessaires pour couvrir les besoins de l’entreprise ?
Cloud Management Platform : quatre couches de fonctionnalités
Pour fournir ce service de manière globale, nous avons besoin de trois couches, chacune étant dédiée à une fonctionnalité spécifique.
• La couche d’interface ou de « gestion de la demande » : c’est elle qui interagit directement avec l’utilisateur, lui indique les services disponibles ainsi que ceux déjà approvisionnés, lui permet de choisir un service et gère le cycle d’approbation associé à cette demande. La couche de demande est axée sur les services publiés.
• La couche d’orchestration ou « d’assemblage/livraison » : elle va décomposer le service requis en plusieurs éléments constitutifs, garantir que les ressources sont disponibles pour chaque sous-élément, et par conséquent pour assurer le service final. Ensuite, cette couche déclenche et gère les processus d’approvisionnement.
• Il est important de noter qu’une couche de design est requise afin de pouvoir définir les services: ici vous allez modéliser les offres qui seront exposées dans le portail. Le designer doit être intuitif, graphique, facile d’utilisation. Le modèle construit doit être lisible, évolutif, maintenable, rapide à fabriquer. C’est la couche d’orchestration qui va interpréter le modèle de service.
• La couche de fourniture des ressources ou « d’accès universel » fonctionne de façon étroite avec la couche d’orchestration pour lui fournir toutes les ressources requises par chaque élément de service. Cela comprend des serveurs, du stockage, des réseaux, mais également des clés de licence, des adresses IP, des éléments de réseau, etc.
A ce stade nous sommes bien entrés en plein dans le sujet du cadre de référence et comme vous le voyez, nous sommes bien loin d’une vision IaaS/PaaS/SaaS. Je m’arrête là pour aujourd’hui. Mais « I’ll be back ». Prochain post : nous rentrons dans le détail de la couche « Demande ».
Auteur : Jean-Marc Defaut
Aucun commentaire:
Enregistrer un commentaire