Pelisse Romain

Que ce soit à des fins statistiques, marketing, ou encore plus simplement pour la recherche scientifique, nos systèmes d'information doivent constamment stocker un nombre impressionnant de données, souvent de plusieurs téraoctets, tout en garantissant non seulement un temps d'accès défiant toute concurrence, mais aussi permettre de retrouver un échantillon ou un sous-ensemble de ces données tout aussi rapidement. Dans cet article, nous allons étudier comment Infinispan [1] permet d'implémenter de puissantes fonctions de recherche, à l'aide de l'une de ses récentes fonctionnalités de requête (« Query » [2]).

En ces années « Big Data », ce n'est pas seulement la taille ou la quantité de données qui représente un nouveau défi, mais aussi leur nature. En effet, que ce soit pour des raisons techniques de tenue de charge ou par souci de simplicité, les données sont sauvegardées dans de plus en plus de systèmes différents. Si l'on pouvait, au début des années 2000, estimer que nos données applicatives seraient stockées, la plupart du temps, dans une base de données relationnelle, ou éventuellement extraites d'un système historique (mainframe), le paysage a assez radicalement changé.

Depuis le début de l'ère internet, le nombre de systèmes et d'applicatifs déployés par les entreprises ne cesse de croître de manière exponentielle, et l'arrivée du cloud et du Big Data n'a fait qu'accélérer la tendance. En outre, là où il y a vingt ans un administrateur système gérait une douzaine de machines, le même administrateur en gère aujourd'hui parfois plusieurs centaines. Or, il devient de plus en plus compliqué de proposer une supervision adaptée qui puisse supporter une telle mise à l'échelle.

Si Puppet vient déjà naturellement avec le support de nombreux produits et outils, et que PuppetForge regorge aussi de nombreux modules complémentaires, il n'en reste pas moins que la plupart des systèmes d'information incorporent des logiciels « maison », ou simplement trop spécifiques pour bénéficier du support de la communauté. Heureusement, Puppet, comme pratiquement toutes les solutions open source, propose un mécanisme d'extensions permettant d'ajouter aisément le support de nouvelles « ressources », que nous allons étudier en détails dans cet article.

Plus que jamais avec le "cloud" et la vague du NoSQL, les problématiques de montée en charge et de passage à l'échelle (scalability, dans le langage de Shakespeare) prédominent dans la conception d'application en ligne. Comment parvenir à atteindre le nombre d'utilisateurs concurrents attendu ou espéré ? Comment supporter un pic de charge, lorsque cette charge s'accroît temporairement ? Comment améliorer ou conserver son temps de réponse moyen, malgré cette charge variable et généralement grandissante ?

On reproche souvent au développement Java, bien que très apprécié dans les entreprises, de manquer de facilité et de pragmatisme. Ainsi, quand il s'agit de réaliser un petit applicatif, ou un outil en ligne de commandes, on se dirige souvent très naturellement vers le Shell ou des langages tels que Python. Néanmoins, avec l'utilisation de quelques bibliothèques open source bien choisies, on peut aisément utiliser Java pour réaliser de tels projets. Démonstration par l'exemple, qui j'espère aidera le lecteur si un jour le besoin de réaliser un tel outil s'impose à lui...

Un peu plus d'une dizaine d'articles [2.1] ont précédé celui-ci dans ce magazine, et ont déjà amplement décrit des outils de gestion de la configuration de serveurs [1.1], tels que Puppet [1.2], Chef [1.3], ou même encore CFEngine[1.4]. L'objectif de cet article n'est pas de reprendre cet exercice de style, mais d'étudier un cas pratique, et surtout complet, d'automatisation de déploiement d'un serveur.

Depuis l'arrivée des réseaux sociaux [1] à la Facebook [1.1] ou professionnels à la LinkedIn [1.2], la notion de messagerie a clairement beaucoup évolué et les attentes des utilisateurs ont évolué de concert. Ces derniers souhaitent désormais un outil de messagerie plus élaboré et plus convivial que le mail traditionnel, et, surtout, de plus en plus de personnes réclament une amélioration de la messagerie dans le cadre de leur travail. Ainsi, l'utilisation de ces nouveaux systèmes de messagerie a même amené certains grands groupes, comme Atos Origin [1.3], à revoir leur propre infrastructure de mails pour adopter une approche dite plus « 2.0 ».

L'heure du Cloud ayant sonné, il va être temps de revoir nos degrés d'exigence en termes de scripts Bash. En effet, finis les scripts à moitié dysfonctionnels ou cassés, le Cloud ne les permet plus ! Pourquoi ? Parce que le « Cloud » demande de la robustesse, les systèmes qui s'y exécutent doivent survivre aux pannes et autres coupures de réseaux... Oui, mais comment faire ? Comment rendre ses scripts plus robustes et plus propres ? Petite explication de texte dans cet article...