Initialement, les technologies Big Data ont vu le jour en réponse aux besoins de la communauté analytique. Ils sont nés de la nécessité d’effectuer des analyses à grande échelle sans faire exploser les budgets. Depuis, ils ont mué en un ensemble de technologies servant en temps réel les aspects opérationnels d’une entreprise. À commencer par Hadoop, Pig et Hive, HBase et autres solutions NoSQL puis Spark, Flink, Drill et Kafka, une multitude de technologies qui ont été créées pour traiter chacun des trois aspects du Big Data, à savoir le volume, la variété et la vitesse.

Arrêtons-nous un instant sur ces technologies. Elles ont commencé par déplacer des workloads traditionnellement réservés aux datawarehouses, lesquels sont désormais activement épaulés ou remplacés par des lacs de données. Car le seul élément qui distingue véritablement le datawarehouse et le datalake est le lieu final de stockage. Mais il est important de voir plus loin.

Du datalake aux microservices

Imaginons qu’une entreprise déploie son applicatif métier directement sur un datalake. Je ne parle pas ici d’une simple application analytique mais d’applications qui nécessitent une persistance des données, par exemple une base de données, voire une base orientée documents. Si la plate-forme de stockage peut augmenter sa capacité de façon linéaire, alors pourquoi ne pas envisager d’installer les applications directement sur celle-ci ? Si l’application s’exécute là où les données sont stockées, il n’y a plus à se préoccuper de les transférer ultérieurement à des fins d’analyse.

Si nous pouvions faire migrer nos applications existantes sur cette pile technologique et mettre à profit la plateforme de stockage partagée, nous pourrions même aller encore plus loin.

Une architecture orientée services (SOA) n’est pas un concept neuf mais, dans la pratique, la capacité de montée en charge qui en est attendue peut se révéler coûteuse. Le principal problème de l’architecture SOA est que jusqu’à présent, le nombre de messages créés est d’autant plus élevé que les composants sont petits et nombreux, de sorte qu’il est très facile de pousser les plateformes de messagerie à leurs limites. Avec le nouveau modèle de messagerie par publication-abonnement, il devient possible de dépasser un million d’événements par seconde moyennant un investissement réduit. Les entreprises ont maintenant tout le loisir de porter les concepts SOA au niveau initialement prévu pour cette architecture. Le but essentiel du microservice est de limiter le service à une seule fonction, de sorte qu’il soit facilement adaptable et interchangeable.

Faire le lien entre microservices & Big Data

Il est parfois difficile de voir en quoi les microservices s’accordent parfaitement avec les technologies Big Data, mais la fraude sur Internet en est un bon exemple.

Imaginons le site web d’une banque comptant un grand nombre d’utilisateurs. La plupart d’entre eux sont légitimes mais certains sont des fraudeurs. La mission de la banque est d’identifier le maximum de fraudes le plus rapidement que possible de façon à anticiper tout préjudice financier.

Chaque événement intervenant sur un site web est consigné dans ses fichiers journaux, qui doivent être traités en quasi-temps réel afin de rendre cet usage fonctionnel. Pas question en effet d’attendre un traitement des données en différé. Un délai ne serait-ce que de cinq minutes pourrait laisser à un escroc le temps de partir avec l’argent de vos clients.

Le flux de clics peut être traité par une série de différents microservices au fur et à mesure de la création d’événements. Ces services pourraient exploiter des bases de données contenant l’historique de l’utilisateur connecté ou encore une liste noire d’activités réputées frauduleuses, voire une liste blanche d’actions qu’un escroc s’abstiendra notoirement d’effectuer (par exemple la lecture du contrat de licence d’utilisateur final). Chacun de ces microservices pourra alors générer ses propres informations, pour un examen plus approfondi. Ces événements peuvent servir à déclencher l’intervention d’une équipe de sécurité dans le cadre d’une évaluation heuristique du trafic en temps réel, portant même éventuellement sur le lieu où se trouvent les escrocs, par exemple en vue d’une action des forces de l’ordre.

Ces services peuvent être facilement adaptés, modifiés, complétés ou validés en fonction de données recueillies en temps réel, ce qui est plutôt difficile à réaliser en dehors d’une architecture orientée messages. De par leur nature, les microservices sont à même d’évoluer rapidement.

Les applications ont tendance à être similaires

Les microservices peuvent être gérés sur une plate-forme Big Data, en les superposant directement à un datalake. Tandis que des clusters isolés peuvent répondre à certains des besoins de ces microservices, les mouvements et la duplication de données deviennent un fardeau majeur. Dans l’idéal, une entreprise doit pouvoir satisfaire les besoins de toutes ses applications, et pas seulement ceux de ses outils analytiques ou applicatifs métier, mais la totalité pour tous les accès nécessaires aux données via des API standard (fichiers, base de données, streaming).

Cette approche permet de disposer d’une infrastructure flexible et capable d’évoluer de façon linéaire. Les développeurs et administrateurs n’ont plus à se préoccuper d’affecter des ressources matérielles dédiées à des clusters monofonctionnels. L’idée pour les entreprises est d’éviter de devoir ré-architecturer des applications lorsque leurs clients s’étendent au-delà de ce qu’elles avaient prévu initialement, ce qui est généralement la rançon du succès. Ces technologies demandent un peu de temps pour les comprendre et les maîtriser, mais le jeu peut en valoir la chandelle.

 

___________
Par Jim Scott est Director Enterprise Strategy & Architecture chez MapR Technologies