Java 8 est réactif !


Programmation réactive

Parmi les nombreuses évolutions que nous propose Java8, l’une d’entre-elles attire particulièrement notre attention. Il s’agit de la présence de la classe CompletableFuture<>. Mine de rien, cette classe va bouleverser les applications Java. De nouvelles architectures seront proposées, de nouveaux frameworks vont apparaître pour remplacer les anciens, etc. C’est une classe majeure de Java8.
(Lire la suite…)

La genèse du modèle réactif

Programmation réactive

Dans un précédent article, nous avons introduit un nouveau modèle de développement qui émerge de plus en plus : le modèle réactif. C’est un modèle fondé sur la réaction à des événements déclenchés par les périphériques hardware (disque ou réseau essentiellement). Pourquoi seulement maintenant ? (Lire la suite…)

Jusqu’où peut aller un simple ordinateur de bureau avec une application web java réactive ?

Programmation réactiveLa tendance actuelle : de plus en plus d’internautes connectés partout, tout le temps et souvent depuis plusieurs machines en même temps (ordinateur de bureau, tablette, mobile).

Les promesses de la programmation réactive : permettre de gérer sur une même machine beaucoup plus de connexions en parallèle et de traiter plus de requêtes par seconde, ceci avec peu de threads donc beaucoup moins de mémoire et de CPU qu’avec les modes de programmation classiques.

Nous avons réalisé (Lire la suite…)

La révolution réactive

Programmation réactive

Nous sommes au matin, à l’aube, devant les fortifications. Les hommes sont prêts. Depuis quelque temps déjà, les choses évoluent par petite touche, d’ici de là. Des fissures remettent en cause les fondations. Ailleurs, certains ont déjà franchi le pas. D’autres hésitent. La question n’est plus de savoir si l’on y participe, si l’on résiste, mais à partir de quand on s’y met. Toutes ces évolutions convergent vers le même but : une nouvelle révolution des systèmes d’information.

(Lire la suite…)

Les nouvelles architectures front Web et leur impact sur la DSI – partie 2

Dans la partie 1 de cet article, nous avons traité des nouvelles architectures front-end basées sur des applications Web massivement Javascript appelant des API offertes par un serveur back-end : les nouvelles architectures front Web et leur impact sur les DSI – Partie 1.

Nous avons vu qu’elles sont apparues ces dernières années grâce à l’augmentation des performances des navigateurs et à l’amélioration des outils d’industrialisation des développements Javascript.

Dans cette seconde partie, nous nous intéresserons aux raisons pour lesquelles on devrait choisir ces nouvelles architectures, aux opportunités qu’elles offrent, et aux conséquences sur les organisations des directions informatiques.

(Lire la suite…)

Les nouvelles architectures front Web et leur impact sur les DSI – Partie 1

Les applications Web évoluent. Depuis les premiers sites en HTML statique jusqu’aux applications AJAX de ces dernières années, en passant par les multiples technologies de sites Web dynamiques (PHP, ASP, Java, Rails…), les architectures applicatives et les outils pour les mettre en place connaissent régulièrement des avancées majeures et des points de ruptures.

Depuis deux ans, nous voyons venir une nouvelle vague technologique qui submerge le paysage des applications Web. Celle-ci n’a pas encore de nom bien défini comme ont pu l’avoir les RIA ou AJAX. Nous les appellerons les « architectures MV* côté client ».

Elles se constituent principalement de ce principe d’architecture : le serveur ne doit plus gérer l’affichage mais seulement envoyer des données brutes à afficher, et toute la génération des écrans et la gestion des interactions avec l’utilisateur doivent être géré côté client, c’est-à-dire dans le navigateur.

Dans ce billet, nous préciserons cette architecture et expliquer les raisons de son émergence. Dans un second billet, nous verrons pourquoi il est pertinent de les mettre en place dès aujourd’hui, les opportunités qu’elles offrent, et quels sont les impacts à prévoir pour les DSI.

(Lire la suite…)

Hadoop 2 en version stable : quel intérêt pour vous ?

Ca y est, Hadoop 2, ou plus précisément la 2.1.0 est passée en version « bêta ».

Et, plus intéressant, la sortie du four de la première version estampillée « stable », la 2.2.0, est maintenant officiellement prévue aux alentours de la mi-Septembre 2013.

Nous ne sommes plus qu’à quelques bugs d’Hadoop 2 !

Tout ça c’est très bien mais quel est vraiment l’intérêt de cette nouvelle version majeure pour un datalab, un cluster de production, un poc ?

Dans cet article, nous allons tâcher de balayer les différences majeures à connaître de cette version par rapport à Hadoop 1 dont nous avions jusque là pris l’habitude.

(Lire la suite…)

Introduction à Flume NG

Flume est une solution de collecte, aggrégation et transfert de gros volumes de logs. Il a été pensé pour gérer des débits importants avec une fonctionnalité native d’écriture dans HDFS au fil de l’eau. Pour gérer ces gros volumes/débits, il se doit d’être très scalable, et donc distribué. L’outil fait partie de l’écosystème Big Data open source Hadoop. Pour vous aider à le situer, ses alternatives sont Scribe et Chukwa pour les plus connus, et également Kafka même si ce dernier répond à d’autres problématiques de par sa nature (messagerie publish/subscribe).

Flume a récemment subit un lifting profond. Il aura fallu 1 an pour refondre son architecture depuis Août 2011 et réécrire certains de ses composants coeurs. Aujourd’hui, 6 mois après la première release stable, Flume NG (version 1.x) est fiable, performant, définitivement prêt pour la production. Bref il est temps de s’y pencher sérieusement. Je vous propose donc de brosser un tableau de la solution à travers ce billet, en regardant de près ses forces, mais aussi ses faiblesses…

(Lire la suite…)

Quelles interfaces pour les voitures de demain ? (3/3)

Après avoir étudié les différentes solutions techniques proposées par les constructeurs, les impacts sur l’ergonomie des applications, nous allons nous intéresser aux difficultés que doivent traiter les développeurs d’applications. (Lire la suite…)

Hadoop dans ma DSI : comment dimensionner un cluster ?

Ca y est, vous avez décidé de mettre en place un cluster Hadoop.

Prochaine étape, le dimensionnement… Hadoop étant une solution complexe, plusieurs questions se posent :

  • HDFS gère des réplicas, Map Reduce génère des fichiers, comment faire pour prévoir mon stockage ?
  • Comment prévoir mes besoins en CPU ?
  • Comment prévoir mes besoins en mémoire ? Faut il faire une distinction sur certaines parties du cluster ?
  • On m’a dit que Map Reduce déplace le code proche des fichiers… Concrètement, qu’est ce que cela implique pour prévoir mes besoins réseau ?
  • Dans quelle mesure les cas d’usages métier entre en compte dans le dimensionnement ?

C’est ce que nous allons tenter d’éclaircir dans cet article en fournissant des explications sur ces différents points ainsi que des moyens pour calculer vos besoins.

(Lire la suite…)