@Simon Ok, merci pour les infos, je ne savais pas qu'on pouvait trouver suffisamment d'alternatives gratuites pour avoir un set de features suffisantes avec une free instance.
Ça fait quand même beaucoup de setup de services pour couvrir ce qui est les fonctionnalités de base d'un dédié :) @Sébastien > Du coup Olivier, que recommandes-tu comme hosting à tes clients? Aujourd'hui mes clients, ce sont des startups pour qui je travaille exclusivement pendant plusieurs années, que ce soit en tant que consultant ou salarié. Du coup, le problème ne se pose plus trop : je leur prend des dédiés et je les administre. Si je devais repasser en mode freelance qui enchaine les contrats, je pense que je prendrais un dédié ou plusieurs dédiés sur lesquels je les hébergerais selon les besoins en ressources de chacun et dont je prendrais l'entière responsabilité - en facturant des services de maintenance en conséquence. C'est pénible et c'est beaucoup de travail, mais ça me semble nécessaire pour résoudre deux problèmes qui me semblent majeurs : 1. l'obsolescence des apps rails. Lorsqu'une app rails atteint les deux ou trois ans, il devient impossible de la faire évoluer. Pour pallier à cela et ne pas donner l'impression que nous réalisons des apps jetables, il faut en permanence mettre à jour les gems et faire les adaptations nécessaires (à facturer en conséquence). À noter que le problème se poserait aussi sur heroku, avec ses changements de stacks et de versions de postgres. Une alternative serait de considérer que c'est ok de devoir réécrire une app tous les trois ans, mais c'est encore moins cost effective, pour le coup, et ça ne résoud pas le problème suivant. 2. la sécurité. Le net est devenu un enfer rempli de pentesters wanabee. Une application que nous déveloperions et laisserions sans maintenance pendant quelques années deviendrait rapidement une porte ouverte pour transformer l'hosting du client en plateforme d'attaque. S'assurer que toute les dépendences sont à jour est un must have. Là aussi, le même problème se pose sur heroku : si la couche OS est maintenu par leurs soins, nous ne sommes pas à l'abris de vulnérabilités dans les gems. @Jean-Hadrien > Parfois, ça me gratte de faire un gros heroku logs --tail > log.txt plutôt > que de m'emmerder avec logentries. Won't work, j'ai déjà essayé :) Le problème est que heroku restart lui-même les dynos quand ils ont tourné suffisamment longtemps à leur goût. Du coup, quand tu lances un `heroku logs -t | tee logs.txt` et que tu reviens le lendemain, tu vois un "broken pipe" et tu te rends compte que tu as perdu quatre ou cinq heures de logs. Pour pallier à ça, il faudrait utiliser quelque chose comme god et t'assurer que le tail tourne en permanence. Mais bon, quand tu en arrives à installer god sur un dédié pour avoir les logs d'heroku ... :) On Saturday, October 12, 2013 5:47:08 PM UTC+2, HappyNoff wrote: > > Salut les gars, > > Je me posais la question du hosting quand vous vendez un site à un client. > Si la demande est assez légère et qu'un heroku gratuit suffirait, comment > vous > le vendez au client ? > Je me doute qu'on peut pas lui facturer un hébergement qui ne nous coute > rien (quoi que ?). > > J'ai aucune idée de comment gérer ce sujet donc votre avis m'intéresse. > > Merci à vous ;) > > Simon Courtois > -- -- Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected] --- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Railsfrance. Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse [email protected]. Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
