Dans le monde Big Data, rapidement se pose un certain nombre de besoins.
Besoins qui, pris unitairement, sont déjà complexes à résoudre mais qui, mis bout à bout, s’avèrent encore plus difficiles à intégrer.
Parmi ces besoins, on peut citer, par exemple, les besoins de qualité de données ou de linéage (problématiques qui peuvent être regrouper sous le terme de data governance).
Cet article n’a pas pour objectif de fournir une solution clé en main ni de parler d’outils déjà existant mais plutôt de poser différentes réflexions que j’ai pu avoir afin de savoir si elles avaient un sens…
Ça y est… Devoxx est fini… :’( Comme je l’ai dit dans un article précédent, je ne ferai pas de compte-rendu exhaustif de présentations auxquelles j’ai pu assisté à Devoxx.
Cependant, je tenais à revenir sur la présentation “Service Versioning in SOA and Cloud” par Ignaz Wanders (@ignazw) dont le synopsis était :
Keeping versioning under control is essential in the success of a SOA. However, there are no industry standards for service versioning, thus leaving the responsibility of implementing a service versioning system up to the architects and developers within the IT enterprise.
Lorsqu’un projet débute, il est important (à mon avis) de se poser la question sur la façon dont celui-ci sera découpé. Pour être plus précis, il existe deux types d’approches :
le découper fonctionnellement, le découper techniquement. En outre, en plus de ce type de découpage, il est également important de s’interroger sur la façon dont il sera représenté dans le SCM : faut-il tout mettre dans le même projet (au sens SVN ou git du terme) en utilisant éventuellement des sous modules maven si c’est ce dernier qui est utilisé, ou faut-il en créer plusieurs?
Suite à de nombreuses présentations de Cassandra (faites, entre autre, par Michaël Figuière) et à une opportunité de regarder plus précisément ce qui se cachait réellement derrière cette implémentation d’une solution de la famille des produits NoSQL orienté colonnes, je vais, dans cet article, tenter de décrire ce que j’ai aimé et ce que je n’ai pas aimé sur Apache Cassandra.
Je tiens toutefois à préciser que je n’ai aucune expérience réelle sur le produit et que je ne m’appuierai donc que sur sa documentation officielle en version 1.
Cet article est une traduction “libre” de l’excellent papier de Michael Duell qui se nomme “Resign Patterns” Ailments of Unsuitable Project-Disoriented Software.
En fait, Resign Patterns reprend le principe des Design Patterns tels que décrit par the Gang Of Four mais en proposant un tout autres types de Patterns… Je vous laisse juger de leur véracité… Je pense qu’ils ont suffisamment fait leurs preuves pour ne pas avoir droit, eux aussi, à leur gloire… ;-)
Ci-dessous se trouve une présentation que j’ai donné sur les problématiques liées aux architectures distribuées. Pour information, c’est un retour d’expérience d’une mission qui date un peu puisque c’était en 2007 mais les préconisations restent identiques à ce jour.
Enjoy et n’hésitez pas à commenter ;-)
Introduction sur les problématiques d'une architecture distribuée View more presentations from jetoile
