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…)

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…)

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…)

Le nombre de voitures connectées devrait passer de 45 millions en 2011, soit 5 % du parc automobile mondial, à 210 millions en 2016 (18 % du parc). Sur cette période, ce marché passerait de 15 milliards de dollars à 40 milliards.

C’est un marché émergent à prendre en compte dès à présent, en anticipant sur les contraintes spécifiques à ces environnements.

Dans cette série d’articles, nous allons parcourir les différentes facettes des applications embarquées dans les véhicules. (Lire la suite…)

OCTO organise le mardi 27 mars 2012 à partir de 8h45 un petit-déjeuner gratuit, à Eurosites George V  « Banque de détail du futur : scénarios 2020 ».

Avec la participation de BNP Paribas Fortis, Friendsclear, ainsi que d’autres acteurs du monde bancaire.

Nous traversons une période paradoxale : confrontés à des innovations technologiques qui bouleversent nos organisations y compris dans le secteur bancaire traditionnellement prudent sur les effets d’annonces, et contraints par un rationnement budgétaire due à une crise financière sans précédent. Crise qui impose en plus de grands travaux en terme de gestion des risques et de reportings réglementaires réduisant d’autant la marge de manœuvre des DSI.

Dans ces conditions, l’espace alloué à l’innovation est limité. Il est donc nécessaire de choisir et c’est peut-être le grand avantage de cette crise : obliger nos entreprises à repenser leur orientation stratégique.

(Lire la suite…)

J’entends souvent la question suivante : L’architecture d’entreprise (EA) doit-elle être centrée sur la vision Métier ou Technologique ?

On parle aujourd’hui de plus en plus régulièrement d’architecture Business et on réalise facilement l’amalgame avec l’EA.

L’architecture Business n’est qu’un domaine de l’architecture d’entreprise qui, pour reprendre la définition donnée par TOGAF, en comporte quatre (Business, data, application, technology). Elle adresse la stratégie Business, l’organisation, les Business process clés et les interactions entre ces éléments. L’architecture d’entreprise adresse également la couche technologique permettant de supporter l’architecture Business.

La notion de capacité (capability) que l’on retrouve dans TOGAF est ici intéressante :
(Lire la suite…)

Depuis le milieu des années 2000, l’augmentation de la puissance de calcul de nos ordinateurs ne passe plus par l’élévation de la fréquence des processeurs mais par la multiplication des cœurs de processeur au sein de nos machines.

Pour tirer parti de cette multiplication, un algorithme doit être parallèlisé, c’est à dire qu’il doit pouvoir diviser ses instructions et les répartir sur différents cœurs pour une exécution simultanée.
De nombreux outils permettent d’implémenter un algorithme parallèle sur une machine, par exemple la librairie Task Parallelism Library (TPL) en .Net, abordé par Olivier Roux et Alexis Flaurimont ou encore le fork/join en Java étudié par Marc Bojoly et David Rousselie.

D’autres outils, implémentant par exemple le pattern Map/Reduce, permettent de distribuer le calcul vers des cœurs situés sur différentes machines.

Cet article présentera une introduction à la programmation orientée acteurs et les réponses qu’elle apporte à ces différents problèmes. (Lire la suite…)

« La complexité, c’est comme le cholestérol. Il faut surtout se débarasser du mauvais. » (Proverbe gascon-malgache)

DDD est l’acronyme de Domain Driven Design. Ce n’est ni un framework, ni une méthodologie, mais plutôt une approche décrite dans l’ouvrage du même nom d’Eric Evans. Un de ses objectifs est de définir une vision et un langage partagés par toutes les personnes impliquées dans la construction d’une application, afin de mieux en appréhender la complexité. Nous ne souhaitons pas faire ici une présentation de DDD (voir plutôt ici pour une introduction). Nous voulons montrer comment DDD peut adresser certaines problématiques évoquées dans l’article “J’ai mal à mon application ! Ca se soigne ?” au travers d’un exemple d’application (“je veux vendre et acheter des légumes sur internet”), tout en s’inscrivant dans une démarche de développement Agile.

(Lire la suite…)

    En écrivant le livre blanc sur l’archivage documentaire dématérialisé ( « Archivage documentaire : enjeux de la dématérialisation, papier contre bits »), il nous est arrivé de croiser à Octo des collègues travaillant sur des projets de coffre fort électronique. Eux se moquaient volontiers, car l’archivage traîne, il faut bien le dire, une image poussiéreuse (faussement, voir notre livre blanc) tandis que le coffre fort électronique en pleine émergence est plutôt très tendance. Acceptant tout de même de me parler, nous avons échangé. Nous nous sommes alors vite aperçus que leurs problématiques et leurs enjeux étaient très similaires aux nôtres.

(Lire la suite…)

Le Challenge USI est un concours organisé dans le cadre de l’USI 2011, en partenariat avec VMware et Steria. Il est ouvert à des équipes d’étudiants et de développeurs qui ont envie d’implémenter des architectures à haute performance, comparables à celles des grands du Web (Google, Facebook, Twitter, etc.). Il consiste à créer une application de Quiz Synchrone qui supporte 1 milliard d’utilisateurs, dont 1 million en simultané. L’architecture technique est complètement libre, sous contrainte de système Linux. Les 3 équipes dont l’application aura permis de faire jouer le plus de monde se verront remettre un prix lors de L’USI en juin 2011.

(Lire la suite…)