Decrypt

Nous vous proposons dans cet article un témoignage vidéo d’un de nos clients Specialchem sur le portage de le leurs applications Web dans Windows Azure.

Une expérience très riche avec la mise en oeuvre d’instances Windows Azure, SQL Azure, DataSync, Azure Blob et l’intégration de Java, d’Apache Solr et de Tomcat sur des instances Azure sous forme de Web Roles et de Worker Roles.

Pour en savoir plus, regardez cette vidéo !

[...]

Varnish est un outil fabuleux à bien des égards. C’est une boite à outils qui permet de simplifier, harmoniser, sécuriser et accélérer les architectures web. Nous allons aborder dans cet article certaines fonctionnalités de Varnish pour commencer à en tirer le maximum. Il se positionne comme un reverse proxy cache. En gros nous allons le placer en amont des serveurs Web pour intercepter les requêtes, mettre en cache ce qui est généré par les backends et resservir le contenu généré depuis son cache. Mais son fonctionnement peut aller plus loin.

Le fonctionnement
Varnish se configure simplement grâce à deux types de fichiers. Le fichier de configuration de Varnish où nous allons définir certains paramètres internes et les fichiers VCL qui permettent de configurer le comportement de Varnish via une sorte de langage de programmation.

[...]

Dans le monde élastique du Cloud et plus précisément en ce qui concerne l’IaaS, nous nous heurtons souvent au problème : “quelle est l’adresse de telle machine, quel est son mode d’accès…”. A ces questions peuvent s’ajouter la problématique du tout automatique via un Capistrano par exemple. Vous me direz qu’il existe une console Web et des API. Oui mais la console n’est pas réellement exploitable pour l’automatisation et les API ont besoin de crédentials que l’on ne préfère pas disséminer partout sur les serveurs.

Le but de cet article est de montrer comment avoir un référentiel des instances disponibles sur un compte Amazon (ou autre) avec toutes les informations qui vont bien sans devoir utiliser la console web Amazon. Cette solution permet de pousser l’automatisation un cran plus loin en proposant une liste exhaustive que l’on peut automatiser et la possibilité d’avoir une liste des serveurs disponibles en une ligne de commande pour n’importe quel Devops allergique aux opérations sur navigateur web.

[...]

J’ai écrit une première version de cet article au sujet des modèles de cohérence il y a environ un an, mais je n’en étais jamais très content, car il a été rédigé à la hâte, et le sujet est suffisamment important pour mériter un traitement plus approfondi. ACM Queue m’a demandé de réviser l’article afin de le publier dans leur revue, et j’ai profité de cette occasion pour l’améliorer. La nouvelle version suit :

Finalement Cohérent – Construire des systèmes distribués et fiables à l’échelle mondiale exige des compromis entre la cohérence et la disponibilité.

À la base du Cloud Computing de Amazon se trouvent des services d’infrastructure tels S3 (Simple Storage Service) de Amazon, SimpleDB, et EC2 (Elastic Compute Cloud), qui fournissent des ressources pour la construction de plateformes de calcul à l’échelle d’Internet et d’une large gamme d’applications. Les exigences imposées aux dits services en infrastructure sont très strictes : ils doivent afficher de bonnes notes dans les domaines de la sécurité, la scalabilité, la disponibilité, la performance et la rentabilité, et ils doivent satisfaire ces besoins tout en desservant des millions de clients dans le monde, de façon continue.

Sous les couvertures, ces services sont des systèmes distribués colossaux qui opèrent à l’échelle mondiale. Cette échelle crée des défis supplémentaires, car quand un système traite des trillions et des trillions de requêtes, des évènements qui ont habituellement une probabilité d’occurrence faible sont désormais certains de se produire, ce qu’il faut prendre en compte dès le début lors de la conception et dans l’architecture du système. Etant donné l’étendue mondiale de ces systèmes, nous utilisons des techniques de réplication partout afin de garantir une performance cohérente et une haute disponibilité. Bien que la réplication nous rapproche de nos objectifs, elle ne peut les atteindre de façon parfaitement transparente ; sous plusieurs conditions, les clients de ces services seront confrontés avec les conséquences d’avoir utilisé des techniques de réplication au sein des services.

[...]

Le stockage de données en lui même n’est plus réellement un problème de nos jours. Nous pouvons facilement trouver des solutions qui permettent, selon les moyens techniques et financiers, de stocker un grand nombre de données. De son côté, Amazon, avec ses AWS, propose une solution « In the Cloud » permettant de créer un disque réseau de la taille désirée et de le raccrocher à une instance virtuelle. Cette solution, nommée EBS (Elastic Block Store), permet de créer à la volée des disques qui peuvent être attachés à chaud à une instance EC2 (Elastic Compute Cloud). Bien évidemment le coût financier de ce service est fonction de l’espace alloué. Trois solutions s’offrent alors à nous :

• Allocation surestimée d’un disque permettant en théorie de subvenir aux besoins futurs du système ce qui occasionne un surcoût.
• Allocation d’un disque pour assurer la pérennité à court ou moyen terme puis migration des données sur un disque plus grand quand le premier sera trop petit. Cette solution va demander un coût élevé en termes de maintenance et d’indisponibilité du système.
• Utilisation de LVM2 (Logical Volume Manager, version 2) pour la gestion des disques. Elle permet de lisser l’augmentation de la quantité d’espace alloué en ajoutant des disques au fur et à mesure des besoins tout en assurant un minimum d’indisponibilité.

[...]

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.

[...]

Il m’arrive souvent chez les clients de rencontrer la même confusion autour de ce triptyque, ce qui peut mener à de sérieux problèmes, surtout quand le client se base sur l’idée que « dans le doute on prend toutes les options, c’est forcément mieux ! ». C’est faux !
Une explication de chacune de ces notions s’impose.

[...]