Grâce au site d’aurelien j’ai pu découvrir ce lien dont la lecture devrait être obligatoire pour les DSI et architectes.
Ce document décrit comment Linux est developpé. Vous y découvrirez :
- les développeurs sont organisés et que ce n’est pas l’anarchie
- qu’ils se passent de beaucoup d’outils, les modifications de codes sont transférés par mails aux personnes qui maintiennent le module modifié.
- “Publier tôt, publier souvent et écouter vos clients” , et oui Linux ne publie pas une version tous les 5 ans … il s’adapte plus vite aux besoins. Vista de son coté a perdu des années pour gérer les DRM et quand il arrive les sociétées commence a les retirer…
- le système est très modulaire
j’aimerais trouver de la documentation sur ce dernier point.
Un journaliste du monde informatique reprend un billet d’un blog d’IBM au titre intéressant ‘SOAP-based Web services are dead‘ ! Le blog est ici et pose plus la question que d’essayer d’y répondre.
Se poser la question c’est être sur la bonne voie car toutes les normes au dessus de SOAP n’apportent pas grand chose (déjà toutes les piles de bases n’apportient rien wsdl, ws-security, soap … tout est faisable avec http, x.509, schema xml…). Sur certaines couches comme bpel ca se discute.
C’est plutôt bien que les journalistes se posent quelques questions sur l’utilisé de toutes ces couches.
je note en pratique y compris chez ceux qui ne connaissent pas REST, qu’en pratique beaucoup de gens font du http/xml car c’est plus simple. Je ne rencontre SOAP & co que dans le cas d’applications intégrées (IHM, Services dans un même serveur d’application ce qui pose peu de problèmes car l’éditeur est cohérent avec lui même). Ceux qui font communiquer des applications différentes utilisent plus facilement (exclusivement ?) http/xml en dehors de tout coté partisan (REST vs SOAP), juste le pragmatisme.
Ca n’est qu’une première étape de faire du http/xml car REST c’est bien plus – on sous estime les URI – mais il faut bien commencer par quelque chose.
un petit article interessant pour revenir sur l’echec de Corba.
During CORBA’s growth phase in the mid- and late ’90s, major changes affected the computing landscape, most notably, the advent of Java and the Web. CORBA provided a Java language mapping, but it did nothing to cooperate with the rapidly exploding Web. Instead of waiting for CORBA to deliver a solution, companies turned to other technologies and started building their e-commerce infrastructures based on Web browsers, HTTP, Java, and EJB (Enterprise JavaBeans).
Given that only a few years ago, CORBA was considered the cutting edge of middleware that promised to revolutionize e-commerce, it is surprising to see how quickly the technology was marginalized, and it is instructive to examine some of the deeper reasons for the decline.
Quelques commentaires :
- le marketing ne gagne pas sur le long terme
- la complexité échoue toujours
- ne pas oublier que les webservices sont les enfants turbulents de Corba … et en encore plus compliqué, un bel avenir donc.
- les technologies qui marchent sont celles ou le cout d’entrée est très faible (voir gratuit …). car se sont les technologies qui sont suceptibles d’être massivements utilisés.
un article du monde informatique indique que selon Illuminata une mainframe serait moins cher que 300 PC sous Linux.
L’article se montre septique, il explique que l’étude serait basée sur les chiffres d’IBM. Comment pourrait-on douter de l’impartialité de l’étude ?
La deuxième faiblesse affichée est qu’ils disent IBM qu’a l’avenir se sera mieux car IBM va inclure des fonctions d’automatisation d’administration qui existent déjà en distribué. Ca veut dire qu’ajourd’hui de nombreuses taches sont automatiques sur distribuées et manuelles sur mainframe mais que celui-ci reste moins cher ? c’est déjà louche.
Autre remarque, un mainframe est comparé a 300 PC sous Linux soit une puissance très importante de traitement et/ou stockage !
Il serait interessant de faire des comparatifs sur des architectures equivalentes, par exemple une application java pour 1000 utilisateurs et avec des performances equivalentes …
il faut voir également comment evoluent les couts, que se passe t-il lorsque l’on passe a 2000 utilisateurs ? il y a des effets de seuils sur les gros serveurs qui peuvent couter très cher, soit parce que l’on achète un très gros serveur dés le départ (financièrement ce n’est pas une bonne idée, voir les couts d’actualisation …) soit on utilise un serveur plus petit et dés qu’il n’est plus assez puissant il faut changer le serveur ! Ces problèmes n’existent normalement pas dans des applications Web prévues pour tourner sur des PC, il est possible de faire tourner des PC d’il y a 5 ans a coté de serveurs achetés hier. on ajoute comme google au fur et a mesure des serveurs.
Le pire avec ces études c’est qu’elles sont reprises partout sans trop de commentaires et beaucoup ne vont lire que les titres. A force les gens vont finir par croire que c’est vrai !
Une nouvelle qui passe inapercue pour le moment, la Xbox va gérer le protocole IPTV pour permettre d’obtenir directement le flux d’image d’une chaine.
pourquoi en parler dans ce blog ?
parce qu’il va arriver a la télévision la même chose que pour internet.
Au départ vous prennez les journaux papiers qui étaient des références et aggrégaient pour vous les milliers d’informations. Maintenant le poste client va chercher lui même aux sources qui l’interessent et se passe des intermédiaires sans valeur ajoutée.
La télévision est encore dans un ancien modèle, de nombreuses chaines et des fournisseurs de bouquets (TPS, TDF …). Demain vous irez directement vous brancher sur les flux ip des chaines qui vous interessent sans passer par ces intermédiaires.
Les particuliers sont gagnants car ils peuvent choisir les chaines qu’ils veulent (et ne sont pas forcés de se limiter a celles prévues par un bouquet), ils peuvent recevoir plusieurs chaines en même temps (seule la bande passante limite).
Le seul problème sera pour les providers et opérateurs telecom : gérer la bande passante correctement pour que les flux arrivent sans trop d’interuptions.
Dans un deuxième temps, le nombre de chaine pourra exploser, c’est techniquement facile pour un particulier de fournir un flux IP, seule la bande passante limite (les offres de fibres arrivent …). Il faut des serveurs mais Microsoft prépare une version d’un serveur pour l’informatique domestique.
Des chaines thématiques seront offertes, ces chaines etant des aggrégations des producteurs. Rien n’interdira de faire une chaine par exemple documentaire qui sera une aggrégation de contenu venant de la BBC, de films achetés … leur interet etant de selectioner les emissions sur un thème. La différence avec aujourd’hui est que se sera simple a faire, il y aura donc des centaines, des milliers peut-être de chaînes thématiques nouvelles.
Des outils permettant au grand public de faire ses propres chaines vont arriver sur le marché. Sur les blogs de msn il est déjà possible d’écouter les ‘playlist’ des internautes qui remplissent leurs musiques préférées sur myspace. Rien n’empeche d’appliquer la même chose à la vidéo.
Si je devais faire une prediction pour l’année qui vient, c’est un echec des HD-DVD et bluray et une percée des flux vidéos IPTV (ou un autre protocole) ou par téléchargement de fichiers plus ou moins legaux (pour les fichiers illégaux je ne prends pas de risques, c’est déjà le cas).
l’architecture gagnante est bien l’utilisateur au centre qui va utiliser les différents services qu’il souhaite et non un seul serveur qui aggrège. Cela est arrivé pour l’information, cela arrivera pour la video.
Bonne année à tous,
et pour bien débuter un article qui remet en cause les architectures n tiers.
C’est un document d’architecture de Microsoft independant de toute technologie Microsoft.
Il faut pour leurs prochains articles remettre également en cause :
- firewalls every where (j’en ai déjà trouvé qui voulaient nous mettre des firewalls entre les serveurs d’applications et les bases de données)
- SGBD comme seul et unique moyen de stockage …
