Cela ne correspond pas vraiment à du mutualisé : ce sont des machines virtuelles infogérées avec pas mal de service. En gros si vous développez l'équivalent d'un Facebook, ils ont les compétences pour l'héberger et même vous conseiller pour le code...

Sinon une petite machine virtuelle ou un serveur dédié bas de gamme peut suffire pour des coûts largement moindre (à partir de 20€/mois environ). Par contre il faut faire la gestion du système.

Effectivement EngineYard n'est pas vraiment ce que je recherche.
Et une petite machine virtuelle ou un serveur dédié bas de gamme, je prefere éviter car lorsuqe le serveur tombre, les ennuis commencent.
Donc mes questions restent valables.
- Hebergement mutualisé.
- RoR est il la bonne solution pour mes clients.

Merci d'avance pour les réponses.

CricriNew

L'hébergement mutualisé au sens classique est difficile à mettre au point avec Rails. Il existe une solution (phusion passenger), mais elle est encore jeune et même si elle est robuste, il n'y a pas d'admins suffisamment rôdés pour la proposer dans une offre packagée.

Techniquement, avec PHP, un hébergeur peut se blinder assez facilement (dans certaines limites) en imposant des quotas sur la RAM utilisée par chaque processus et en mutualisant les processus pour différents clients.

Rails ne permet pas cela (limiter la mémoire n'est pas supporté et un processus ne peut actuellement pas être réutilisé par plusieurs applications).

En conclusion, avec Rails les coûts d'hébergement sont plus élevés. C'est connu et mon retour d'expérience est le suivant :

Pour 95% des projets de dev web (et pas de config de CMS / dev très léger), les économies sur le dev sont très largement supérieures aux coûts supplémentaires d'hébergement, on y gagne donc beaucoup lorsqu'on propose un service complet au client (dev + hébergement / infogérance).

Donc à la question :
RoR est-il la bonne solution pour vos clients ?

Tout dépend de leurs besoins:

• si vous faites pas mal de devs spécifiques sur des contrats au delà des 5-10k€, oui, car si vos développeurs ne sont pas manchots ils vont très vite devenir beaucoup plus productifs et les coûts de dev vont chuter de plusieurs centaines ou milliers d'euros alors que l'hébergement ne prendra que 200 ou 300€ en plus par an (voir plus loin)
• si vous faites plus de l'adaptation de CMS ou des devs très courts (des adaptations de bases de codes existantes) qui se chiffrent en dessous des 5k€ là ça devient plus dur de rester compétitif avec Rails, ça peut se justifier pour des projets amenés à évoluer ou devant être maintenus sur le long terme (la maintenance de code PHP étant tout simplement un cauchemard la plupart du temps et donc un gouffre financier)

Maintenant en ce qui concerne l'hébergement d'une application Rails à moindre coût, ma société peux se positionner car nous avons déjà l'infrastructure en place et donc pouvons profiter d'économies d'échelles. Par contre il me serait nécessaire d'avoir plus d'informations (occupation RAM de l'application, taille de la base de données, nombre de requêtes - j'ai retenu 200 à 300/j).

Si vous désirez me contacter à ce sujet : lionel.bouton@jtek.fr

> Rails ne permet pas cela (limiter la mémoire n'est pas supporté
Ah bon ? Et dans une JVM via JRuby, un OS virtualisé, une solution de cloud computing ?

> et un processus ne peut actuellement pas être réutilisé par
> plusieurs applications).
C'est plutôt bien ça, non ?

> En conclusion, avec Rails les coûts d'hébergement sont plus élevés. Pour 95% des projets [...]
> les économies sur le dev sont très largement supérieures aux coûts supplémentaires
Ça c'est clair. L'essayer c'est l'adopter :)

Il faut replacer ma remarque dans son contexte : l'hébergement mutualisé : donc exit l'OS virtualisé ou le cloud computing.

