Deuxième lecture d’une série de trois visant à m’améliorer en tant que programmeur d’informatique nuagique développant essentiellement au tour d’applications distribuées. (La première lecture était Cloud Application Architectures.) À quoi m’attendais-je avec ce livre? Apprendre comment gérer (ou « manager » comme le « plug » le titre) une grille informatique. Qu’est-ce que j’ai appris? Pas mal l’histoire de l’informatique en grille pré 2006, année de publication du livre.
Pour refaire le même exercice qu’a mon billet sur ma lecture précédente, un titre plus approprié pour ce livre aurait été « Grid Computing: The savvy manager’s manager’s history guide ». Oui, « manager’s manager’s » car le bouquin ne parle pas tant de comment gérer la grille soi-même mais en dit quand même assez pour être en mesure de dire au «vrai gestionnaire» de la grille quoi faire.
Côté positif: j’ai aimé le fait que les auteurs prennent le temps d’expliquer clairement les termes introduits au lecteur à mesure qu’ils se présentent.
Pour le reste…
Une référence web qui est fréquemment présente « Visit the book online companion at savvygrid.com! » où les lecteurs sont invités à partager sur le sujet des grilles et où l’information doit évoluer. Qu’est-ce qu’on y trouve? Une page aux allures des années ’90 et aucune discussion. Raté pour compagnon enligne
Ensuite il y a de nombreux exemples (« case study ») d’entreprises qui ont amélioré leur infrastructure avec une grille. C’est bien, mais en tant que «gestionnaire» ça ne nous aide pas trop à voir comment faire pour «notre architecture». On fait également référence aux problèmes «parallèles de manière embarrassante», donc hyper faciles à paralléliser, mais peu d’indices sur comment paralléliser un programme qui n’est pas «embarrassant» au delà du découpage vertical[*].
Pour finir en beauté, le livre s’écarte du sujet et parle « d’extreme programming » et de méthode de développement agile. Okay… Le prétexte est de fournir des moyens de développement pour adapter ses programmes à la grille. À mon avis, ça frise le hors sujet, mais, ça reste du contenu de gestionnaire. (Pour être équitable, on parle également des risques associés, de gestion du facteur humain, du besoin ou non de consultants, etc., ce qui cadre bel et bien la gestion.)
Un dernier point: tel que mentionné au début du billet, le livre a été écrit en 2006. Devinez ce qui y manque cruellement? Le nuage, qui est pas mal un « game changer » dans le domaine. Alors que le bouquin parle de l’utilité d’incorporer tous les ordinateurs d’un réseau à une grille afin de bénéficier de leur puissance de calcul hors des heures de travail, à quoi bon se casser la tête avec tous les problèmes reliés (sécurité, accès, fiabilité, etc.) alors qu’on peut avoir un bel environnement facile à gérer dans le nuage? Pour un projet tel que Folding at Home, ce concept reste valable, mais pour une entreprise, je doute que cette stratégie soit encore pertinente. L’ordinateur de bureau moyen a besoin de capacités très faibles pour effectuer les tâches quotidiennes versus le type de serveurs hyper puissants disponibles dans le nuage. (Au bureau, nous utilisons essentiellement des mac minis: bicoeur 2.5Ghz, 4Go de mémoire vive. Un serveur amazon r3.8xlarge: 2.5 à 3.3Ghz 32 coeurs, 240Go de mémoire vive, coûte généralement moins de 30¢ de l’heure en mode « spot ». Ayoye…)
Est-ce moi qui est hors sujet maintenant en parlant du nuage alors qu’il n’en est pas fait mention dans le livre? Et bien le fait est que je crois que ce livre est passablement obsolète à cause du dit nuage. Ce dernier permet d’avoir un environnement contrôlé qui élimine les casses-têtes reliés à l’infrastructure et avec en prime des performances qui écraseront l’utilisation des PC du bureau.
Pour conclure, à mon avis ce livre a aujourd’hui surtout une valeur historique. Le sujet a tellement évolué en 8 ans qu’il ne décrit plus les solutions au problèmes présents.
* Découper les étapes d’un programme en sous-programmes qu’on peut ensuite exécuter sous différentes machines, un peu comme dans un pipeline. C’est surtout pratique si les différentes étapes demandent différentes ressources. Ainsi, une étape plus gourmande pourra être exécutée sur une machine plus puissante.
Computers
Morgan Kaufmann Pub
2006
261