Commentaires sur : USI 2009 Quelques idées issues des « grands » du web pour remettre en cause vos réflexes d’architectes

Par : Nicolas Martignole

Nicolas Martignole — Sat, 11 Jul 2009 15:56:03 +0000

@Damien : vas-y sers toi c’est open bar

Par : Damien

Damien — Sat, 11 Jul 2009 15:36:43 +0000

J’adore : « Il y a un monde entre l’univers des gens qui tartinent du Word et du PowerPoint avec une cravate et les autres, qui vont vraiment vous construire une architecture, mettre en place des outils, trouver une solution à l’arrache sans craquer, motiver et diriger une équipe. »

ça te dérange si je m’emprunte ta phrase magique l’envoyer à ma très estimée hiérarchie ?

Par : Nicolas Martignole

Nicolas Martignole — Wed, 08 Jul 2009 08:42:53 +0000

@Gabriel j’imagine le méga spoiler sur mon Scenic, tu commences à parler comme moi

Par : Gabriel

Gabriel — Tue, 07 Jul 2009 19:43:59 +0000

Sur EBay, il y a aussi cet article – http://www.infoq.com/articles/ebay-scalability-best-practices
qui m’avait assez sidéré à l’époque. Il avait remis en cause pas mal de choses, notamment, la gestion des transactions, des entrepots de données, des requetes, le compromis nécessaire entre différents aspects d’une archi, etc etc. Bien, bien!
Bel article, on est un peu comme des mecs qui lisent les spécifications des F1. Après on regarde sa Citroën Saxo et on se dit qu’on lui mettrait bien un petit spoiler…

Par : william

william — Tue, 07 Jul 2009 02:25:24 +0000

Interessant de voir qu’on en revient toujours aux fondamentaux des systèmes distribués.
Interessant de voir aussi que les plus grands du web ont des développeurs en nombre et en interne (pas d’outsourcing), qu’ils concoivent eux memes leur logiciels (voire leur hardware pour Google).
Enfin, si la présentation des architectures est linéaire et policée, elle masque néanmoins les nombreuses évolutions de l’architecture, des essais et des échecs, qu’ils ont du mettre en place, sans oublier les contraintes du legacy (et oui tout le monde en a).
Enfin, j’ai rien contre le site d’assurance suédois, mais, on ne compare pas un rafale à un planeur.

Par : oliv

oliv — Mon, 06 Jul 2009 16:51:06 +0000

SAlut Nico,

Merci pour le résumé : quelle prose.
y a effectivement quelques erreurs/inversion eBay/AMazon mais peu importe. sinon ce n’et pas 150 équipes mais 150 services

oliv’

Par : HollyDays

HollyDays — Mon, 06 Jul 2009 13:20:29 +0000

En fait, la leçon des grands acteurs, c’est que la mode ne fait pas une bonne architecture : il y a 15 ans, la mode, c’était « le client-serveur sinon rien », aujourd’hui, c’est « des EJB, Spring, Hibernate sur une base relationnelle sinon rien », …

Or une bonne architecture, c’est d’abord une architecture adaptée à ses besoins. Faire des EJB si on s’interdit de déployer l’applicatif sur plusieurs serveurs, c’est idiot. Passer son temps à créer des beans passe-plats pour faire transiter les données de couche en couche n’est pas forcément ce qu’il y a de plus adapté pour réduire la complexité (il y a d’autres moyens de mettre en œuvre des mécanismes d’abstraction). Se servir d’une base de données relationnelle comme un simple entrepôt pour consulter des données, c’est rarement approprié (et quand c’est pour écrire du log, c’est carrément inepte !).

Enfin, la grande leçon de ces grands acteurs, c’est que, malgré ce que leurs promoteurs prétendent, les solutions « à la mode » ne sont pas les plus scalables et les mieux à même de réduire la complexité du problème posé. Même si le syndrome Make-It-All-By-Yourself est un véritable danger, le métier d’architecte ne se réduit pas à celui d’intégrateur de technologies…

Par : Nicolas

Nicolas — Mon, 06 Jul 2009 09:29:07 +0000

« Amazon c’est 1500 développeurs, 30 architectes. Pas beaucoup pour 6 millions de ligne de code »

Hum, j’imagine qu’un des chiffres n’est pas correct. 4000 lignes de code à maintenir par développeur, c’est un ratio qui doit faire rêver toute l’industrie.

Par : Philippe

Philippe — Mon, 06 Jul 2009 09:21:28 +0000

Pas de problème, j’avais bien compris que c’était un exemple alors je l’ai aussi pris comme exemple

Je suis d’accord avec toi sur les principes et l’organisation. On voit bien qu’amazon a fait quelque chose de très décentralisé. Mais bon, ils peuvent recruter les meilleurs de la terre et les payer. Dans des boites normales, je crois que les gens seraient épuisés bien vite dans une telle organisation.

Sinon, ma remarque concernait plutot les aspects techniques : oui c’est attirant pour des « architectes » de faire des gros machins comme amazon (moi, par exemple, je trouverais çà absolument passionant de tout remettre en cause et repousser les limites). Mais combien de sites ont réellement leurs requirements ? Je pense qu’on peut les compter sur les doigts de la main au niveau mondial

Par : Cédric Vidal

Cédric Vidal — Mon, 06 Jul 2009 08:21:05 +0000

Salut Nicolas,

Merci pour ce résumé de l’USI. Je m’intéresse aux « grandes » architectures du web depuis un moment déjà et c’est vraiment bien d’en parler dans ton blog, ces principes architecturaux sont trop peu connus. Et je partage complètement ton avis, même si on n’utilise pas ces principes sur le premier projet qui vient, connaître ces principes donne un recul permettant de mieux concevoir les « petites » architectures

Par ailleurs, un article qui m’a particulièrement marqué tant il est bien écrit et met le doigts sur l’essence du fonctionnement de ces « grande » architecture est l’article de Dan Pritchett sur BASE.
http://queue.acm.org/detail.cfm?id=1394128

Dan Pritchett est un ancien membre du pôle d’architecture d’eBay. Je t’invite à lire cet article si tu ne l’a pas déjà fait, il est passionnant, ça a été une révélation pour moi. Il décris en détails les principes que tu évoques ici.

A très bientôt,

Cédric Vidal