Si tu utilises MRI (l'implémentation standard) que tu sois sur un OS virtualisé ou dans le nuage avec une part mémoire limitée, tu vas juste planter ton appli si tu atteints les limites de ta capacité RAM.

C'est à comparer avec PHP qui propose "memory_limit". Le script retourne une erreur, mais le processus Apache ne meurt pas, on peut le réutiliser pour une requête suivante sans avoir à le redémarrer (ce qui est couteux).

Avec Phusion Passenger tu peux limiter la casse (le redémarrage d'un processus est automatique et les vieux processus donc les plus susceptibles de prendre de la place en RAM sont régulièrement remplacés par de nouveaux). Avec Mongrel tu peux utiliser un soft de supervision pour redémarrer les processus tués par le noyau, mais au final, ça tient avec du scotch et des bouts de ficelle et surtout en cas de charge les perfs s'effondrent à cause du manque de RAM et des redémarrages perpétuels de processus.

Si tu utilises Jruby, tu consommes moins de RAM pour de grosses applications, mais le coût initial en RAM est élevé et proposer du mutualisé relève de la haute voltige sur JVM (techniquement c'est faisable, juste complexe et pas encore assez maîtrisé). Le problème de Jruby qui diminue régulièrement et devient rapidement négligeable est également que son support des gems disponibles n'est pas complet à 100%. Si tu n'as pas testé ton application avec Jruby ou vérifié la compatibilité des gems que tu utilises tu peux tomber sur un os.

Pour du mutualisé c'est bloquant.

mod_php permet de faire du mutualisé à un niveau qui n'existe pas sous Rails actuellement et cela fait naturellement monter les frais d'hébergement pour du Rails.

Merci beaucoup pour tes infos ! C'est un domaine sur lequel je n'ai pas pris le temps de faire une veille intensive...

> - RoR est il la bonne solution pour mes clients

RoR n'est qu'une technologie, récente qui plus est : ce sont les implications techniques, de pérennité, commerciales et dans votre métier qui sont intéressantes.

TECHNIQUE
En tant que technologie, dans l'absolu, RoR est-il vraiment une excellente technologie ?

La puissance et l'expressivité des outils permettent de développer vite et bien, donc moins de bugs et de maintenance.

Maintenant, je prêche pour ma paroisse : RoR gagne très haut la main contre un développement PHP "seul" (une horreur qui ne devrait plus exister), gagne encore contre l'utilisation d'un bon framework PHP, mais le fossé est moins grand.

PÉRENNITÉ
Vous investissez (au moins en temps et en compétences) dans la voie de RoR. Cette solution est elle envisageable sereinement dans la durée ? Je pense que oui, et l'expérience le prouve. La techno est jeune, mais beaucoup de chemin a été parcouru depuis 4 ans. On donnait à Rails deux ans à vivre puis péricliter, et le voilà plus bouillonnant que jamais !

De très grands sites utilisent Rails ; la communauté développe des composants de plus en plus impressionnants ; la technologie gagne en reconnaissance : oui, vous pouvez avoir confiance en Rails dans la durée.

COMMERCIALEMENT
Vous êtes convaincus par Rails, très bien, mais vos clients ?

À priori, s'ils n'exigent pas de J2EE ou .Net, ils seront moins fermés à Rails. Apparemment, c'est vous qui hébergez, donc ils n'auront pas besoin d'intégrer des compétences en sysadmin ou de couplage avec leur IT.

C'est à vous de les convaincre, mais très franchement ils n'ont pas à avoir peur. Vous pourrez trouver partout sur le net (et sur Railsfrance !) des argumentaires technico-commerciaux pour vous appuyer. Ce qui est génial avec Rails, c'est que vous leur vendez de l'innovation tout en ayant une excellente confiance.

Au final, vous leur vendez moins de temps, moins de bugs, moins de retards et d'incertitudes. Ils devraient apprécier.

MÉTIER
Le problème principal est surtout VOTRE adoption Rails. Si vous en êtes à rechigner sur l'hébergement et doutez de votre propre développeur, je ne peux pas grand chose pour vous.

Certes, il faudra que vos développeurs apprennent Ruby. C'est très facile. Il faudra leur apprendre à remplacer du SQL moche par des appels à ActiveRecord. C'est pas dur et on y gagne.

Si vos développeurs utilisent déjà un framework PHP, ils passeront à Rails très facilement. D'ailleurs, la moitié des frameworks PHP connus de nos jours s'inspirent fortement de Rails.

S'ils ne sont pas encore à utiliser des frameworks, alors mettez-les y immédiatement ! Leur code sera structuré, et il deviendra plus facile pour une personne étrangère au projet de comprendre son architecture. Vos équipes seront plus agiles et interchangeables.

... alors, faites d'une pierre deux coups : passez à Rails :)