Note : 3 ; Ou plus exactement : Aborder Amazon EC2 pour l’ingénieur système
Aborder le Cloud quand on a pas grande idée de la chose est un exercice difficile. Le livre de George Reese a pour but de nous mettre le pied à l’étrier. En vérité, avec ses 160 pages, ce n’est pas un bien gros ouvrage. Aussi n’est-il pas surprenant de constater qu’il se focalise sur un cas particulier : le déploiement d’applications en IAAS sur Amazon EC2. Même les autres offres Amazon sont mises de côté (j pense bien sûr à S3). C’est en fait principalement les aspects système liés au déploiement sur EC2 qui sont développés ici.
Le premier chapitre se focalise sur les cas d’usage du cloud computing et les aspects économiques qui lui sont attaché.
Le second chapitre détaille l’offre Amazon, les concepts qu’il faut connaître lorsque l’on pénètre dans cet écosystème : EC2, S3 ; elastic IP, Région, EBS, etc… On y manipule déjà ces objets via les commandes permettant de créer et gérer ces différents objets. De quoi donner une dimension plus concrète au propos.
Le troisième chapitre « avant la transition » revisite le modèle économique afin de nous aider à faire un choix sur le modèle de déploiement. Les différents aspects à considérer (sauvegarde, sécurité, disponibilité, scalabilité, aspects légaux) sont abordés. J’ai bien aimé ce chapitre qui oblige à se poser de nombreuses questions préalablement à l’établissement d’une « architecture cloud ».
Le chapitre 4 est une partie assurément importante du livre car elle présente des cas d’architecture d’applications cloud. Hélas les 30 pages de ce chapitre sont plus une introduction qu’un traitement en profondeur.
Les chapitres 5 et 6 sont dédiés à la sécurité d’une part et au « disaster recovery planning » d’autre part. Ce sont deux éléments très importants d’une architecture cloud. Si la partie dédiée à la sécurité s’avère plutôt traitée en profondeur, donnant pas mal d’éléments de réflexion, le chapitre 6 donne plutôt quelques éléments sur le DRP, mais guère plus.
Qui dit « cloud » dit « scaling » et « élasticité ». Le chapitre 7 est dédié à cette question, mais là encore le point est traité assez légèrement.
Au-delà des 7 chapitres de ce livre, on notera 2 annexes dédiées à Rackspace et GoGrid. Ecrits par les CTO de ces deux entreprises, il s’agit hélas plutôt de brochures publicitaires pour ces deux offres.
En conclusion, ce livre apparaît pour moi plutôt comme une introduction au Cloud et plus particulièrement à IAAS avec EC2. Il a clairement le mérité d’amorcer les pistes de réflexions (au demeurant pas si évidentes) liées au déploiement de solutions Cloud. Il est loin d’être une référence exhaustive sur le sujet. Peut-être n’est-ce pas plus mal, car le sujet évolue vite, tout comme les différentes offres, et cela permet d’avoir un certain état de l’art en 160 pages ! L’inconvénient est l’obsolescence très rapide de ce livre.
L’offre Cloud avance et évolue à la vitesse de la lumière. Je crains qu’un texte accusant déjà 3 ans ne puisse être toujours être considéré comme pertinent.
Référence complète : Cloud Application Architectures, Building applications and infrastructure in the cloud – George Reese – O’Reilly 2009 – ISBN : 978 0 596 15636 7
Jim Coplien à propos de l’architecture DCI et de son rôle au sein d’une approche agile
Cette intervention enregistrée en 2009. Elle reprend le propos développé par Jim Coplien et Gertrud Bjornvig dans leur livre : Lean Architecture.
Sans être révolutionnaire, il y a quelques idées intéressantes. Mais qualifier cette architecture de “lean” est un peu source de confusion pour moi. Bref, en ce qui me concerne, je ne suis pas encore convaincu…
Sacha Labourey n’est pas un inconnu pour moi. Pour vous non plus peut-être. Soat nous poposait une rencontre avec cette figure marquante du monde Java à la veille de Devoxx France (je sais, ça fait déjà un bail …), je ne pouvais que sauter sur l’occasion.
Pour ceux qui l’ignoreraient, Sacha Labourey fut le CTO de JBoss après le départ de Marc Fleury, mais c’est en tant que fondateur et CEO de CloudBees qu’il se présentait à nous ce soir-là.
En fait de présentation, j’ai hélas rarement mis de photo aussi médiocre sur mon blog, mais c’est ainsi. La voilà.
CloudBees propose une plateforme pour héberger la totalité du cycle de vie d’une application Java sur le cloud. En l’occurrence, il s’agit du cloud d’Amazon, mais ils travaillent activement à rendre leur plateforme indépendante de l’infrastructure du géant de l’e-commerce afin de donner plus de flexibilité au client.
Hardware as a commodity
A la base, il y a la conviction que l’on se dirige vers une commoditifaction (est-ce vraiment un mot ?) du hardware. Sacha Labourey évoque le parallèle avec l’électricité : si à ses débuts, il fallait posséder son propre générateur et gérer les aléas de la régularité de l’alimentation, aujourd’hui nous nous sommes “débarassés” du problème chez des prestataires. Nous n’avons plus que des prises de courant nous délivrant un courant normalisé, le reste est l’affaire de ce prestataire.
Ce mouvement inéluctable : spécialisation -> standardisation -> régulation, Sacha Labourey le voit s’appliquer aujourd’hui à l’infrastructure.
Doit-on aujourd’hui encore s’occuper des machines, de les configurer, gérer les mises à jours système et même les “piles logicielles” ? Existe-t-il une valeur spécifique à se construire sa pile logicielle spécifique ? Si elle existe, elle doit être marginale (du moins dans la plupart des cas) et ne justifie pas les efforts et le détournement de focus de la problématique métier que l’on souhaite adresser.
C’est là la proposition de valeur de CloudBees : rendre l’infrastructure aussi facile à exploiter qu’une prise électrique !
Cloud vs cloud vs cloud
On peut rappeler rapidement les 3 types de cloud proposés, ils sont déjà très connus:
IaaS : Ce sont les briques de base de l’IT. On pense à Amazon EC2, Rackspace, …
SaaS : Des solutions logicielles standardisées prêtes à l’emploi. Salesforce est probablement le premier nom qui vient à l’esprit.
PaaS : Il s’adresse aux développeurs. L’objectif est de ne plus avoir à gérer les serveurs et les services standard fonctionnant dessus : serveur d’application, load balancing, etc..
Le focus est sur le “S” final : voir les facilités comme des services, disponibles sous forme d’API. Cette dématérialisation offre aussi un avantage fort : la possibilité de faire des essais (donc des erreurs) et de commencer petit. On peut ainsi itérer rapidement sans devoir attendre des mises à disposition de serveurs et des installations logicielles. Elles sont prêtes et peuvent être exploitées tout de suite. Et être abandonnées tout aussi rapidement (le serveur ne finit pas à la cave).
Pour Sacha Labourey, une architecture typique d’entreprise serait la suivante :
Au niveau back-office : les systèmes “legacy”, très stables, intégrant peu d’innovation.
Au niveau front : des applications pour mobile (par exemple) communiquant avec un back-end évoluant très rapidement au rythme des nouvelles fonctionnalités disponibles dans l’appli mobile. Cette partie est peu stable et est le siège de beaucoup d’innovations
Une communication front / back selon les protocoles mis à disposition par le back-office
Aujourd’hui la partie front / produit est subordonnée aux frictions entre développeurs et départements “opérations”. Les personnes en charge des opération privilégient la sureté de fonctionnement et renaclent le plus souvent à déployer des solutions logicielles qui n’ont pas été validées en interne, ou en tout cas ne satisfont pas des critères d’acceptabilité.
PaaS et innovation
Pour améliorer la capacité à mettre en ligne, la tendance actuelle est le “devops”, faire travailler ensemble développement et opération et outiller les opérations de déploiement afin de pouvoir pratiquer très souvent des déploiement automatisés. Je fais là un gros raccourcis et ne rends probablement pas justice à ce qu’il y a derrière devops, mais l’idée est là.
CloudBees revendique du “no ops” ! Plusieurs facteurs sont nécessaire pour permettre cela. On verra aussi que c’est un peu une simplification, l’IT ne disparait pas.
Standardiser les environnements : à l’image de l’électricité délivrée en voltage et fréquence constants, la standardisation des environnements est un facteur clé. Chez CloudBees, ces environnements standards sont les ClickStacks.
Travailler en SLA : pour pouvoir se passer d’ops, il ne faut pas avoir à se soucier de contingences d’infrastructure telles que stockage, clustering, etc… Il faut pouvoir signer un engagement de performance, à charge du prestataire de faire les mises en oeuvre d’infrastructure nécessaires pour garantir cet engagement.
Avec le SLA vient la question du support : une plateforme intégrant des sous-systèmes tiers peut être sujete à des dysfonctionnements (ou des mauvaises utilisation) de n’importe lesquels de ces composants. Il est logique que le support de service intègre complètement le support ou la délégation de support de ces composants.
Bien sûr, cela n’a de sens que si l’on est capable de mettre cela en oeuvre non seulement sur l’environnement de production, mais aussi sur les autres environnements utilisés dans le cycle de développement : environnements de développement, d’intégration, de stagging, etc… Le support du cycle de vie de l’application est donc l’étape suivante logique. L’intégration continue y joue un rôle clé.
Cycle de vie applicatif et gouvernance
C’est Jenkins qui est au centre du cycle de vie applicatif chez CloudBees. Il faut dire que Kohsuke Kawaguchi, la figure emblématique de ce projet open-source est un des leaders techniques de CloudBees !
Aujourd’hui, la partie faible me semble être toute la partie acceptance testing, AB testing etc… Mais c’est déjà le point faible de pas mal de projets. CloudBees propose quand même un environnement de stagging permettant de tester ses applications en conditions réelles : beescloud.com
Dans cette image que Sacha Labourey nous dresse, nous voyons une entreprise avec de nombreux projets, sur chacun d’eux les développeurs font des choix indépendants transformant le système d’information en gigantesque tour de Babel. Justement ce que l’IT cherche à éviter et lui vaut cette image d’épine dans le pied. Quel doit être le travail et la position du département IT, alors ?
C’est ce que Sacha Labourey appelle l’IT pragmatique : laisser faire, mais rester informés. Puis travailler en consolidation des différents projets ensuite (comment ? mystère …). De toute façon, si on bloque les projets trouveront le moyen de passer quand même !
Donc l’IT ne disparait pas, mais elle cesse de s’occuper d’infrastructure pour se concentrer sur les workflow de données, de services, etc… Elle reste le gardien du temple.
Tirer les leçons
Sacha Labourey a une vision très radicale non pas de l’IT de demain, mais de celle d’aujourd’hui :
Passer son IT sur le cloud inquiète toujours. Mais la peur ne peut pas être une stratégie ! Rester organisés à l’ancienne peut nous valoir de voir un département de 20 personnes se faire griller la politesse par “4 punks dans une cave” comme le dit Sacha !
Il faut profiter des gains compétitifs que représentent des services prêts à l’emploi.
Aujourd’hui, les investissements ne prenant pas en compte le cloud sont déjà de la création de dette ! Méditez là-dessus mes amis…
Ce que j’en vois
Sacha Labourey nous a bien secoué sur une vision du développement se passant dans le cloud, en rupture avec nos habitudes actuelles. Et il est très convainquant sur l’aspect des choses que nous n’avons plus à prendre en charge…
Pour aborder cette rupture, il faut permettre la montée en compétence progressive des équipes. Le ClickStart que propose CloudBees s’apparente surtout à des assistants logiciels. Il faut apprendre à travailler avec son usine logicielle dans le cloud. D’après notre orateur de la soirée, cela va vite. Mais quand même…
Accepter la standardisation : c’est une condition sine qua non.
On peut avoir un développement produit dans le cloud. Mais qu’en est-il de la communication front-back, si le back-office est dans les murs de l’entreprise ? C’est très probablement un point faible. A moins que le back-office soit lui-même dans le cloud, ce qui est la solution préconisée par Sacha Labourey. Un tel choix nous amène rapidement à des considération de vulnérabilité de notre entreprise, dont les avoir ont quitté les murs pour être localisés … à des endroits que nous ne savons même plus localiser ! Mais ne sommes-nous pas déjà, voir plus, vulnérables avec l’informatique chez nous ? Il y a eu pas mal d’échange avec Sacha Labourey sur ce sujet et j’avoue que ces arguments ne manquent pas de fondements. Je ne vais cependant pas les développer plus avant, cela m’emmènerai trop loin.
La présentation de ce soir-là avait un ciblage très managérial, j’ai un petit regret là-dessus, surtout que notre orateur est un expert de haut niveau. Mais ce point m’était connu à l’avance, je n’ai donc pas de regrets à avoir.
Si vous avez le courage de voir le contenu complet, la video a été mise en ligne par Soat.
Il vous faudra un peu de la persévérance, car la video dure 2h30 … et contrairement à ce que Sacha annonce au début, il oubliera de répéter les questions !
Il me reste à remercier Soat pour cette opportunité d’en savoir plus sur le développement sur le cloud en général et sur Cloudbees en particulier, avec l’un des grands noms du monde Java.
Note : 4 ; Un concept intéressant, avec un contenu plutôt hétéroclite, mais aussi certaines entrées plutôt pertinentes
Voilà un concept vraiment original : un livre collaboratif, publié en open source, compilant 97 conseils écrits par presque autant d’auteurs différents, chaque conseil tenant en 2 pages (en réalité plutôt un peu moins, environ 1 page et demi). L’intérêt de ce concept est que chaque « thing » est nécessairement concise, efficace et se doit d’aller au but, on n’a guère le temps de s’ennuyer. Le volume du livre reste aussi de taille plus que raisonnable : 195 pages dont j’estimerais que cela correspond à 150 pages d’un ouvrage plus classique.
L’ouvrage souffre quand même d’une faiblesse due au sujet traité : qu’est-ce qu’un architecte et quel est son travail ? Ainsi les conseils traitent d’aspect très diversifiés, ce qui peut être vu comme un bénéfice en élargissant le spectre des aspects traités : aspects fonctionnels, humains, performances, infrastructure matérielle, conceptions, technologies et frameworks, etc… Mais cela ressemble finalement à un grand « melting pot » qu’à un tout cohérent.
Il est d’ailleurs intéressant de voir à quel point les avis d’experts sont variés, allant de la figure paternaliste aux travail d’architecture réparti chez les développeurs eux-mêmes. Parmi les tendances que je vois se dessiner au long de ces 97 conseils :
La nécessité de connaître la substance de base : les patterns, qu’ils soient architecturaux ou de conception.
L’importance du facteur humain.
L’importance des facteurs « environnementaux » : le lien avec le contexte métier, la contrainte d’entropie du système, etc..
Au final, il y a certes des choses à jeter, mais aucun article n’est mal écrit (ils sont courts, donc les auteurs doivent faire très attention), et il y a nécessairement des choses valables.
Ce n’est pas le livre de l’année, mais je le classerais volontiers dans les « lectures amusantes ».
Référence complète : 97 Things Every Software Architect Should Know – Richard Monson-Haefel edt. – O’Reilly 2009 – ISBN : 978 0 596 52269 897
Note : 2 ; Pas aussi bien qu’espéré et souvent hors sujet
Voilà bien un sujet qui me touche de près : comment s’assurer qu’une architecture d’entreprise, composée de multiples applications interagissant, déployées sur une infrastructure ad hoc, fonctionne de façon optimale ? Quels sont les points à vérifier et les pièges à éviter ? Comment mesurer l’ensemble et surtout quoi mesurer ? Si j’ai trouvé là parfois des éléments de réponse, le livre m’a largement déçu.
Celui-ci est long de 260 pages découpées en 4 parties comptant au total 16 chapitres. Donc les chapitres ne sont pas trop longs, ce qui est une bonne nouvelle.
La première partie est consacrée à des généralités « problématiques de performance des SI ». On en prend pour 30 pages et 3 chapitres, ce qui est déjà trop car le propos est complètement creux.
La seconde partie (4 chapitres, 90 pages) est moins creuse mais d’avantage hors sujet. J’ai bien aimé les anti-patterns du chapitre 4, mais qui me disent ce que je sais déjà, sans y apporter de solution. Je n’ose même pas parler de la discussion Web Services versus Rest qui est un propos de développeur, pas d’architecte IT. Un architecte IT doit travailler avec le contexte qui s’offre à lui, il n’a pas le luxe de créer le sien. Le reste de cette partie évoque beaucoup SOA, ce qui n’est pas la raison pour laquelle j’ai acheté ce livre, et souvent n traitant des points qui sont plutôt du ressort de l’architecture logicielle (et j’ai passé l’âge de « l’architecture logicielle pour les nuls »).
La troisième partie a enfin trait au sujet du livre (on est quand même page 127). Elle revendique 70 pages sur 5 chapitres. Chaque chapitre est donc succinct, et en fait superficiel. C’est bien dommage car chacun traite d’un volet important qui mériterait que l’on s’y attarde. En fait, j’aurais bien aimé une partie pour chacun de ces chapitres, en faisant table rase du reste du bouquin ! Les sujets traités sont : les réseaux, le stockage, le clustering, les bases de données et les serveurs d’application. Comme je le disais, difficile d‘être pointu quand chaque chapitre compte à peine 15 pages. Là encore, on ne va pas très loin, vous trouverez mieux sur Wikipedia.
La quatrième partie couvre 60 pages sur 4 chapitres et s’intéresse aux sujets suivants : les techniques de programmation (pas éblouissant et hors sujet), les tests de performances (en soi pas inintéressant, mais on a là qu’une introduction), la gestion de la production quelques bonnes idées à prendre concernant le monitoring), la gestion de projet (bien bateau).
Bref, un livre raté. Les auteurs se sont perdus dans des considérations complètement en dehors du sujet. C’est certainement ce qui arrive quand on se pique d’architecture IT alors que votre véritable centre d’intérêt est l’architecture et la conception logicielle.
Référence complète : Performance des Architectures IT : Disponibilité, temps de réponse, robustesse, montée en charge – Pascal Grojean, Médéric Morel & Guillaume Plouin – Dunod 2007 – ISBN : 978 2 10 051262 1 (une seconde édition est aujourd’hui disponible)
Note: 8 ; J’ai des scrupules à le juger excellent …
Franchement, rien que la première partie justifie l’achat du livre. En une centaine de pages, l’auteur parvient à faire le tour des aspects sur lesquels il faut opérer des choix d’architecture et les contraintes qui peuvent nous guider vers telle ou telle solution. Le tout est exposé clairement et simplement, avec limpidité devrai-je même dire, par comparaison aux autres ouvrages dédiés à l’architecture logicielle. Voilà qui devrait être une saine source d’inspiration pour les auteurs des pavés de 1000 pages !
L’auteur prend des positions nettes par rapport à ces choix, et c’est tant mieux. Cette première partie, par sa qualité et son narratif me rappelle “UML distilled” du même auteur.
En revanche c’est à “Refactoring” que me fait penser la seconde partie du livre, car Martin Fowler a utilisé ici la même présentation pour ses patterns. C’est plutôt une qualité, car j’avais déjà trouvé cette présentation claire et intéressante, même si elle tend à mettre beaucoup d’emphase sur le code (nous avons le droit à du Java – essentiellement – et aussi du C#) et parfois pas assez l’accent sur l’essence de la solution. Ces patterns (il y en a tout de même 51) sont regroupés en “thèmes” qui font le pendant aux chapitres de la première partie :
Organisation de la logique métier.
Architecture des sources de données
Mapping comportemental objet-relationnel
Mapping structural objet-relationnel
Mapping objet-relationnel des métadonnées
Présentation Web
Distribution des traitements
Gestion transactionnelle
Gestion des états
Patterns de base
Ce qui m’a certainement le plus troublé (et même choqué, devrais-je dire), c’est l’absence de référence aux autres ouvrages ! Et pourtant il devrait y en avoir. Pire : nombre de patterns présentés ici ne sont guère que des reprises de patterns déjà publiés. Les indécrottables de la galaxie Patterns (j’en fais partie) s’en offusqueront. C’est ce dernier point qui m’incite à ne pas attribuer un 10 à cet excellent livre. Il y a toutefois un aspect pratique : nous avons un livre complet et auto-suffisant de patterns applicatifs dans lesquels faire notre marché pour les applications d’entreprise. Et cet ouvrage est de haute qualité, cela mérite certainement quelques concession… Martin Fowler nous a plus ou moins suggéré qu’il pourrait y avoir un second volume: nous l’attendons toujours…
Référence complète :Patterns of Enterprise Application Architecture – Martin Fowler with David Rice, Matthew Foemmel, Edward Hieatt, Robert Mee and Randy Stafford – Addison Wesley / Signature series 2002 – ISBN: 0-321-12742-0
Quand mon produit est un système d’information (Scrum Day 2011)
Scrum évoque implicitement, dans les différentes descriptions qui en sont faites, la réalisation de systèmes fermés, qu’ils soient logiciels ou applications Web.
Lorsqu’il s’agit d’informatique interne, il s’agit le plus souvent, non plus de réaliser une application isolée, mais de faire grandir un système d’information constitué de plusieurs composants applicatifs collaborant ensemble.
Dans ce contexte, la dimension projet est généralement dissociée de la dimension produit (le système d’information). Comment gérer une telle dichotomie avec Scrum ?
Les différents projets d’informatique interne s’adossant et faisant croitre un même système d’information, comment gérer les interactions et les synergies entre ces projets ?
Est-il nécessaire de penser et faire des plans sur l’évolution de l’architecture du SI indépendamment du cadre imposé par chaque projet ? Si oui, est-il possible de faire cela tout en restant dans Scrum ?
C’est à ces différentes questions et bien d’autres encore que nous tentons de répondre ici.
Software Freethinker 
