A lire sur: http://cloud-experience.fr/le-cloud-et-la-parabole-du-restaurant.html
le 18 avril 2013
le 18 avril 2013 |
Expliquer à votre grand-mère ce qu’est le cloud computing n’est pas chose facile. Lorsque je dois me lancer dans de telles explications, j’aime bien utiliser la parabole du restaurant. Rappelons tout d’abord le principe : la parabole est un genre littéraire, consistant en une comparaison développée dans un récit conventionnel dont les éléments sont empruntés à la vie quotidienne. |
Dans l’acte banal d’aller déjeuner au restaurant, il y a pas mal
d’analogies qu’on peut faire avec le cloud computing et qui permettront à
votre grand-mère de mieux comprendre.
Le catalogue de services
Prenons pour commencer la carte que vient de vous apporter le maître d’hôtel. En l’ouvrant, vous allez choisir parmi un ensemble d’entrées, de plats de résistance, de desserts, de boissons, ce que vous souhaitez consommer. Cette carte c’est évidemment le portail de services d’un cloud de type IaaS (Infrastructure as a Service) privé, public ou hybride dans lequel les entrées, les plats de résistance, et les desserts sont des services de nature ou de gabarit différents… Chaque service/plat est décrit avec plus ou moins de précision et un tarif est associé pour chaque ligne figurant sur la carte. »
Pour séduire le client, la carte doit être à la fois complète, mais pas trop. En effet, comment réagiriez-vous devant une carte avec 50 entrées, 80 plats et 40 desserts ? Dans le cloud, il faut identifier les bons services, ceux qui seront utilisés par le plus grand nombre de vos utilisateurs, et créer le catalogue de services en conséquence. Au restaurant, si un client demande un beau jour une morue au chocolat introuvable sur la carte, deux réactions possibles. Soit la serveuse vous propose de prendre la morue de la carte, soit elle demande au cuistot de préparer votre morue au chocolat rien que pour vous. Dans ce dernier cas, préparez-vous à payer un joli supplément !
Puisqu’on parle de tarifs, dans votre catalogue de services, arrangez-vous pour que vos services soient au prix du marché. Ceci est surtout valable pour les services à faible valeur ajoutée, comme une VM brute de fonderie. Vos utilisateurs connaissent les tarifs pratiqués par les mastodontes du cloud public, et vous aurez du mal à leur proposer une VM avec 1 vCPU et 2 Go à 500 €/mois sur votre cloud privé. Idem au restaurant. Si vous voyez l’œuf mayonnaise à 30€, peu de chances que vous choisissiez cette entrée… A moins que l’œuf mayo ne soit accompagné de caviar ou de truffes…. On le voit bien, le prix du service dépend donc de la valeur qu’il apporte. Les tarifs pratiqués par les restaurants étoilés sont au-dessus de ceux de Flunch, mais la valeur est légèrement différente.
Revenons dans notre restaurant. Vous avez consulté la carte, et choisi les plats en fonction de votre appétit, et peut-être aussi en fonction du tarif de chaque plat (ou du ratio apparent prix/valeur). L’heure est venue de passer votre commande à la serveuse.
Vous avez envie d’une entrecôte maître d’hôtel, mais allez-vous choisir l’entrecôte de 150g, ou celle de 250g ? C’est un peu comme le choix entre les tailles de VM : petite, moyenne, grosse.
Mieux encore, avec l’inévitable question « et quelle cuisson, l’entrecôte ? », la serveuse vous a même demandé un niveau de SLA : bleu, saignante, à point, et bien cuite (je vous déconseille le SLA « bien cuite »). C’est un peu comme pour ma VM, je peux choisir une VM simple, une VM répliquée, une VM sauvegardée.
L’orchestration
Votre commande est prête à être transmise en cuisine. Un processus d’orchestration va être déroulé pour préparer votre entrecôte maître d’hôtel. En langage cloud, on parlerait plutôt de l’instanciation d’une entrecôte maître d’hôtel… Des ressources (l’entrecôte, les haricots verts, du sel, du poivre..) vont être prélevées dans des pools de ressources mutualisées. Ce sont ici les réfrigérateurs, qui contiennent les ingrédients nécessaires à la confection de tous les plats pour le service de déjeuner. Les ressources sont mutualisées. C’est le même pool de haricots verts qui sera utilisé pour votre entrecôte et pour le confit de canard de la table voisine.
Ensuite, des actions vont être enchaînées dans un ordre bien établi afin de préparer votre entrecôte. En effet, il est préférable de mettre l’entrecôte dans la poêle, d’allumer le gaz, de retourner l’entrecôte, de la servir dans l’assiette, le tout dans cet ordre. Evitez par exemple d’allumer le feu sous la poêle seulement après avoir servi votre entrecôte dans l’assiette.
J’ai parlé de «Supply Chain IT». Vous voyez c’est à dessein. Après avoir mis en place les deux étapes précédentes, nous arrivons bien à l’élaboration d’une véritable stratégie de sourcing d’énergie numérique. Concept flatteur, non ?
Même si dans notre exemple ce sont des opérateurs humains qui vont préparer votre entrecôte, on va considérer que le processus est globalement automatisé. En ce sens que personne n’ira consulter le livre de recettes de cuisine pour préparer les plats des clients, et que l’enchaînement des tâches est subordonné à l’acquittement des sous-processus (si ma sauce béarnaise est loupée, je lance immédiatement un processus de recovery en préparant une nouvelle sauce). Lorsque toutes les étapes ont été réalisées dans l’ordre et avec succès, le service est prêt à être provisionné vers l’utilisateur final. La serveuse prend l’assiette et vient vous l’apporter sur votre table. Le SLA explicite a été atteint : votre entrecôte est chaude, cuite selon votre gout. Et idéalement, avec un délai de provisionning compatible avec les standards du marché. Si vous avez attendu 4 à 6 semaines votre entrecôte, un conseil : changez de restaurant.
Et le bursting ?
Lorsque le chef a préparé sa commande de viande à Rungis, il a fait du capacity planning. A partir de son expérience, de la saison (inutile de sur-provisionner des châtaignes en dehors de la période de Noël), il a imaginé combien d’entrecôtes il allait servir ce midi, et a donc provisionné le nombre d’entrecôtes en conséquence. Mais c’était sans compter sur l’arrivée massive d’un car de touristes qui ont tous commandé de l’entrecôte. Que faire ? La solution de facilité ? Leur proposer d’autres services de substitution (« il me reste de très bons faux-filets »)
Mais si les clients menacent de quitter le restaurant, pas d’autre solution que de tenter un entrecôte-bursting. En d’autres termes, aller sourcer le complément d’entrecôtes en dehors de votre restaurant. La boucherie du coin est un excellent site pour faire de l’entrecôte-bursting. En ce qui concerne les API’s, pas besoin de choses très sophistiquées. Un banal « get_entrecôte » suivi d’un nécessaire « pay_entrecôte » feront l’affaire ! Vous burstez juste le nombre nécessaire d’entrecôtes manquantes, pour satisfaire le pic d’activité créé par le car de touristes.
Pas nécessaire d’informer le client final de votre manipulation de bursting. Le service « entrecôte maître d’hôtel » sera provisionné, avec le même niveau de SLA, et au même prix que les entrecôtes « maison » que vous avez servies à vos premiers clients.
Voilà, en termes certes réducteurs, mais imagés, ce que permet le cloud bursting : faire du débordement de charge vers un cloud externe pour satisfaire un pic d’activités.
Un café et l’addition !
Vous venez de terminer votre entrecôte, la serveuse va décommissionner votre assiette, vos couverts, et vous demander « un dessert ? ». Je vous laisse le choix de la consommation de services cloud complémentaires selon votre appétit… Puis, pour finir vous allez demander »un café et l’addition s’il vous plait ». Ceci va déclencher le processus de facturation, calculée en fonction du nombre de plats que vous avez consommés, à partir des tarifs indiqués dans le catalogue de service. La boucle est bouclée.
Alors, la prochaine fois que vous amènerez votre grand-mère au restaurant et qu’elle vous demandera « explique-moi donc un peu ce que c’est que ton cloud », vous aurez une réponse toute trouvée….
Le catalogue de services
Prenons pour commencer la carte que vient de vous apporter le maître d’hôtel. En l’ouvrant, vous allez choisir parmi un ensemble d’entrées, de plats de résistance, de desserts, de boissons, ce que vous souhaitez consommer. Cette carte c’est évidemment le portail de services d’un cloud de type IaaS (Infrastructure as a Service) privé, public ou hybride dans lequel les entrées, les plats de résistance, et les desserts sont des services de nature ou de gabarit différents… Chaque service/plat est décrit avec plus ou moins de précision et un tarif est associé pour chaque ligne figurant sur la carte. »
Pour séduire le client, la carte doit être à la fois complète, mais pas trop. En effet, comment réagiriez-vous devant une carte avec 50 entrées, 80 plats et 40 desserts ? Dans le cloud, il faut identifier les bons services, ceux qui seront utilisés par le plus grand nombre de vos utilisateurs, et créer le catalogue de services en conséquence. Au restaurant, si un client demande un beau jour une morue au chocolat introuvable sur la carte, deux réactions possibles. Soit la serveuse vous propose de prendre la morue de la carte, soit elle demande au cuistot de préparer votre morue au chocolat rien que pour vous. Dans ce dernier cas, préparez-vous à payer un joli supplément !
Puisqu’on parle de tarifs, dans votre catalogue de services, arrangez-vous pour que vos services soient au prix du marché. Ceci est surtout valable pour les services à faible valeur ajoutée, comme une VM brute de fonderie. Vos utilisateurs connaissent les tarifs pratiqués par les mastodontes du cloud public, et vous aurez du mal à leur proposer une VM avec 1 vCPU et 2 Go à 500 €/mois sur votre cloud privé. Idem au restaurant. Si vous voyez l’œuf mayonnaise à 30€, peu de chances que vous choisissiez cette entrée… A moins que l’œuf mayo ne soit accompagné de caviar ou de truffes…. On le voit bien, le prix du service dépend donc de la valeur qu’il apporte. Les tarifs pratiqués par les restaurants étoilés sont au-dessus de ceux de Flunch, mais la valeur est légèrement différente.
Revenons dans notre restaurant. Vous avez consulté la carte, et choisi les plats en fonction de votre appétit, et peut-être aussi en fonction du tarif de chaque plat (ou du ratio apparent prix/valeur). L’heure est venue de passer votre commande à la serveuse.
Vous avez envie d’une entrecôte maître d’hôtel, mais allez-vous choisir l’entrecôte de 150g, ou celle de 250g ? C’est un peu comme le choix entre les tailles de VM : petite, moyenne, grosse.
Mieux encore, avec l’inévitable question « et quelle cuisson, l’entrecôte ? », la serveuse vous a même demandé un niveau de SLA : bleu, saignante, à point, et bien cuite (je vous déconseille le SLA « bien cuite »). C’est un peu comme pour ma VM, je peux choisir une VM simple, une VM répliquée, une VM sauvegardée.
L’orchestration
Votre commande est prête à être transmise en cuisine. Un processus d’orchestration va être déroulé pour préparer votre entrecôte maître d’hôtel. En langage cloud, on parlerait plutôt de l’instanciation d’une entrecôte maître d’hôtel… Des ressources (l’entrecôte, les haricots verts, du sel, du poivre..) vont être prélevées dans des pools de ressources mutualisées. Ce sont ici les réfrigérateurs, qui contiennent les ingrédients nécessaires à la confection de tous les plats pour le service de déjeuner. Les ressources sont mutualisées. C’est le même pool de haricots verts qui sera utilisé pour votre entrecôte et pour le confit de canard de la table voisine.
Ensuite, des actions vont être enchaînées dans un ordre bien établi afin de préparer votre entrecôte. En effet, il est préférable de mettre l’entrecôte dans la poêle, d’allumer le gaz, de retourner l’entrecôte, de la servir dans l’assiette, le tout dans cet ordre. Evitez par exemple d’allumer le feu sous la poêle seulement après avoir servi votre entrecôte dans l’assiette.
J’ai parlé de «Supply Chain IT». Vous voyez c’est à dessein. Après avoir mis en place les deux étapes précédentes, nous arrivons bien à l’élaboration d’une véritable stratégie de sourcing d’énergie numérique. Concept flatteur, non ?
Même si dans notre exemple ce sont des opérateurs humains qui vont préparer votre entrecôte, on va considérer que le processus est globalement automatisé. En ce sens que personne n’ira consulter le livre de recettes de cuisine pour préparer les plats des clients, et que l’enchaînement des tâches est subordonné à l’acquittement des sous-processus (si ma sauce béarnaise est loupée, je lance immédiatement un processus de recovery en préparant une nouvelle sauce). Lorsque toutes les étapes ont été réalisées dans l’ordre et avec succès, le service est prêt à être provisionné vers l’utilisateur final. La serveuse prend l’assiette et vient vous l’apporter sur votre table. Le SLA explicite a été atteint : votre entrecôte est chaude, cuite selon votre gout. Et idéalement, avec un délai de provisionning compatible avec les standards du marché. Si vous avez attendu 4 à 6 semaines votre entrecôte, un conseil : changez de restaurant.
Et le bursting ?
Lorsque le chef a préparé sa commande de viande à Rungis, il a fait du capacity planning. A partir de son expérience, de la saison (inutile de sur-provisionner des châtaignes en dehors de la période de Noël), il a imaginé combien d’entrecôtes il allait servir ce midi, et a donc provisionné le nombre d’entrecôtes en conséquence. Mais c’était sans compter sur l’arrivée massive d’un car de touristes qui ont tous commandé de l’entrecôte. Que faire ? La solution de facilité ? Leur proposer d’autres services de substitution (« il me reste de très bons faux-filets »)
Mais si les clients menacent de quitter le restaurant, pas d’autre solution que de tenter un entrecôte-bursting. En d’autres termes, aller sourcer le complément d’entrecôtes en dehors de votre restaurant. La boucherie du coin est un excellent site pour faire de l’entrecôte-bursting. En ce qui concerne les API’s, pas besoin de choses très sophistiquées. Un banal « get_entrecôte » suivi d’un nécessaire « pay_entrecôte » feront l’affaire ! Vous burstez juste le nombre nécessaire d’entrecôtes manquantes, pour satisfaire le pic d’activité créé par le car de touristes.
Pas nécessaire d’informer le client final de votre manipulation de bursting. Le service « entrecôte maître d’hôtel » sera provisionné, avec le même niveau de SLA, et au même prix que les entrecôtes « maison » que vous avez servies à vos premiers clients.
Voilà, en termes certes réducteurs, mais imagés, ce que permet le cloud bursting : faire du débordement de charge vers un cloud externe pour satisfaire un pic d’activités.
Un café et l’addition !
Vous venez de terminer votre entrecôte, la serveuse va décommissionner votre assiette, vos couverts, et vous demander « un dessert ? ». Je vous laisse le choix de la consommation de services cloud complémentaires selon votre appétit… Puis, pour finir vous allez demander »un café et l’addition s’il vous plait ». Ceci va déclencher le processus de facturation, calculée en fonction du nombre de plats que vous avez consommés, à partir des tarifs indiqués dans le catalogue de service. La boucle est bouclée.
Alors, la prochaine fois que vous amènerez votre grand-mère au restaurant et qu’elle vous demandera « explique-moi donc un peu ce que c’est que ton cloud », vous aurez une réponse toute trouvée….
Aucun commentaire:
Enregistrer un commentaire