Le cloud … pour que les nuages n’annoncent pas la tempête
Mais ce n’était que partie remise, car j’ai pu vendredi dernier (26 Mars), lors des « Entretiens Télécoms 2010″, expliquer devant un parterre de responsables réseaux, infrastructures … ma vision du sujet, qui complète bien ce que je disais déjà il y a plus d’un an.
Voici la vidéo de mes slides … un peu court sans l’oral qui va derrière, mais quelques vidéos incluses vous permettront de saisir l’essence du sujet.
En un mot, à la différence de beaucoup de professionnels parfois trop orienté dans la solution qu’ils ont à défendre, je pense que l’essentiel dans «le cloud», n’est ni l’ordinateur, ni le réseau, mais bel et bien l’application. Celui qui la contrôle, controlera le reste. Mais maintenant, si l’on veut passer du contrôle à la maitrise, il faut lui associer la supervision de bout en bout qui seule nous permet de savoir si réellement :
- cela fonctionne
- la performance attendue est toujours au rendez-vous
- on sert bien le service / l’information / l’usage attendu
Mes conclusions sont simples :
- Hors des standards OUVERTS, point de salut
- Le controle de l’application permet de ne pas se rendre définitivement triburaite d’une architecture précise et de surpasser des problèmes momentannés de qualité de service
- Piloter un système d’information ou gérer une infrastructure sans un monitoring de qualité, c’est comme piloter un avion sans instruments de bords … cela ne va souvent pas bien loin
Ajout du 30/3/2010:
Ceci dit, pour aller plus loin et surtout corriger la vision que je pourrais laisser supposer, je vous propose d’écouter Riguidel, qui a le mérite de connaître le sujet et d’avoir sa propre opinion. Même si je ne partage pas tout, il y a beaucoup des choses intéressantes à prendre. En particulier son parallèle entre l’évolution de l’informatique et des langages et des réseaux, à laquelle je souscris complètement.
Il est bien sûr, essentiel de continuer le travail sur les protocoles et le réseau et d’en avoir une vision plus « holistique » que ce que nous avons aujourd’hui. Mais il est surtout aussi fondamental d’en avoir une vision pas simplement « technicienne », mais aussi « humaine ». Sans cela, nous tenterons de faire un réseau très efficace et ne parviendrons qu’à refaire le futur de l’X25, de l’ATM ou du GSM. A quoi bon si l’on en oublie le sens des choses et le pourquoi l’on fait tout cela. Si l’Internet, avec toutes ses imperfections c’est imposé, par rapport à toute cette science, c’est qu’il y avait autre chose derrière … qu’il ne faut pas perdre de vue.
Related posts:
- Le numérique pour tous ?
- Le Cloud, nouvel eldorado ou simple Minitel 2.0 ?
- Il n’y a pas un mais DES Internets …
- Ma position sur la Loppsi : en 3 mots et en proposition
3 Comments
Oui, mais.
À quel niveau définir la standardisation ? Je suis plus que dubitatif sur la foire d’empoigne actuelle sur la standardisation des API IaaS. Et d’ailleurs ça commence à grincer sec du coté des utilisateurs. Il faut dire que ces efforts là ont un fort relent de « comment réussir à contourner le succès d’EC2 quand on a raté le coche ». Standardiser ok, mais le faire en petit comité de boîtes qui essaient de coller du « ouvert/opensource/etc » pour refaire leur retard techno et marketing, je suis moins fan.
Je ne suis vraiment pas sûr que le vrai problème soit au niveau des API IaaS: le modèle est simple, assez facile à abstraire, et c’est sûrement pas sur la façon de lancer une instance qu’on va avoir des lock-ins terrifiants.
Par contre, et c’est là où je te rejoins totalement, c’est sur la couche applicative qu’est la vraie bataille. Que ça soit Google App Engine, Amazon SimpleDB / Simple Queue Service, ou Azure, on change de monde et d’enjeu. D’abord parce qu’il y a une vraie valeur ajoutée pour une application réécrite selon des contraintes clouds, et parce qu’on est dans des bouts-d’infra-as-a-service qui sont 1/ loin d’être évident à réimplémenter 2/ trop dissimilaires pour avoir des abstractions (standards ou pas) 3/ qui ont une vraie valeur pour les développeurs d’applis.
Entièrement d’accord également sur le problème du monitoring, et c’est le truc le plus nébuleux 
Comment monitorer correctement une appli cloud ? Quand on se restreint à de la virtualisation ou du cloud IaaS, ça peut aller (encore que, avec des fonctionnalités de lancement à la demande et cie, les choses se compliquent). Mais quand on entre dans du cloud PaaS, ça devient velu: comment intégrer correctement la surveillance de l’appui de l’intérieur quand elle dépend de n services d’infra fourni par Google/Microsoft/Amazon/whatever. Ce n’est pas avec les quelques dashboards gentiment fournis par lesdits qu’on va aller bien loin…
mars 30th, 2010
[...] This post was mentioned on Twitter by JM Planche, Aurélien Fache. Aurélien Fache said: Le cloud … pour que les nuages n’annoncent pas la tempête par @jmplanche: http://bit.ly/a5WYQA #cloud [...]
Francois 2
avril 4th, 2010
Un des problème n’est-il pas d’essayer de coller sous un terme unique et fédérateur un ensemble de choses qui ne sons pas aussi similaires que cela ?
Commençons par la disquerie :
si l’on répartit la ressource disque, alors on peut supposer que chacun met a disposition tout ou partie de ses Go (To…) disponibles, tout en profitant en retour de la ressource du réseau.
Oui mais voila, lorsqu’on est déconnecté du réseau, que reste-t-il chez soi, et dans le reste du réseau ?
On doit donc concevoir deux notions, selon que le raccordement est permanent ou non…
En mode quasi permanent, on aboutit a un concept de Net-RAID, avec une redondance modérée ce qui permettrait a une entreprise, par exemple, de disposer d’un grand espace de stockage pour un cout marginal des équipements pas chers du marché… Encore faudrait-il que cromou comprenne la question, et intègre un tel driver dans son OS… RdV en 2030… l’open source arrivera avant A quand un EXT+ réseau ??
En mode non connecté en permanence (de logique Internet grand public) on doit assurer deux notions complémentaires plus lourdes : assurer un cache de ce que l’on avait en commun lors du raccordement au réseau, pour soi, et une redondance beaucoup plus massive, pour les autres, car si le nombre de connectés baisse trop, la redondance risque de ne plus suffire a maintenir le disque virtuel collectif. J’attend d’ailleurs avec impatience le premier fabricant de NAS qui implémentera un tel driver de disque réseau réparti « grid storing » … (surement très apprécié des hadopitres)
Même idée donc, en apparence, et pourtant deux livrables fondamentalement différents… est-il possible de trouver un standard ? j’en doute, tant cela risque d’être lié a la structure même du file système… mais qui sait ?
Prenons maintenant la CPU :
On trouve encore plus de variantes, s’étalant de la téléapplication genre CGI/RPC qu’on consomme depuis son iPhone au number-crunching déplacé des super-calculateurs vers la communauté d’internautes a la Seti@home, en passant par les Noeuds de calcul du son pour des machins comme Apple Logic…
Si les applis unitaires pour une grande masse d’utilisateur semble assez facile a répartir par nature, la chose est plus complexe quand c’est au contraire un utilisateur qui nécessite des ressources massives… Le premier cas est juste un empilement bête et méchant de ressources, donc du cloud assez léger en design, tandis que le second a besoin que les applications soient développées en conséquences (qui veut refaire de l’OCCAM ?).. la dedans, ou sont les standards ? Plus de standard reviendrait surement a dire qu’on monte dans des surcouches d’abstraction, donc des trucs a la Java, qui écroulent les performances. On peut se demander quel est le gain final.
Si on veut gagner en performances, on en arrive a des OS optimisés, un peu comme sur les Jaguar ou Kraken, qui finalement sont un bel échantillon de cloud machines, vu l’empilement de processeurs en jeu.
Globalement, il faut peut-être savoir ce qu’on espère du cloud, de l’utilisation de la ressource CPU inutilisée (mais dont les fondeurs tendent a réduire la consommation autant que possible) au nouveau concept de communication entre les gens, sachant que tout est un seul système , sans notion d’intra ou extra.
Finalement, le moignon de concept est peut-être là, mais il manque encore un brin d’usages et donc d’applis que Jean-michel prendra grand plaisir a monitorer 
3