|
|

Si la vie des vrais agriculteurs était aussi douillette que dans FarmVille, le jeu phare de chez Zynga, alors ma famille n’aurait probablement jamais quitté les hivers rudes du North Dakota. A FarmVille, aucun des contes atroces que me racontait ma grand-mère n’est véridique. Les agriculteurs y prospèrent, les cultures fleurissent, et les animaux ne partent jamais au « red barn » (abattoir). A mon avis, c’est justement ce charme rustique d’un univers où l’on ne salit même pas ses souliers, qui a contribué à rendre FarmVille « le jeu le plus important au monde » dans un délai étonnamment court.
Comment FarmVille a-t-il réussi le scaling d’une application web pour accueillir 75 millions de joueurs par mois ? Luke Rajlich de FarmVille nous a gracieusement révélé quelques uns de leurs défis et de leurs secrets. Je passe la parole à Luke. [...]
Et voici la suite tant attendue de la comparaison entre une infrastructure déployée sur le Cloud via les AWS (Amazon Web Services) et une infrastructure physique classique. Pour rappel, concernant l’infrastructure physique, je considère autant l’infrastructure hébergée soi-même que celle prise en charge chez un hébergeur spécialisé. De même, je considère autant les infrastructures reposant directement sur l’OS de la machine que celles reposant sur des environnements virtualisés. Le Cloud repose également sur de la virtualisation, mais ce n’est pas la technologie qui nous intéresse ici, mais la manière de la mettre à disposition des clients (vous).
[...]
Je constate encore beaucoup d’interrogations sur les différences impliquées par le choix d’une infrastructure Cloud de type AWS (Amazon Web Services) ou d’une infrastructure physique classique. Tout d’abord, il y a un certain nombre d’idées reçues sur le sujet que je vais tenter de décrypter pour vous. Ensuite, il faut comprendre que chaque infrastructure présente des avantages et des inconvénients : une infrastructure de type Cloud ne correspondra pas forcément à vos besoins dans tous les cas, cependant, elle peut répondre à certains d’entre eux en optimisant ou facilitant ce que propose une infrastructure physique classique. Je vais donc présenter les différences que j’ai notées entre ces 2 infrastructures afin de vous aider à y voir plus clair et que vous puissiez vous faire une idée.
[...]

Pour ceux qui doutaient encore de l’efficacité de Puppet, voilà encore un bel exemple de réalisation utilisant cet outil ! Allez consulter cet article de High Scalability : How FarmVille Scales to Harvest 75 Million Players a Month ! [...]

Enfin une facture consolidée !!! Pratique pour les sociétés qui gèrent plusieurs comptes pour différents clients ou bien pour un client divisé en plusieurs unités ! Un compte est désigné comme payeur et un ensemble d’autres comptes y sont rattachés via une simple hiérarchie à un niveau. La relation se limite au niveau de la facturation et chaque compte conserve son autonomie et sa gestion propre en termes d’accès aux services (EC2, S3, …) : pas d’accès spécial pour le compte payeur, chacun conserve ses credentials et ses droits (ACLs).
[...]
Un article de saison pour clore cette année : un peu d’algorithmique et notamment le B-tree (de Noël ;ob). Le B-tree (ou arbre équilibré) est un algorithme très utilisé et notamment dans la gestion des bases de données et des systèmes de fichiers. Il permet d’effectuer des opérations sur les données triées qui le composent suivant un temps amorti logarithmique. Ce sujet n’est pas tant pour vous expliquer le fonctionnement d’un B-tree, même si le fonctionnement est intéressant au demeurant, mais pour vous sensibiliser à la connaissance des algorithmes (les grands classiques et leurs dérivés) qu’il est très pratique de comprendre pour optimiser les performances de nos architectures et effectuer les bons choix.
[...]
Les bases de données non relationnelles sont mises en avant depuis quelques temps avec un panel important de systèmes de stockage de la forme clé/valeur (key/value store). Cette approche permet d’avoir des structures optimisées pour certains types de fonctionnel et facilement distribuables. Tokyo Cabinet est un de ces outils. C’est un outil de stockage clé/valeur open source sponsorisé et utilisé par Mixi (Facebook japonais). Il a été développé par Mikio Hirabayashi que vous pouvez retrouver ainsi que l’exhaustivité des produits qu’il met à disposition sur Mikio Hirabayashi’s homepage. Tokyo Cabinet est couplé à un autre produit : Tokyo Tyrant. Tokyo Tyrant est en fait l’interface réseau qui permet, entre autre, d’accéder à partir d’un serveur distant à Tokyo Cabinet. Il ne se limite cependant pas à cela et permet un certain nombre de fonctionnalités très intéressantes. Le point fort de ce couple est la rapidité de traitement des requêtes, ainsi que les possibilités de mise en oeuvre.
[...]
Fin octobre 2008, Microsoft avait annoncé officiellement son offre de Cloud : la plateforme Windows Azure. Initialement prévue pour 2009, la sortie commerciale de Windows Azure a été repoussée à février 2010 et deviendra alors accessible aux entreprises moyennant finance. La plateforme Windows Azure regroupe un ensemble de services disponibles sur le nuage. Ces services sont physiquement hébergés dans les différents datacenters de Microsoft. Pour l’instant il existe deux datacenters aux Etats-Unis, un autre étant prévu prochainement en Europe. Les datacenters hébergeant les services et l’architecture de la plateforme Windows Azure sont conçus pour assurer une haute disponibilité et une forte scalabilité. Microsoft assure que la plateforme peut garantir une disponibilité de service sans interruption car les serveurs sont tous repliqués au moins deux fois. Le transfert vers le serveur de remplacement est automatique si le serveur principal a un problème. Les trois grands services proposés sont : Windows Azure, SQL Azure et .NET Services.
[...]
Décidemment, encore un article sur les AWS (Amazon Web Services). Au-delà du fait, que ce sont de bons composants dans le cadre de la mise en place d’une infrastructure, il faut noter qu’ils couvrent un scope complet de ce que l’on peut trouver dans une infrastructure en termes de fonctionnalités (gestionnaire de files de messages -SQS-, base de données non relationnelle -SimpleDB- et relationnelle -RDS- depuis peu, traitement massif de données -MapReduce, bonjour BI ?-, instances virtuelles -EC2-, VPN -VPC-, …), mais également en termes de « background technique ». Je m’explique : prenons l’exemple de S3, qui sera notre sujet d’étude dans cet article d’ailleurs, quoi de plus simple qu’un système de stockage d’objets ? Ca se résume à « PUT », « GET » et « DELETE ». Et pourtant derrière cette apparente simplicité, se cache une complexité technique sous-jacente étonnante, qui reprend bons nombres de concepts « standards », mais que l’on implémente rarement soi-même, parceque complexes à mettre en place. On laisse donc cela aux outils que l’on utilise ou tout simplement on fait l’impasse dessus. Tout cela pour introduire les 9 principes sous-jacents au service S3 d’Amazon qui font de ce service apparemment succint, un bel exemple technique.
[...]
Une petite vidéo intéressante de Werner Vogels de moins de 3 min sur un retour utilisateur (Joshua Baer, co-fondateur et CEO de OtherInbox) sur les AWS (Amazon Web Services) et plus particulièrement l’utilisation qui est faite de SimpleDB et S3. Ce retour montre comment en utilisant différents services de stockage (en l’occurrence SimpleDB et S3) adaptés au type de la donnée à conserver et en se reposant sur l’architecture AWS, on optimise et facilite le développement de son propre service. En résumé, pourquoi refaire ce qui existe déjà.
[...]
|
|
Commentaires récents