Journal Microsoft IIS ne dépasse pas Apache et il est encore en train de se prendre une taule

Posté par (page perso) . Licence CC by-sa
17
17
déc.
2014

Cher Journal,

Je suis tombé un peu par hasard sur ce journal qui date de cet été et qui annonce avec une joie à peine contenue la fin d'Apache et la montée d'IIS au firmament des PDM de serveurs web :

J'ai particulièrement apprécié la conclusion du journal : "Une page se tourne donc, même si sur les sites dits actifs, Apache est encore largement devant."

MOUAHAHAHAHAHA !!!! hum… pardon…

Je suis allé faire un tour sur les dernières les stats Netcraft pour voir ou ça en est et j'ai le regret (ah ! ah !) d'annoncer qu'IIS est de nouveau en train de se casser la figure. Je crois que ça montre encore et toujours que MS ne réussi a booster les stats d'IIS que grâce à son chéquier et dès qu'il arrête les subventions, ses produits reviennent très vite a leur niveau habituel.

Et comme le disait fort justement notre troll Samuel Pajilewski préféré qui a laissé éclater son exaltation un peu vite : "sur les sites dits actifs, Apache est encore largement devant"

et c'est pas peu de le dire…

  • # Sérieusement....

    Posté par . Évalué à 3.

    Quelqu'un s'en soucie réellement ?

    • [^] # Re: Sérieusement....

      Posté par . Évalué à 10.

      Perso j'aime me dire que le libre est top1 dans quelque chose d'aussi important :)

      • [^] # Re: Sérieusement....

        Posté par (page perso) . Évalué à -5.

        Pour que cela soit pertinent, il faudrait s'assurer que le marché ciblé est le même. Sauf erreur de ma part, Microsoft cible majoritairement les entreprises pour les serveurs. Il serait donc pertinent de voir la part de marché sur ce secteur avant de dire qu'Apache poutre IIS.

        Sinon, avec le même raisonnement, Citroën poutre Ferrari ! La nuance c'est que le marche de Ferrari est un sous-ensemble du marché de l'auto, au même point que le marché visé par Microsoft avec IIS est un sous-ensemble du marché des serveurs web. Donc comparer sur le marché global n'a que peu de sens…

        • [^] # Re: Sérieusement....

          Posté par (page perso) . Évalué à 6.

          Le marché ciblé est le meme : les frontaux web publics.
          Ca sert a rien de pratiquer la drosophilie : c'est pas une question de fonctionnalités, de performances, de qualité ou que sais-je, c'est un pur concours de quequette et il faut le prendre comme ca…

          Et la morale de cette histoire est que d'un coté, MS use et abuse de ce genre d'outil sans aucune efficacité alors que le Libre n'en a pas besoin :

          Titre de l'image

          • [^] # Re: Sérieusement....

            Posté par (page perso) . Évalué à -9.

            Le marché ciblé est le meme : les frontaux web publics.

            Raté. Les frontaux web publics, c'est le marché global ;)

            Ca sert a rien de pratiquer la drosophilie : c'est pas une question de fonctionnalités, de performances, de qualité ou que sais-je, c'est un pur concours de quequette et il faut le prendre comme ca…

            Je vais plus loin dans mon raisonnement. Les outils de Microsoft ont une chose que les outils libres n'ont pas (ou que très rarement) : la stabilité des API. Et ça, pour les entreprises, c'est un GROS plus. Alors certes IIS est gratuit. Mais pour l'utiliser, il faut une licence Windows. Potentiellement, ces entreprises ont aussi un abonnement à la MSDN, des licences SQL Server, etc….

            Donc non, je persiste et signe : le marché ciblé n'est pas le même.

            • [^] # Re: Sérieusement....

              Posté par . Évalué à 10.

              Je pense que l'API d'Apache est plutôt exceptionnellement stable…

              • [^] # Re: Sérieusement....

                Posté par (page perso) . Évalué à -5.

                Tu n'as jamais eu à souffrir d'un problème lors d'une mise à jour d'apache donc. Chanceux va :)

                • [^] # Re: Sérieusement....

                  Posté par (page perso) . Évalué à 4.

                  C'est quoi le rapport entre une mise à jour et un problème…

                  Tu veux dire que tu es l'auteur d'un module apache et que t'as eu des problèmes de compilation lors d'une mise à niveau d'apache?

                  • [^] # Re: Sérieusement....

                    Posté par (page perso) . Évalué à -1.

                    Non.

                    A deux reprises, suite à une mise à jour d'apache, j'ai un site qui a cessé de fonctionner.
                    Pour le premier cas, le site entier était HS. J'ai eu à modifier le .htaccess pour que cela refonctionne.
                    Pour l'autre, c'était plus fourbe. Seules certaines requêtes ne passaient plus (certaines requêtes en Ajax) et c'était à cause du module de réécriture de requête dont le comportement avait été légèrement modifié.

                    • [^] # Re: Sérieusement....

                      Posté par (page perso) . Évalué à 10. Dernière modification le 17/12/14 à 23:45.

                      Sur une mise à jour de sécurité????

                      Ou tu vas me dire que tu fais des upgrades de serveurs sur des sites en prod sans passer par une phase de test???

                      • [^] # Re: Sérieusement....

                        Posté par (page perso) . Évalué à 1. Dernière modification le 17/12/14 à 23:50.

                        Non, pas sur une mise à jour de sécurité. Et c'était sur la version de test. Fort heureusement que je fais des tests avant :)

                        [edit]
                        Enfin, pour le premier cas. Le second était malheureusement passé à travers les mailles des tests…
                        [/edit]

                        • [^] # Re: Sérieusement....

                          Posté par (page perso) . Évalué à 9.

                          Parce que tu penses vraiment que les upgrades de version chez Microsoft et autres ça passe tout seul? Genre, on migre et hop là merci Microsoft tout fonctionne comme avant?

                          • [^] # Re: Sérieusement....

                            Posté par (page perso) . Évalué à 0.

                            sachant que je manie beaucoup plus de sites sous IIS que sous Apache (juste 2), et que j'ai eu bien plus de soucis avec Apache qu'avec IIS… je répond oui pour Microsoft. Pour autre… je sais pas, ça dépend de ce qui se cache derrière :p

                            PS : il ne faut pas croire, j'aime le libre (sinon, je ne serais pas ici xD), mais je sais aussi reconnaître les forces et les faiblesses des différentes solutions que j'utilise.

                            • [^] # Re: Sérieusement....

                              Posté par . Évalué à 9.

                              Et moi c’est l’inverse, je manie beaucoup plus de sites sous nginx que sous IIS (juste 1), et j’ai eu plus de problèmes sous IIS.

                              C’est normal d’avoir moins de problèmes avec le logiciel auquel tu es le plus familier…

                              • [^] # Re: Sérieusement....

                                Posté par (page perso) . Évalué à 1.

                                C’est normal d’avoir moins de problèmes avec le logiciel auquel tu es le plus familier…

                                Ca on est d'accord et je ne vais pas dire le contraire. Mais le sujet ici n'est pas la configuration du serveur (Apache ou IIS), mais de devoir modifier une configuration existante et précédemment fonctionnelle pour la réparer car une mise à jour dudit serveur l'a cassée.

                                • [^] # Re: Sérieusement....

                                  Posté par . Évalué à 3.

                                  Le truc avec les expériences c'est qu'on en a tous des différentes ;)

                                  Côté développement, avec le C# .NET que je pratique le plus souvent maintenant, j'ai eu une galère récemment avec une application web ciblant le framework 4.0 ne ne tournant pas bien sur une machine avec le 4.5. On a dû retoucher un peu de code. D'après MS, il devait pas y avoir de régressions et n'ont pas trop communiquer dessus :/
                                  Après dans l'ensemble, je trouve que cela passe plutôt bien pour le "code".

                                  Côté outillage, c'est parfois plus galère.

                                  J'ai en tête une migration SSIS 2005 sur du 2008 qui n'était pas de tout repos.

                                  Le couplage fort entre les versions des frameworks et visual studio est parfois problématique.
                                  Genre, je veux ouvrir un vieux projet de 2008 dans un visual studio de 2013 …

                                  Les postes de développements contiennent souvent un bel historique de versions ;)

                                  Tout ça pour dire que c'est pas tout rose non plus !

                    • [^] # Re: Sérieusement....

                      Posté par . Évalué à 2.

                      Ah ouais… Ben je dois avouer être un peu déçu par Apache, là.

            • [^] # Re: Sérieusement....

              Posté par (page perso) . Évalué à 10.

              Les outils de Microsoft ont une chose que les outils libres n'ont pas (ou que très rarement) : la stabilité des API.

              Mon trollomètre a explosé…

              • [^] # Re: Sérieusement....

                Posté par (page perso) . Évalué à -4.

                Ce n'est même pas un appel au troll. C'est un simple constat d'une réalité que certain libriste se refuse à voir.

                Pourquoi ces connes d'entreprises persistent avec des solutions payantes comme SQL Server alors qu'elles pourraient utiliser un produit équivalent tout aussi fiable comme Postgres ? Peut être qu'elles ont fait le test et ont eu une solution basée sur du postgres en version 7. Ca a marché pendant des années. Puis le serveur a crashé (défaillance du disque dur). Heureusement, il y avait des backups de la bd. Mais aie, le backup ne passait pas avec des version plus récente ! Et impossible d'installer simplement un postgres 7. Zut alors ! Résultat des courses : l'entreprise à du mettre au chomage technique une bonne partie de son personnel pendant 3 semaines (autant dire qu'elle a failli couler).

                Maintenant, je prends SQL Server. Un dump de SQL Server 2005 passe comme une lettre à la poste sur un SQL Server 2012.

                Laquelle de ces deux solutions a couté le plus cher ? Un indice : bizarrement, ce n'est pas celle à base de SQL Server.

                Là, je n'ai abordé que le problème d'un SGBD. Mais on rencontre ce genre de problème un peu partout. Une appli écrite en .Net2 continue de tourner aujourd'hui sans problème sur les versions plus récente du framework. Peut-on dire la même chose des applications écrite en Python ? en PHP ? en Ruby ? Il n'y a bien que le Java pour rattraper cela. Et là je n'aborde que l'aspect framework venant avec un langage.

                Alors oui, quand je regarde la "pérénité", je préfère mille fois conseiller des outils Microsoft à mes clients. Il y a un coût, mais qui est bien vite amorti sur le long terme.

                Maintenant, je ne dis pas qu'il n'y a que des avantages. mais on me demande un avantage, j'en cite un gros ;)

                • [^] # Re: Sérieusement....

                  Posté par (page perso) . Évalué à 1.

                  Ou mais tu essayes de faire des parallèles entre le monde des applications d'entreprises et le web public.
                  Ces 2 mondes n'ont absolument rien a voir en terme de besoins, de contraintes et d'enjeux si ce n'est qu'ils ont tous les 2 HTTP et qq autres technos en commun…

                  Sur le web, on se fout de la stabilité des API car on code et on transforme sans arret a une vitesse folle. On peut recoder la totalité d'un site d'une annee sur l'autre parfois… C'est la souplesse, le cout du ticket d'entrée et la "bidouillabilité" qui comptent le plus. Les besoins sont presque a l'opposé des entreprises pour leurs applis metier…

                  • [^] # Re: Sérieusement....

                    Posté par (page perso) . Évalué à 1.

                    Ou mais tu essayes de faire des parallèles entre le monde des applications d'entreprises et le web public.
                    Ces 2 mondes n'ont absolument rien a voir en terme de besoins, de contraintes et d'enjeux si ce n'est qu'ils ont tous les 2 HTTP et qq autres technos en commun…

                    Là où je ne suis pas d'accord avec toi, c'est pour dire que ce sont deux mondes disjoints. Je ne parle pas d'intranet d'entreprise (qui, par définition, n'est pas accessible de l'extérieur et ne fait donc pas partie du web public). Mais il existe un grand nombre d'entreprises avec un site internet, et ce site n'est pas forcément qu'une vitrine de communication. Cela peut être une banque, une boutique en ligne, le service des impôts ou que sais-je encore. Et pour de tels services, la pérénité est très importante.

                    Sur le web, on se fout de la stabilité des API car on code et on transforme sans arret a une vitesse folle. On peut recoder la totalité d'un site d'une annee sur l'autre parfois… C'est la souplesse, le cout du ticket d'entrée et la "bidouillabilité" qui comptent le plus. Les besoins sont presque a l'opposé des entreprises pour leurs applis metier…

                    Le geek dans son coin qui s'occupe de son blog, oui, il s'en fou. C'est son temps. Une entreprise non, car du temps, c'est de l'argent. Une fois que le site est développé, il ne s'amuse pas à le redévelopper l'année suivante, sauf vraiment si c'est nécessaire.

                    Et la stabilité des API est encore plus importante si un site fait appel à des services web.

                    • [^] # Re: Sérieusement....

                      Posté par (page perso) . Évalué à 4.

                      Une fois que le site est développé, il ne s'amuse pas à le redévelopper l'année suivante

                      Et du coup, ces entreprises vendent des produits merdiques, codé avec les pieds qui ne sont pas mis à jour et qui nécessite des modifs dans les navigateurs modernes pour fonctionner… C'est mieux?

                      https://www.eudonet.com/app/log.asp?l=0

                      • [^] # Re: Sérieusement....

                        Posté par (page perso) . Évalué à 0.

                        Et du coup, ces entreprises vendent des produits merdiques, codé avec les pieds qui ne sont pas mis à jour et qui nécessite des modifs dans les navigateurs modernes pour fonctionner… C'est mieux?

                        Si le site a été bien codé, ne nécessite pas d'adaptation particulière de la part des navigateurs modernes pour fonctionner… on le refait pour le fun ?

                        Si le site a été mal codé, ce n'est pas un problème de techno changeante, mais un problème de prestataire.

                        • [^] # Re: Sérieusement....

                          Posté par (page perso) . Évalué à 3.

                          Oui, enfin en 2000, beaucoup de monde codait comme cela ;)

                        • [^] # Re: Sérieusement....

                          Posté par (page perso) . Évalué à 1.

                          C'est évident pour toi, héros qui sait faire du code pur dont tu sais qu'il fonctionnera dans 10 ans partout sur tous les navigateurs.

                          Et bien sûr, tu auras payés la vraie valeur d'un bon développeur web qui pense à 10 ans plus tard plutôt que d'avoir choisi le devis le moins cher.

                          • [^] # Re: Sérieusement....

                            Posté par (page perso) . Évalué à 1.

                            C'est évident pour toi, héros qui sait faire du code pur dont tu sais qu'il fonctionnera dans 10 ans partout sur tous les navigateurs.

                            Savoir coder proprement fait de moi un héros ? Zut, j'ai pas de costume… Je ne sais pas si mon code fonctionnera dans 10 ans. Ce que je sais, c'est que dans 1, 2 voir 3 ans, il fonctionnera encore.

                            Et bien sûr, tu auras payés la vraie valeur d'un bon développeur web qui pense à 10 ans plus tard plutôt que d'avoir choisi le devis le moins cher.

                            C'est toujours le même problème : est-ce qu'on cible le court ou long terme ? (je considère que 3 ans dans l'informatique, c'est du long terme). Le devis le moins cher sur le court terme n'est pas forcément le devis le moins cher sur le long terme. Je pense que tu connais assez le milieu Zenitram pour savoir cela ;)

                            • [^] # Re: Sérieusement....

                              Posté par . Évalué à 7.

                              Ce que je sais, c'est que dans 1, 2 voir 3 ans, il fonctionnera encore.

                              On s'en fou.

                              Le web c'est devenu du speed dating, 45 secondes avec un framework avant de toute jeter et tout réécrire avec le nouveau truc hype du moment. Et tout ça pour avoir 1/100 des fonctionnalités de Word ou n'importe quelle appli avec des machines plus de 100 000x plus puissantes.

                              “What we need is less hipsters and more geeks” - Martin Thompson

                              • [^] # Re: Sérieusement....

                                Posté par (page perso) . Évalué à 1.

                                On s'en fou.

                                TU t'en fous. Mes clients, qui paient, eux non. Ne fais pas d'un cas particulier une généralité.

                                • [^] # Re: Sérieusement....

                                  Posté par . Évalué à 2.

                                  Mes clients prennent le moins cher et mes patrons cherchent le plus de marge possible. Résultat, je ne suis pas toujours fier de mon travail. Enfin, il m'arrive d'être fier du résultat quand je prends en compte mes compétences au début du projet, mais j'ai quand même honte du produit livré.

                • [^] # Re: Sérieusement....

                  Posté par . Évalué à 7.

                  Ca a marché pendant des années. Puis le serveur a crashé (défaillance du disque dur). Heureusement, il y avait des backups de la bd. Mais aie, le backup ne passait pas avec des version plus récente ! Et impossible d'installer simplement un postgres 7. Zut alors ! Résultat des courses : l'entreprise à du mettre au chomage technique une bonne partie de son personnel pendant 3 semaines (autant dire qu'elle a failli couler).

                  Qu'est qui empêche de réinstaller le même os et le même postgres qu'auparavant d'autant que c'est juste le disque qui a crashé ?

                  • [^] # Re: Sérieusement....

                    Posté par (page perso) . Évalué à 1.

                    L'hébergeur de l'entreprise ne proposait plus la distribution en question (ou plutôt, la version de la distribution).

                    Et sur les versions plus récente, la même version de postgres ne démarrait pas (crash).

                    • [^] # Re: Sérieusement....

                      Posté par . Évalué à 8.

                      Dans ce cas c'est clairement le choix de l'hébergeur qui est mauvais pas celui d'une api stable.

                      • [^] # Re: Sérieusement....

                        Posté par (page perso) . Évalué à 2.

                        Ou pas. C'est la faute de l'entreprise si elle n'a pas pris la formule adaptée. L'entreprise gérait initialement le serveur en son sein. Elle a ensuite externalisée la gérance de son serveur. Elle a trouvé un hébergeur qui acceptait de prendre le serveur dans ses locaux. L'entreprise a demandé qu'un backup de la bd soit effectué quotidiennement, pas du système (pour des raisons de coûts).

                        Le serveur n'étant pas la propriété de l'hébergeur, il n'avait pas d'obligation en cas de défaillance matérielle.

                        Contractuellement, l'hébergeur n'avait rien à se reprocher.

                        • [^] # Re: Sérieusement....

                          Posté par . Évalué à 2.

                          L'entreprise a demandé qu'un backup de la bd soit effectué quotidiennement, pas du système (pour des raisons de coûts).

                          C'est ballot.

                    • [^] # Re: Sérieusement....

                      Posté par (page perso) . Évalué à 10.

                      Et genre y'a tout de dispo chez postgresql pour convertir les backups de la majorité des base de données existantes sur terre mais les mecs, ils avaient rien prévu pour leur changement de version, tu te fous pas un peu de nous? :p

                      • [^] # Re: Sérieusement....

                        Posté par (page perso) . Évalué à 1.

                        Et genre y'a tout de dispo chez postgresql pour convertir les backups de la majorité des base de données existantes sur terre mais les mecs, ils avaient rien prévu pour leur changement de version, tu te fous pas un peu de nous? :p

                        Non. Déjà, ce n'est pas les backups qui peuvent être importés, mais le schéma et les données. Tu laisses sur le carreau les procédures stockées, les fonctions, les triggers, les requêtes, etc… Bref, c'est pas vraiment ce que j'appelle une conversion….

                        Et cela sous-entend aussi que ces outils sont exempts de bugs. En l'occurence, la restauration du backup plantait. Dump corrompu si ma mémoire est bonne. Pourtant, le dump corrompu est très bien passé avec la même version de Postgres quand ils ont enfin réussis à en réinstaller un…

                • [^] # Re: Sérieusement....

                  Posté par (page perso) . Évalué à 4.

                  Une appli écrite en .Net2 continue de tourner aujourd'hui sans problème sur les versions
                  plus récente du framework.

                  Désolé de t'informer que tu ne vis pas dans le monde réel, des applications qui ont besoin d'une version antérieur de .NET pour tourner sous Windows, cela arrive trop souvent.

                  • [^] # Re: Sérieusement....

                    Posté par (page perso) . Évalué à 1.

                    Désolé de t'informer que tu ne vis pas dans le monde réel, des applications qui ont besoin d'une version antérieur de .NET pour tourner sous Windows, cela arrive trop souvent.

                    La seule exception que je connaisse était avec la première version de .Net. Pour le reste, que ce soit moi ou mes collègues, nous n'avons jamais rencontré de problèmes lors d'un passage à une version ultérieure du framework .Net. Et quand on a migré nos 27 applications d'un serveur Microsoft Server 2005 et 2008 vers notre nouveau serveur sous 2012, nous n'avons rencontré absolument aucun problème (et pourtant, on a tout migré, le code des applis et les bases de données).

                    Certaines de ces applications n'avaient pas été retouchée depuis des années.

                    Donc non, je vis bien dans le monde réel.

                    • [^] # Re: Sérieusement....

                      Posté par (page perso) . Évalué à 3.

                      Et ben moi j'installe des logiciels qui ne tournent que si il trouvent leur version pas à jour de .NET sinon ça plante… La raison, vielle comme le monde, comme quand toi même tu dis que le module rewrite de apache a cassé ton site… Un changement de comportement dans un soft suffit à faire planter un autre logiciel.

                      Après, je dois avouer que le roi des rois dans la matières, c'est Java, j'ai jamais vraiment su si le problème vient du framework ou des développeurs qui l'utilisent…

                      • [^] # Re: Sérieusement....

                        Posté par (page perso) . Évalué à 0.

                        Un changement de comportement dans un soft suffit à faire planter un autre logiciel.

                        J'ai envie de dire que tu n'as vraiment pas de chance. Car les changements de comportement reste relativement rare au sein des API développé par Microsoft (que ce soit Win32, .Net ou autre). Ils vont même jusqu'à garder des bugs pour ne pas modifier le comportement de programmes existant ! C'est d'ailleurs une des raisons qui fait qu'un projet comme Wine à quelques difficultés parfois à établir un comportement identique ;)

                      • [^] # Re: Sérieusement....

                        Posté par . Évalué à 2.

                        Et ben moi j'installe des logiciels qui ne tournent que si il trouvent leur version pas à jour de .NET sinon ça plante…

                        Jamais rencontré ce problème.

                        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

            • [^] # Re: Sérieusement....

              Posté par (page perso) . Évalué à 6.

              Nan mais en fait, on parle pas de la meme chose…

              Dans le terme "marché ciblé", moi je parle du marché ciblé par Netcraft pour faire ses stats alors que toi tu fais des conjectures sur le marché visé par MS pour IIS.
              Sauf que quand MS file un cheque a GoDaddy pour qu'il passe ses pages parking sous IIS, c'est bien qu'il cherche a marcher sur les plates-bandes d'Apache. Alors, oui, c'est evident que IIS est utilisé majoritairement par les entreprises en interne mais la strategie de MS a son sujet semble etre beaucoup plus floue que ca…
              Et je dis bien "floue" parce que je comprends pas pourquoi MS s'obstine a essayer de se faire remarquer sur un marché qui, de toute facon, ne lui rapporte rien, n'a rien à faire de lui et se fout royalement de ses produits…

              • [^] # Re: Sérieusement....

                Posté par (page perso) . Évalué à -2.

                Dans le terme "marché ciblé", moi je parle du marché ciblé par Netcraft pour faire ses stats alors que toi tu fais des conjectures sur le marché visé par MS pour IIS.

                Effectivement, on ne parlait pas de la même chose. D'où le quiproquo :) Et appelle cela conjecture si tu veux, mais avec un brin de réflexion il est facile d'arriver à cette conclusion.

            • [^] # Re: Sérieusement....

              Posté par . Évalué à 6.

              Le libre (enfin, à condition de sortir Tomcat et Mono du libre, ce qui est déjà pas mal douteux, mais enfin…) n’a peut-être pas d’API stable, il a mieux : des protocoles (FastCGI/WSGI principalement).

              Histoire vraie : une entreprise A a développé un soft avec Tomcat. Une entreprise B a développé un soft avec ASP.net. Les deux se rendent comptent de la complémentarité de leurs solutions et aimeraient bien distribuer les deux avec un seul serveur. Sauf que… IIS est incapable de servir du Java, et Tomcat est incapable de servir de l’ASP.net.

              Alors moi j’ai peut-être pas « d’API stable », mais mon serveur nginx, il est capable de servir en même temps une application PHP, une application Ruby et une application Python (et quelques scripts Perl en CGI).

              • [^] # Re: Sérieusement....

                Posté par (page perso) . Évalué à 0.

                Le libre (enfin, à condition de sortir Tomcat et Mono du libre, ce qui est déjà pas mal douteux, mais enfin…)

                Déjà, pourquoi ?

                il a mieux : des protocoles (FastCGI/WSGI principalement).

                Qui ne sont pas réservés au libre et supporté par IIS.

                Histoire vraie : une entreprise A a développé un soft avec Tomcat. Une entreprise B a développé un soft avec ASP.net. Les deux se rendent comptent de la complémentarité de leurs solutions et aimeraient bien distribuer les deux avec un seul serveur. Sauf que… IIS est incapable de servir du Java, et Tomcat est incapable de servir de l’ASP.net.

                Sur cet aspect, un mauvais point pour tomcat. Il est possible de lancer des .war avec IIS ;)

                Alors moi j’ai peut-être pas « d’API stable », mais mon serveur nginx, il est capable de servir en même temps une application PHP, une application Ruby et une application Python (et quelques scripts Perl en CGI).

                IIS fait de même. Pour tomcat, je ne sais pas.

                • [^] # Re: Sérieusement....

                  Posté par . Évalué à 3.

                  Déjà, pourquoi ?

                  Pourquoi quoi ?

                  Pourquoi « à condition de sortir » ? Parce que Mono et Tomcat ont des API stables.

                  Pourquoi « douteux de les sortir » ? Parce qu’ils sont libres.

                  Il est possible de lancer des .war avec IIS ;)

                  Mon contact dans l’entreprise A me dit l’inverse, ainsi que http://stackoverflow.com/questions/9391826/deploy-war-file-in-microsoft-iis-7

                  • [^] # Re: Sérieusement....

                    Posté par (page perso) . Évalué à 0.

                    Pourquoi quoi ?
                    Pourquoi « à condition de sortir » ? Parce que Mono et Tomcat ont des API stables.
                    Pourquoi « douteux de les sortir » ? Parce qu’ils sont libres.

                    Putain je suis fatigué, je ne l'avais pas compris comme ça :p Maintenant, félicitation, tu m'as montré des exemples avec des API stables. Quoi qu'on pourrait chipoter pour Mono dans la mesure où il s'agit principalement d'une implémentation d'une API déjà défini et que le projet vise justement la compatibilité avec l'API initiale ;)

                    Mais tu veux que je te sorte des projets où l'API n'est pas stable ?
                    - le noyau linux
                    - ffmpeg
                    - libxml2
                    - qt
                    - gtk

                    Mon contact dans l’entreprise A me dit l’inverse, ainsi que http://stackoverflow.com/questions/9391826/deploy-war-file-in-microsoft-iis-7

                    Ton contact de l'entreprise A devrait mieux se renseigner :
                    http://www.helicontech.com/articles/deploying-java-servlet-applications-on-windows-with-iis/

                    (ok, derrière, ça utilise je ne sais plus qu'elle conteneur et ça configure IIS en tant que proxy, mais c'est totalement transparent).

            • [^] # Re: Sérieusement....

              Posté par . Évalué à -1.

              Ń'importe quoi, le marché est exactement le même. Quoi que tu invente :)

    • [^] # Re: Sérieusement....

      Posté par (page perso) . Évalué à 3.

      Ben, comme toutes les stats de ce genre, ca veut pas dire grand chose en soi mais c'est un outil de promotion donc autant l'utiliser comme tel. MS, pour le coup, ne s'en prive pas…

      Et puis, l'exemple d'Apache est un argument pour débuncker un paquets de trolls. Rien que le fameux "si linux n'a pas de virus, c'est parce que ses PDM sont tres faibles" se fait facilement defoncer en donnant l'exemple des virus IIS (comme CodeRed) alors qu'il représente que dalle en terme de PDM face à Apache qui n'a jamais connu ce genre de problème (des attaques, oui, des exploits, évidemment, mais jamais de virus).

  • # Nginx

    Posté par (page perso) . Évalué à 8.

    J'en profite pour voir (sur le "top million busiest sites", les autres sont bien moins interessants) que Nginx monte, monte…

    Qu'est-ce qui fait qu'Apache se fait lacher par bon nombre de sites pour y mettre Nginx?
    J'ai entendu parler de perfs, mais est-ce tout? Apache n'a pas de fonctionnalité trop utile et n'a plus la motivation à évoluer plus vite que les autres et du coup un autre vient le remplacer dans le coeur des développeurs?
    De loin du peu que j'ai lu, Apache me fait penser à Firefox (oui, la, c'est un énorme troll que j'essaye de lancer)

    • [^] # Re: Nginx

      Posté par (page perso) . Évalué à 5.

      Netcraft fait des stats sur les frontaux et Nginx est un excellent frontal… Ca veut pas dire qu'Apache est moins utilisé, ca veut juste dire qu'Apache est de moins en moins exposé en front.

      Et puis globalement, quand on veut faire de la perf avec php, une des 1eres choses qu'on installe est PHP-FPM. Et a partir du moment ou on utilise PHP-FPM, ben on peut facilement utiliser Nginx plutot qu'Apache.
      Apache est vachement bien car il fait papa-maman avec tous ses plugins mais la facon de faire du web se transforme beaucoup en ce moment et on recherche plus des solutions legeres et simples capables de scaler sur des centaines de petits serveurs plutot que des gros engins a tout faire qui reclament de grosses machines pour bien tourner. C'est un peu le succes de AWS et des Clouds en general qui veulent ca car les petites VM sont pas cheres sur ces plateformes mais les grosses coutent un bras.
      Et puis on voit apparaitre pas mal de trucs alternatifs comme Rails ou Node.js qui changent la donne aussi.

      Bref, Apache n'est pas mort, loin de la, il est juste un peu vieillot et pas assez bien adapté aux nouveaux besoins. Mais faut pas rever, IIS est encore moins adapté… D'ailleurs, je ne sais pas si ce truc a jamais ete adapté a quoique ce soit sans le forcing de MS pour le pousser avec .Net, Sharepoint, Exchange et tous ses produits.

      • [^] # Re: Nginx

        Posté par . Évalué à 0.

        Euh, on peut utiliser facilement apache pour faire du php-fpm…

        • [^] # Re: Nginx

          Posté par (page perso) . Évalué à 1.

          Oui mais quand t'as un nginx qui fait pareil en mieux, pourquoi utiliser Apache ?

          Le gros interet d'apache est surtout sa facilité d'installation avec le plugin php. Mais quand tu te passes du plugin php et que tu utilises une autre solution alors apache n'a pratiquement plus d'interet sauf dans des cas tres specifiques. Je parle bien sur dans le cas general…

          • [^] # Re: Nginx

            Posté par . Évalué à 1.

            Probablement que je ne connais pas assez Nginx mais je ne vois pas trop les limitation d'apache en php-fpm. Si quelqu'un peut m'éclairer :)

            • [^] # Re: Nginx

              Posté par . Évalué à 4.

              Je ne sais pas mais pour moi qui n'est jamais vraiment utilisé Apache la question est simple :

              • nginx fait très bien le boulot avec php-fpm
              • il est plus léger
              • il est assez facile à configuré (pas pire que ça en tout cas, je ne compare pas à Apache)
              • sa conf en json est plus agréable à écrire que le xml d'apache

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Nginx

                Posté par . Évalué à 5.

                sa conf en json est plus agréable à écrire que le xml d'apache

                La configuration d'apache n'est pas en XML.

              • [^] # Re: Nginx

                Posté par . Évalué à 1.

                Perso, c'est la facilité de lecture de la conf qui m'a fait passé de Apache à Nginx sur mes sites.
                Sinon, la légèreté : au vu de mon serveur qui sert des sites pour moi (et ma famille), c'est kifkif avec apache je pense

            • [^] # Re: Nginx

              Posté par (page perso) . Évalué à 1.

              À ma connaissance la version Debian stable d'Apache est incapable de taper sur un PHP-FPM, à moins de sortir les paquets «non-free». En effet «mod-fastcgi» le gère, mais pas «mod-fcgi».

              En «vraiment libre et maintenu», la solution serait du coté du «mod-proxy-fcgi», à partir d'Apache 2.4, et qu'on retrouvera par exemple dans la prochaine Debian.

              Bref, Debian Wheezy (main) + Apache + démon fastCGI externe c'est actuellement compliqué. Maintenant est-ce la faute d'Apache ou de Debian ? :D

              alf.life

        • [^] # Re: Nginx

          Posté par . Évalué à 2.

          Euh, on peut utiliser facilement apache pour faire du php-fpm…

          Oui, on peut.

  • # Le bon mot du jour

    Posté par (page perso) . Évalué à 10.

    "Une page se tourne donc, même si sur les sites dits actifs, Apache est encore largement devant."

    Comme quoi, il faut savoir tourner l'Apache.

  • # Ce n'est pas la première fois.

    Posté par . Évalué à 1.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.