La première hypothèse est que IIS 6.0 est un bon produit. En mode isolation complète on peut changer la configuration d'un site web ou d'un ensemble de sites webs sans impacter quoi que ce soit à coté. De plus les meccanismes ISAPI, OLE et DCOM permettent facilement de le lier à une interface d'intégration customisée, ie il est beaucoup plus facile de faire dialoguer un programme lourd spécifique avec IIS/ASP.net qu'avec Apache/perl ou Apache/PHP. Donc une maintenance et une integration beaucoup plus aisée sous IIS... A titre d'exemple mettre sur le même serveur IIS deux configuration ASP avec des paramètres totalement différents pour des raisons de sécurité qui appellent la même base de données avec d'un coté des appels extrèmement intensifs pour une mise à jour immédiate des données et de l'autre une gestion de cache optimisée pour minimiser les accès base est assez délicat sous Apache/PHP, rien que de gérer des php.ini différents en fonction des sites est problématique, et pour la gestion des accès il va probablement falloir se farcir une gestion du cache à la main (ce qui est toujours une très mauvaise idée, tant la question est délicate). Sous IIS ca se fait facilement. On met un processus middle tier par site et on règle les paramétrages OleDB par site et basta.
La seconde hypothèse est que PHP/Perl ont complètement loupé le coche. je ne veux pas tomber dans le troll sur langage PHP, mais ilf aut bien admettre que malgré les gros efforts du zend optimizer et les améliorations dans la série 5, le PHP a pris une génération de retard au niveau de la faclité de dev et de la productivité. Ruby (on rail ou pas), Python et (mon favori personnel) Erlang ne sont pas encore au niveau pour assurer la relève. Résultat on a rien de comparable à la plateforme .Net sous Linux. J2EE étant un poil trop complexe pour pouvoir être utilisé "partout". Et pourtant .Net est une très mauvaise plateforme (gestion mémoire catastrophique, système de cache à la con, threads à configurer un par un pour éviter les catastrophes en j'en passe).
Dernière hypothèse, et c'est à mon sens une grave lacune du monde libre aujourd'hui : on a pas de cubes et surtout pas de plateformes pour les exploiter. Vu l'espace disque dont on dispose aujourd'hui, pourquoi créer une base de données quand on peut faire un cube ? Si celui-ci est bien créé on se facilite la tache de façon monstrueuse pour tout ce qui est reporting. Plus besoin de faire venir un dev qui touche bien se bille en SQL si il faut consolider les données de l'années. Et au niveau simulation c'est le jour et la nuit par rapport aux BDD classiques. Seulement interroger un cube OLAP ou même en Star-Schema en ligne de commande bonjour. Il faut donc un SDK complet avec un générateur de requètes optimisé et un système d'audit de perf capable de remonter quelles hiérarchies simplifieraient/accelerreraient le travail. A ce niveau là en solution sous Linux (propriétaires ou libres) on est au point mort. Et pas de bras, pas de chocolat...
Sinon il y a aussi un phénomène boule de neige. Avec un Active Directory, Exchange (autre très mauvais produit, même en version 2005) et IIS il y a moyen assez simplement de créer un groupware complet extranet. Si on ajoute reporting services (obligatoire avec Exchange 2005) on a un outil de gestion de documents et de suivi assez complet. Donc on fait rentrer des compétences IIS pour tirer parti à fond des licences qui ont déjà été achetées, et un fois que les compétences IIS sont là...
# Plusieurs hypothèses
Posté par Jerome Herman . En réponse au journal apache perd du terrain face à IIS de manière inquiétante. Évalué à 10.
La seconde hypothèse est que PHP/Perl ont complètement loupé le coche. je ne veux pas tomber dans le troll sur langage PHP, mais ilf aut bien admettre que malgré les gros efforts du zend optimizer et les améliorations dans la série 5, le PHP a pris une génération de retard au niveau de la faclité de dev et de la productivité. Ruby (on rail ou pas), Python et (mon favori personnel) Erlang ne sont pas encore au niveau pour assurer la relève. Résultat on a rien de comparable à la plateforme .Net sous Linux. J2EE étant un poil trop complexe pour pouvoir être utilisé "partout". Et pourtant .Net est une très mauvaise plateforme (gestion mémoire catastrophique, système de cache à la con, threads à configurer un par un pour éviter les catastrophes en j'en passe).
Dernière hypothèse, et c'est à mon sens une grave lacune du monde libre aujourd'hui : on a pas de cubes et surtout pas de plateformes pour les exploiter. Vu l'espace disque dont on dispose aujourd'hui, pourquoi créer une base de données quand on peut faire un cube ? Si celui-ci est bien créé on se facilite la tache de façon monstrueuse pour tout ce qui est reporting. Plus besoin de faire venir un dev qui touche bien se bille en SQL si il faut consolider les données de l'années. Et au niveau simulation c'est le jour et la nuit par rapport aux BDD classiques. Seulement interroger un cube OLAP ou même en Star-Schema en ligne de commande bonjour. Il faut donc un SDK complet avec un générateur de requètes optimisé et un système d'audit de perf capable de remonter quelles hiérarchies simplifieraient/accelerreraient le travail. A ce niveau là en solution sous Linux (propriétaires ou libres) on est au point mort. Et pas de bras, pas de chocolat...
Sinon il y a aussi un phénomène boule de neige. Avec un Active Directory, Exchange (autre très mauvais produit, même en version 2005) et IIS il y a moyen assez simplement de créer un groupware complet extranet. Si on ajoute reporting services (obligatoire avec Exchange 2005) on a un outil de gestion de documents et de suivi assez complet. Donc on fait rentrer des compétences IIS pour tirer parti à fond des licences qui ont déjà été achetées, et un fois que les compétences IIS sont là...