On Sat, 14 Aug 2010 12:49:01 +0200, eberkut <eber...@minithins.net> wrote:
> Pour Google, Facebook ou Twitter, ça peut être simplement que la > virtualisation n'est pas adaptée à leurs workloads et/ou ils ont > commencé à construire leurs infra avant que la virtualisation ne soit > suffisamment performante. Pas adaptée à leurs workloads, certainement. Par contre, Twitter refait son infra à neuf cet été et ne passe a priori pas à du virtualisé donc j'ai un doute sur la deuxième possibilité. > Et ils ont quand même la facilité de déploiement grâce à des > solutions de provisionning maison. Mais les gros cloud providers eux > sont basés sur de la virtualisation (de mémoire, AWS sur Xen, > Rackspace sur VMWare, Azure sur Hyper-V...). AWS sur Xen, d'accord pour EC2 et EMR, mais je ne suis pas certain que les services de stockage de données comme S3, SQS ou SimpleDB tournent en environnement virtualisé. Quelqu'un aurait plus d'infos là-dessus ? On Sat, 14 Aug 2010 19:14:54 +0200, Benjamin Billon <bbillon...@splio.fr> wrote: > Dans des cas de plus en plus fréquents, le NoSQL devient une option > réaliste et crédible. Et on rejoint les Twitter, Facebook et autres > sites sans virtualisation. Ça dépend de quelle virtualisation on parle. Pas mal de BDD NoSQL scalables sont en Java ou en Erlang et les deux langages tournent dans leur propre VM. Je considère déjà ça comme une forme réduite de virtualisation. On Sat, 14 Aug 2010 17:16:23 +0200, Xavier Beaudouin <k...@oav.net> wrote: > Si on trouve que le coût en CPU est trop élevé... bah des fois > réapprendre aux développeurs a coder c'est aussi une bonne idée... > comment faire ? baisser la prio de leur VM de dev a des valeurs > basses.... histoire de leur faire comprendre qu'un code bien optimisé > c'est de l'argent de gagné ! Si ça leur fait prendre deux fois plus longtemps pour finir une application ou choisir la performance contre la fiabilité, pas certain que ça soit une bonne opération. Le CPU coûte souvent moins cher que le dev, et presque toujours moins que le downtime. -- Pierre Chapuis _______________________________________________ FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
